xerrors
Feat: 知识库api的异步改写
好久没同步主分支了，魔改了很多代码，基本就是每天提需求就爆肝改改改。 基本上sql，minio，文件io，ocr等功能已经完全用异步实现。添加了异步Redis做缓存，Celery实现定时任务，alembic管理数据库 1.添加了硅基流动的deepseekOCR提取markdown文本，现在可处理ppt，png等图像，但是硅基流动的deepseekOCR图像理解输出中文时的效果非常差，后续可能考虑直接用Qwen3-VL视觉模型辅助生成图像理解。 2.知识库代码的异步改造，为上传接口添加了失败回滚 3.文件上传可同步到minio。添加了rerank，threshold，top-K配置项。添加了知识库向量文档迁移功能，已经导入的向量在使用相同embedding模型的情况下可直接迁移向量不需要再录入 4.企业微信单点登录 5.user表添加字段permission，控制用户对智能体的访问权限，前端只显示可访问的智能体
make测试我不会啊，都是让ai帮我做了，基本就是写个python测试脚本用边界用例跑一下接口能过就行了。每天写需求就燃尽了 如果有哪些需要的部分我可以整理下可以推到主分支
感谢你这么详细的更新！能保持需求迭代同时还把这么多模块打通，真的不容易 👏
为了后续更顺畅地合并到主分支，我这边有几个小建议（酌情选择）：
-
能否把这些大改动拆成几个相对独立的 PR？ 每个 PR 对应一个功能块（比如异步化 / OCR / 权限 / 向量迁移等），这样 review 会更清晰，也方便我们讨论细节。
-
关键模块（例如异步化部分、向量迁移、OCR 适配）最好附带一些简单的使用说明或注意点。 不需要正式文档，用 README 或注释都可以，主要是让其他开发者能顺利接手。
-
测试部分可以先保持轻量。 不需要严格的 make 流程，你现有的 Python 脚本也可以先附上，之后我们再统一测试框架。
如果你愿意整理一下已有的部分，非常欢迎你提 PR。我这边也会尽量帮你一起 review 和完善，nice👍！
期待 pr, 我看现在的创建 lightrag 实例写死了使用json 进行的 kv 和 doc 存储，希望可以改成可选的 redis ，https://github.com/xerrors/Yuxi-Know/blob/9c7a5fb4ec45b674656b76a0a659a2f636dbe35d/src/knowledge/implementations/lightrag.py#L132
目前pr提了一些代码。本人水平有限，然后平时也比较忙，大家多多见谅。
我在使用milvus的时候发现了一些问题，针对milvus添加了很多修改，我想提出几条建议：
- 知识库数据越来越多后，chunk检索准确性明显下降了。单纯根据query_text来匹配chunk的方式已经无法满足需求。因此我为metadata添加了以下字段：
file_path: Optional[str] = Field(None, description="文件路径，现已更换为minio的文件链接")
category: Optional[str] = Field(None, description="分类（例如：售后文档）")
tags: Optional[List[str]] = Field(None, description="标签列表（例如：['售后文档','某个产品型号', '故障排查']）")
custom_metadata: Optional[dict] = Field(None, description="自定义元数据（JSON对象）")
因为我们的文档库有做知识治理，所以为每个文档按照的档案库内的文件路径进行分类和标签是比较适合的。这样在检索的时候，让模型优先通过category ，tags ，query_text的任意组合进行高颗粒度的检索。能够更快的定位到目标chunk。在custom_metadata中也可以通过ai总结，或者用户自定义的方式来添加更多的信息；或者可以直接存储类对象，为工具调用提供可能。
async def async_retriever_wrapper(
query_text: str | None = None,
category: str | None = None,
tags: list[str] | None = None
) -> Any
"""
异步检索器包装函数
Args:
query_text: 查询关键词
category: 可选的分类筛选
tags: 可选的标签筛选
"""
而所有的category和tags我都放到了工具描述中，这样模型在调用工具的时候就可以自动看到该知识库中所有的category和tags
- main分支放弃对Chroma的维护。我认为milvus是chroma的上位替代，单从开发的角度来看，milvus的存取方式更多，拓展性更丰富。且lightrag的仓库中我也没有看到对chroma的支持。可以在其他分支中保留Chroma。 未来知识库部分的代码更新一定是着力于提升RAG的准确性和即时性，重心不该是我支持哪些向量数据库，而应该是我支持哪些rag方式，例如Agentic RAG。而从二者的路线图就可以看出来哪个更适合作为向量数据库——当Milvus着力于增强检索性能的时候，Chroma居然在考虑做工作流和可视化？显然Chroma的存在是一个暗雷。
我未来的开发方向是RAG优化以及上下文工程。自己又比较懒，下班后就想躺平，效率没有很高，大家可以催一下我鞭策一下。
@ELK-milu ，感谢！
第一点非常赞同，之前也萌生过类似的想法，当时是考虑到现在的 Code agent普遍使用 grep 这类传统方法检索片段（适用于代码场景，不适用于传统 RAG），不过结合在一起倒是挺好的，query_text的时候可以指定关键词。 这次提到的 category 和 tags 也确实是非常好的思路。
第二点这个其实是遗留问题，源自之前的代码重构，Milvus当时的支持不完善，每次调试很麻烦，而基于chroma的这种单文件的向量数据库就很好调试，所以保留了下来。现在知识库整体比较成熟了，chroma的历史使命也确实是可以完成了，近期版本会移除。这里关于知识库类型的定位非常赞同，后续这里的类型会调整为 RAG 的类型，将 Milvus 调整为 基础RAG，LightRAG 保留，额外支持 LinearRAG 无 token 消耗的 GraphRAG 方法，在 local 检索方面效果不错（不过可惜的是代码是 GPL 协议 https://github.com/DEEP-PolyU/LinearRAG ，只能基于原论文复现）。
其实我目前的研究工作是 GraphRAG相关的，只是最近论文难产，等论文搞定了就把代码合并进来。