Wenjie Zhang
Wenjie Zhang
格式参考：{"h": "北京", "t": "中国", "r": "首都"}
> > 格式参考：{"h": "北京", "t": "中国", "r": "首都"} > > 建议大佬把docker-compose.dev.yml的milvus和neo4j的版本改一下，这样会减少很多复现错误 昨天刚更新，因为我本身的设备测试不出来这个 bug，所以根本不知道 🤣
最新的代码已经更新 @shangluz
新版本修改为基于智能体的调用，此issue已不适用，因此close这个issue
问题1在昨晚的更新中修复了，可以更新一下。问题2那里需要前端重新安装依赖，启动的时候加上 --build 就好
> 你好，还是会出现类似情况 说的是问题1现在还是会出现吗？
@Gjt20021214 这个有点奇怪，如果说，docker compose down 之后，重新 build 启动还会出现这个问题的话，确实有点诡异。package.json 里面确实是有的，正常 npm install 应该是没问题的。也可以在 docker 外部启动一下前端试试
@Gjt20021214 这个解决了吗？如果没解决的话，可以看一下这个 https://github.com/xerrors/Yuxi-Know/issues/169#issuecomment-2832266461
感谢你这么详细的更新！能保持需求迭代同时还把这么多模块打通，真的不容易 👏 为了后续更顺畅地合并到主分支，我这边有几个小建议（酌情选择）： 1. 能否把这些大改动拆成几个相对独立的 PR？ 每个 PR 对应一个功能块（比如异步化 / OCR / 权限 / 向量迁移等），这样 review 会更清晰，也方便我们讨论细节。 2. 关键模块（例如异步化部分、向量迁移、OCR 适配）最好附带一些简单的使用说明或注意点。 不需要正式文档，用 README 或注释都可以，主要是让其他开发者能顺利接手。 3. 测试部分可以先保持轻量。 不需要严格的 make 流程，你现有的 Python 脚本也可以先附上，之后我们再统一测试框架。...
@ELK-milu ，感谢！ 第一点非常赞同，之前也萌生过类似的想法，当时是考虑到现在的 Code agent普遍使用 grep 这类传统方法检索片段（适用于代码场景，不适用于传统 RAG），不过结合在一起倒是挺好的，query_text的时候可以指定关键词。 这次提到的 category 和 tags 也确实是非常好的思路。 第二点这个其实是遗留问题，源自之前的代码重构，Milvus当时的支持不完善，每次调试很麻烦，而基于chroma的这种单文件的向量数据库就很好调试，所以保留了下来。现在知识库整体比较成熟了，chroma的历史使命也确实是可以完成了，近期版本会移除。这里关于知识库类型的定位非常赞同，后续这里的类型会调整为 RAG 的类型，将 Milvus 调整为 基础RAG，LightRAG 保留，额外支持 LinearRAG 无 token 消耗的 GraphRAG 方法，在 local 检索方面效果不错（不过可惜的是代码是 GPL 协议...