LNA 是 chrome 从 142 版本开始默认启用的一个功能,简单来说,LNA 出于保护本地服务的目的,会阻拦公网网站向本地网络发起的请求。本地网络的概念可以参考这个链接。
一些参考资料:
LNA 是 chrome 从 142 版本开始默认启用的一个功能,简单来说,LNA 出于保护本地服务的目的,会阻拦公网网站向本地网络发起的请求。本地网络的概念可以参考这个链接。
一些参考资料:
随着部门深入使用 dify,逐渐遇到了一些卡点问题,因此我也顺便看了下 Dify 社区的贡献指南,想着给社区提供一些我们这边的思路。
目前来说是做了两个 feature:
这两个 feature 都能显著提升平台使用体验。
第一个 feature 在开发工作流的过程中,一般我们是先搭直线的流程,再通过迭代节点等来进行流程的优化,此时如果要将许多节点一次性复制到迭代节点内部,就会特别方便,在以往只能重新再迭代节点内部再重搭一次流程。这个 feature 已经被合并到主分支且在 1.9.0 正式上线了。
在参加完 Vue Conf 25 后,跟大佬们一通交流,当时又燃起了参加开源的想法,加上得到了和一位社区同学 Little Sound 的交流,了解到了开源对于普通开发者来说也不是那么的遥不可及,我就在想,要不我也开始试试吧?
正好当天最后一个主题是我偶像 antfu 大佬的 vitejs/devtools 分享,大佬在演讲完成后当场将库开源,我也是急匆匆地点上了 star,在后面的一个开发工作中,我遇到了一些 vite 打包的性能优化问题,我就想起来这个 devtools,想看看能不能帮上忙,结果发现其实这个项目还在 WIP,这下是真的一个好机会了,我也就在这里面找到了一些 TODO,开始尝试做贡献。我找到的这个 TODO 是给 devtool 中的 plugin 视图加上 flamegraph,即火焰图。
star 数:10346
npm 下载量:260944
npm 上次更新时间:2022-10-18
GitHub:Akryum/vue-virtual-scroller
python 项目依赖管理结构发展:
pip 安装依赖,但安装在全局,容易出现依赖版本冲突的问题
venv 为每个项目搭建一套自己的虚拟环境,使得 pip 能安装到每个项目中,但是使用前需要先激活虚拟环境
依赖列表使用 pip freeze > requirements.txt 生成,但默认会将所有相关依赖都列出来,删除一个依赖就只会删除一个依赖,不会将其相关的依赖也删除,其他的就变成了孤儿依赖
引入 pyproject.toml 来管理依赖,将依赖放置在 dependencies 中,使用 pip install -e . 来安装依赖,就会自动处理好所有的间接依赖了
手动去编辑 pyproject.toml 太麻烦了,就催生了 uv poetry 这样的项目管理工具,本质上是对 pip venv 等的高级封装(但我看到 uv 是新的实现,完全使用了 rust 重写),提供了用户友好的高级接口方便地进行操作
GPT5 deepresearch canvas 功能内置,无需手动开启,模型会自己去推理现在应该使用什么工具
支持混合思考模式,简单的问题直接输出,复杂的问题会自动开启深度思考
更新了语音交互与视频交互功能,但是估计在国内用不太起来,语音功能已经支持让说话变得更快和更慢,挺厉害的
增强了记忆功能
几处都提到了显著降低了幻觉,同时减低了欺骗性,欺骗性指的是大模型有些时候会谎报自己的工作结果,或者说是为自己错误的行为做找补。
GPT 5 使用了 4o-3 来强化学习,使用了上一代模型生成的内容,来作为下一代模型的训练材料
typescript enum 会被编译为 IIFE,因此无法被正常的 treeshaking 掉,如果有 treeshaking 的需求,建议不要使用 typescript 中的 enum
React 中真的处处都是坑(重点)
最初是发现 props 变更时会导致许多不应该发生的 re-render
function App() {
return (
<div>
<Chat class="p-4" messages={messages}></Chat>
<Button
type="primary"
onClick={() => {
setMessages([
...messages,
{
id: `${Date.now()}`,
content: '测试消息',
role: 'user',
loading: false,
},
])
}}
>
test add
</Button>
</div>
)
}
const Chat: React.FC<ChatProps> = ({
difyAPIUrl,
difyAPIKey,
messages,
}: ChatProps) => {
const memoMessages = React.useMemo(() => messages, [messages])
return (
<>
<XProvider theme={theme}>
<DifyContext value={{ difyAPIUrl, difyAPIKey }}>
<ChatList messages={memoMessages}></ChatList>
</DifyContext>
</XProvider>
</>
)
}
function ChatList({ messages }: ChatListProps) {
const rolesAsObject: GetProp<typeof Bubble.List, 'roles'> = {
assistant: {
placement: 'start',
avatar: { icon: <UserOutlined />, style: { background: '#fde3cf' } },
typing: { step: 5, interval: 20 },
styles: {
content: {
backgroundColor: 'white',
},
},
variant: 'shadow',
shape: 'corner',
messageRender: renderMarkdown,
classNames: {
header: 'w-full',
},
},
user: {
placement: 'end',
// avatar: { icon: <UserOutlined />, style: { background: '#87d068' } },
shape: 'corner',
},
}
const renderMessages = useMemo(() => {
return messages.map((item) => ({
key: item.id,
role: item.role,
content: item.content,
header: renderWorkflow(item.workflowProcess),
loading: item.loading ?? false,
}))
}, [messages])
return (
<>
<Bubble.List
items={renderMessages}
roles={rolesAsObject}
className="h-full"
></Bubble.List>
</>
)
}
RAG 架构本质上是一种压缩,为了解决大模型上下文有限做出的一种方法,将文章和文本进行切段、做筛选、建索引、召回,以达到将上下文给到上下文有限的大模型的目的。
一个简单的问题,我们可以直接作为 prompt 交给到大模型,但毕竟大模型的上下文空间是有限的,即便是现在最新的 GPT5,上下文达到了 400k,即 40w 这么大了,还是有可能不够用,我们自然会想到,那我们将这么大的文章中一部分相关的内容给到大模型,结合问题就能得出想要的结果,这就是向量化的思路。
embedding 就是做这个事情的,它将一段话转换成多维数组坐标系,相似的文本在坐标系中的落点就会相接近,因此可以通过这种方式来找到相似的内容,就能实现在庞大文本中找出相似内容的目标。平时我们接触的数学中的二维坐标系、三维坐标系,自然是比较简单,但很容易就会将维度中的落点空间用完,所以先进的 embedding 模型转换成的是 3000 多维,甚至更多,来解决空间不够的问题。