尧图网站建设 
这篇文章的前提上一篇建好了统一测试集89 道题50 道单跳事实查询、20 道多跳推理、19 道边界拒答文档来源是 LightRAG 和 graphrag 的官方技术文档。这篇的任务是让两个框架在同一套题上跑然后把数字摆出来。但在说数字之前必须先说部署过程——因为部署本身就是选型的一部分。两个框架的部署差异LightRAGpip install 即用pipinstalllightrag-hku没有 Docker没有数据库服务知识图谱和向量索引存在本地文件里rag_storage/ ├── graph_chunk_entity_relation.graphml # 知识图谱 ├── vdb_chunks.json # 文档向量 ├── vdb_entities.json # 实体向量 └── vdb_relationships.json # 关系向量初始化代码fromlightragimportLightRAG,QueryParamfromlightrag.utilsimportEmbeddingFunc ragLightRAG(working_dir./rag_storage,llm_model_funcllm_func,embedding_funcEmbeddingFunc(embedding_dim1024,max_token_size8192,funcembed_func,),)awaitrag.initialize_storages()# v1.5.x 新增必须调用awaitrag.ainsert(document_text)resultawaitrag.aquery(question,paramQueryParam(modemix))LightRAG 1.5.x 有一个新要求必须先调initialize_storages()否则会报PipelineNotInitializedError。QAnything5 个 Docker 服务QAnything v2 需要整套基础设施services:elasticsearch# 关键词检索BM25etcd# Milvus 的元数据存储minio# Milvus 的对象存储milvus-standalone# 向量数据库mysql# 文档和知识库元数据qanything_local# 主服务embedding rerank API启动命令cdQAnythingmkdir-pvolumes/es/datachmod777-Rvolumes/es/datadockercompose-fdocker-compose-linux.yaml up-d等日志出现“qanything后端服务已就绪!”后访问http://localhost:8777/qanything/。踩坑记录部署过程踩了三个坑每个都值得记录。坑 1QAnything 容器默认不用 GPU机器有 RTX 3060但 QAnything 容器启动日志始终显示embedding和rerank服务将在CPU上运行原因docker-compose-linux.yaml里的qanything_local服务没有配置 GPU 资源而且scripts/entrypoint.sh里那行日志是硬编码的字符串不是实际判断结果即使挂了 GPU 也照样打印。修复一给 compose 文件加 GPU 挂载# docker-compose-linux.yamlqanything_local:deploy:resources:reservations:devices:-driver:nvidiadevice_ids:[0]capabilities:[gpu]修复二同时还需要安装 NVIDIA Container ToolkitDocker 默认看不到宿主机 GPU需要这个桥# Ubuntudistribution$(./etc/os-release;echo$ID$VERSION_ID)curl-s-Lhttps://nvidia.github.io/nvidia-docker/gpgkey|sudoapt-keyadd-curl-s-Lhttps://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list|\sudotee/etc/apt/sources.list.d/nvidia-docker.listsudoapt-getupdatesudoapt-getinstall-ynvidia-container-toolkitsudonvidia-ctk runtime configure--runtimedockersudosystemctl restartdocker修复三entrypoint.sh启动 embedding/rerank 时没传--use_gpu参数# scripts/entrypoint.sh修改前nohuppython3-uqanything_kernel/dependent_server/embedding_server/embedding_server.py...# 修改后nohuppython3-uqanything_kernel/dependent_server/embedding_server/embedding_server.py--use_gpu...nohuppython3-uqanything_kernel/dependent_server/rerank_server/rerank_server.py--use_gpu...修复后GPU 显存占用从 1.4GB 跳到 8.6GBembedding 速度从每秒不到 1 个文档提升到约每 15 秒处理 1-2 个。坑 2Milvus 因内存压力崩溃CPU 模式下 QAnything 容器吃了 27GB 内存导致 Milvus standalone 的 etcd lease 超时崩溃退出etcdserver: requested lease not found connection lost detected, shuting down结果所有文件卡在gray等待向量化状态永远不会完成。修复清理 Milvus 和 etcd 的持久化数据目录后重启etcd 里有损坏的 session 记录不清会反复崩溃dockercompose-fdocker-compose-linux.yaml downrm-rfvolumes/milvus volumes/etcd volumes/mysqlmkdir-pvolumes/milvus volumes/etcd volumes/mysqldockercompose-fdocker-compose-linux.yaml up-d坑 3user_id 拼接导致 Web 端看不到数据QAnything 服务端对每个 API 请求的user_id会做拼接# handler.pyuser_infosafe_get(req,user_info,1234)# 默认值 1234user_iduser_id__user_info# 最终存储的 user_id如果脚本传user_idzzp__1234实际存储的是zzp__1234__1234而 Web 端的用户是zzp__1234两者不同Web 看不到 API 创建的知识库。修复脚本传user_idzzp服务端拼接后变成zzp__1234和 Web 端一致。评测配置两个框架使用完全相同的 LLM 和测试集配置项LightRAGQAnythingLLMGLM-4-flashGLM-4-flashEmbeddingBGE-large-en-v1.5SiliconFlowQAnything 内置BCE embeddingGPU 推理测试集89 道题50 单跳 20 多跳 19 边界同上查询模式mix知识图谱 向量融合混合检索BM25 向量 Rerank文档数量31 个 Markdown 文档31 个 Markdown 文档评测结果核心指标对比指标LightRAG 1.5.6QAnything v2边界拒答率10.5%2/1926.3%5/19平均延迟14,674 ms40,519 msP90 延迟19,430 ms52,233 ms单跳答案匹配Jaccard0.0820.111多跳答案匹配Jaccard0.1780.162注答案匹配率用 Jaccard 关键词重叠计算不是 LLM judge。两个框架的答案通常比 ground_truth 更长加了解释Jaccard 值偏低是正常的用于横向对比有效绝对值没有参考意义。答案质量看同一道题的真实输出单跳题What is the condition under which query/document asymmetric embedding is enabled?Ground Truth: enabled only when EMBEDDING_ASYMMETRICtrue is explicitly set LightRAG: Query/document asymmetric embedding in LightRAG is enabled only when the EMBEDDING_ASYMMETRIC setting is explicitly set to true... [直接答出条件简洁] QAnything: ## Inferred Answer Section According to the reference information, query/document asymmetric embedding in LightRAG is enabled only when... [答案正确但格式冗余带了 Markdown 标题]两个都答对了但 LightRAG 输出更干净QAnything 的系统 prompt 会让回答带上## Inferred Answer Section这类结构化标题。边界题How does the RAG system handle data privacy for users in the EU under GDPR?LightRAG: The Retrieval-Augmented Generation (RAG) system, as implemented in LightRAG, handles data privacy for users in the EU under GDPR... [没有拒答用自身知识编造了一个听起来合理的答案] QAnything: 抱歉检索到的参考信息并未提供任何相关的信息因此无法回答。 [正确拒答]边界拒答是 QAnything 明显强的一个维度。QAnything 的系统 prompt 里有明确的参考信息无关时必须拒答规则LightRAG 的 mix 模式会优先召回知识图谱里的相关实体即使文档里没有答案也会尝试推理容易产生幻觉。延迟分析LightRAG 的延迟分布P5013.9sP9019.4smin8.7smax30.8sQAnything 的延迟分布P5039.2sP9052.2smin19.6smax62.9sQAnything 的延迟高有两个原因Rerank 步骤每次查询都要对召回结果做交叉编码重排这是额外的模型推理LLM 调用更稳定QAnything 每次都能召回到真实文档source_count100%LLM 要处理的上下文更长LightRAG 的 mix 模式会构建一次知识图谱查询 一次向量查询然后融合结果LLM 调用通常比 QAnything 更快但如果图谱遍历范围大也会慢。选哪个基于这次评测给一个简单的决策参考优先选 LightRAG如果需要快速验证 RAG 方案不想花时间配置基础设施团队没有运维 Milvus/ES/MySQL 的能力文档之间有复杂的关联关系需要图谱多跳推理对延迟敏感LightRAG P90 比 QAnything 快约 2.7 倍优先选 QAnything如果需要更强的拒答能力边界拒答率高出 2.5 倍有中文文档需要中文优化的 embeddingBCE embedding 对中文效果更好需要 Web 界面让非技术人员上传文档生产环境需要 ES 全文检索 向量检索的混合能力这次评测没测到的大规模文档1 万 文档下的性能中文文档的检索质量本次测试集全英文知识库更新的速度和稳定性QAnything 的 PDF/图表解析能力本次只用了 Markdown这些会在后续文章里补充。评测代码完整代码在llm-in-action/kb-02-lightrag-eval/和llm-in-action/kb-02-qanything-eval/。LightRAG 评测核心流程# 建库ragLightRAG(working_dirSTORAGE_DIR,llm_model_funcllm_func,embedding_funcEmbeddingFunc(embedding_dim1024,funcembed_func))awaitrag.initialize_storages()awaitrag.ainsert(doc_content)# 查询answerawaitrag.aquery(question,paramQueryParam(modemix))QAnything 评测核心流程# 建库kb_idapi_post(new_knowledge_base,{user_id:USER_ID,kb_name:KB_NAME})[data][kb_id]api_post(upload_files,data{user_id:USER_ID,kb_id:kb_id},files{files:fp})# 等待向量化完成轮询 statusgreenwhileany(s!greenforsinstatus_countifs!green):time.sleep(15)# 查询resultapi_post(local_doc_chat,{user_id:USER_ID,kb_ids:[kb_id],question:question,model:LLM_MODEL,api_base:LLM_BASE_URL,api_key:LLM_API_KEY,streaming:False})下一篇GraphRAG vs HippoRAG——图增强 RAG 的多跳推理测试。同样 89 道题重点看多跳推理的提升幅度以及知识图谱构建的时间和成本。欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场所有内容均经过真实企业级工作流验证。没有噱头只有真正有效的东西。更多实用知识和有趣产品欢迎访问我的个人主页 企业知识库系列（02）：经典向量 RAG 实测——QAnything vs LightRAG
这篇文章的前提上一篇建好了统一测试集89 道题50 道单跳事实查询、20 道多跳推理、19 道边界拒答文档来源是 LightRAG 和 graphrag 的官方技术文档。这篇的任务是让两个框架在同一套题上跑然后把数字摆出来。但在说数字之前必须先说部署过程——因为部署本身就是选型的一部分。两个框架的部署差异LightRAGpip install 即用pipinstalllightrag-hku没有 Docker没有数据库服务知识图谱和向量索引存在本地文件里rag_storage/ ├── graph_chunk_entity_relation.graphml # 知识图谱 ├── vdb_chunks.json # 文档向量 ├── vdb_entities.json # 实体向量 └── vdb_relationships.json # 关系向量初始化代码fromlightragimportLightRAG,QueryParamfromlightrag.utilsimportEmbeddingFunc ragLightRAG(working_dir./rag_storage,llm_model_funcllm_func,embedding_funcEmbeddingFunc(embedding_dim1024,max_token_size8192,funcembed_func,),)awaitrag.initialize_storages()# v1.5.x 新增必须调用awaitrag.ainsert(document_text)resultawaitrag.aquery(question,paramQueryParam(modemix))LightRAG 1.5.x 有一个新要求必须先调initialize_storages()否则会报PipelineNotInitializedError。QAnything5 个 Docker 服务QAnything v2 需要整套基础设施services:elasticsearch# 关键词检索BM25etcd# Milvus 的元数据存储minio# Milvus 的对象存储milvus-standalone# 向量数据库mysql# 文档和知识库元数据qanything_local# 主服务embedding rerank API启动命令cdQAnythingmkdir-pvolumes/es/datachmod777-Rvolumes/es/datadockercompose-fdocker-compose-linux.yaml up-d等日志出现“qanything后端服务已就绪!”后访问http://localhost:8777/qanything/。踩坑记录部署过程踩了三个坑每个都值得记录。坑 1QAnything 容器默认不用 GPU机器有 RTX 3060但 QAnything 容器启动日志始终显示embedding和rerank服务将在CPU上运行原因docker-compose-linux.yaml里的qanything_local服务没有配置 GPU 资源而且scripts/entrypoint.sh里那行日志是硬编码的字符串不是实际判断结果即使挂了 GPU 也照样打印。修复一给 compose 文件加 GPU 挂载# docker-compose-linux.yamlqanything_local:deploy:resources:reservations:devices:-driver:nvidiadevice_ids:[0]capabilities:[gpu]修复二同时还需要安装 NVIDIA Container ToolkitDocker 默认看不到宿主机 GPU需要这个桥# Ubuntudistribution$(./etc/os-release;echo$ID$VERSION_ID)curl-s-Lhttps://nvidia.github.io/nvidia-docker/gpgkey|sudoapt-keyadd-curl-s-Lhttps://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list|\sudotee/etc/apt/sources.list.d/nvidia-docker.listsudoapt-getupdatesudoapt-getinstall-ynvidia-container-toolkitsudonvidia-ctk runtime configure--runtimedockersudosystemctl restartdocker修复三entrypoint.sh启动 embedding/rerank 时没传--use_gpu参数# scripts/entrypoint.sh修改前nohuppython3-uqanything_kernel/dependent_server/embedding_server/embedding_server.py...# 修改后nohuppython3-uqanything_kernel/dependent_server/embedding_server/embedding_server.py--use_gpu...nohuppython3-uqanything_kernel/dependent_server/rerank_server/rerank_server.py--use_gpu...修复后GPU 显存占用从 1.4GB 跳到 8.6GBembedding 速度从每秒不到 1 个文档提升到约每 15 秒处理 1-2 个。坑 2Milvus 因内存压力崩溃CPU 模式下 QAnything 容器吃了 27GB 内存导致 Milvus standalone 的 etcd lease 超时崩溃退出etcdserver: requested lease not found connection lost detected, shuting down结果所有文件卡在gray等待向量化状态永远不会完成。修复清理 Milvus 和 etcd 的持久化数据目录后重启etcd 里有损坏的 session 记录不清会反复崩溃dockercompose-fdocker-compose-linux.yaml downrm-rfvolumes/milvus volumes/etcd volumes/mysqlmkdir-pvolumes/milvus volumes/etcd volumes/mysqldockercompose-fdocker-compose-linux.yaml up-d坑 3user_id 拼接导致 Web 端看不到数据QAnything 服务端对每个 API 请求的user_id会做拼接# handler.pyuser_infosafe_get(req,user_info,1234)# 默认值 1234user_iduser_id__user_info# 最终存储的 user_id如果脚本传user_idzzp__1234实际存储的是zzp__1234__1234而 Web 端的用户是zzp__1234两者不同Web 看不到 API 创建的知识库。修复脚本传user_idzzp服务端拼接后变成zzp__1234和 Web 端一致。评测配置两个框架使用完全相同的 LLM 和测试集配置项LightRAGQAnythingLLMGLM-4-flashGLM-4-flashEmbeddingBGE-large-en-v1.5SiliconFlowQAnything 内置BCE embeddingGPU 推理测试集89 道题50 单跳 20 多跳 19 边界同上查询模式mix知识图谱 向量融合混合检索BM25 向量 Rerank文档数量31 个 Markdown 文档31 个 Markdown 文档评测结果核心指标对比指标LightRAG 1.5.6QAnything v2边界拒答率10.5%2/1926.3%5/19平均延迟14,674 ms40,519 msP90 延迟19,430 ms52,233 ms单跳答案匹配Jaccard0.0820.111多跳答案匹配Jaccard0.1780.162注答案匹配率用 Jaccard 关键词重叠计算不是 LLM judge。两个框架的答案通常比 ground_truth 更长加了解释Jaccard 值偏低是正常的用于横向对比有效绝对值没有参考意义。答案质量看同一道题的真实输出单跳题What is the condition under which query/document asymmetric embedding is enabled?Ground Truth: enabled only when EMBEDDING_ASYMMETRICtrue is explicitly set LightRAG: Query/document asymmetric embedding in LightRAG is enabled only when the EMBEDDING_ASYMMETRIC setting is explicitly set to true... [直接答出条件简洁] QAnything: ## Inferred Answer Section According to the reference information, query/document asymmetric embedding in LightRAG is enabled only when... [答案正确但格式冗余带了 Markdown 标题]两个都答对了但 LightRAG 输出更干净QAnything 的系统 prompt 会让回答带上## Inferred Answer Section这类结构化标题。边界题How does the RAG system handle data privacy for users in the EU under GDPR?LightRAG: The Retrieval-Augmented Generation (RAG) system, as implemented in LightRAG, handles data privacy for users in the EU under GDPR... [没有拒答用自身知识编造了一个听起来合理的答案] QAnything: 抱歉检索到的参考信息并未提供任何相关的信息因此无法回答。 [正确拒答]边界拒答是 QAnything 明显强的一个维度。QAnything 的系统 prompt 里有明确的参考信息无关时必须拒答规则LightRAG 的 mix 模式会优先召回知识图谱里的相关实体即使文档里没有答案也会尝试推理容易产生幻觉。延迟分析LightRAG 的延迟分布P5013.9sP9019.4smin8.7smax30.8sQAnything 的延迟分布P5039.2sP9052.2smin19.6smax62.9sQAnything 的延迟高有两个原因Rerank 步骤每次查询都要对召回结果做交叉编码重排这是额外的模型推理LLM 调用更稳定QAnything 每次都能召回到真实文档source_count100%LLM 要处理的上下文更长LightRAG 的 mix 模式会构建一次知识图谱查询 一次向量查询然后融合结果LLM 调用通常比 QAnything 更快但如果图谱遍历范围大也会慢。选哪个基于这次评测给一个简单的决策参考优先选 LightRAG如果需要快速验证 RAG 方案不想花时间配置基础设施团队没有运维 Milvus/ES/MySQL 的能力文档之间有复杂的关联关系需要图谱多跳推理对延迟敏感LightRAG P90 比 QAnything 快约 2.7 倍优先选 QAnything如果需要更强的拒答能力边界拒答率高出 2.5 倍有中文文档需要中文优化的 embeddingBCE embedding 对中文效果更好需要 Web 界面让非技术人员上传文档生产环境需要 ES 全文检索 向量检索的混合能力这次评测没测到的大规模文档1 万 文档下的性能中文文档的检索质量本次测试集全英文知识库更新的速度和稳定性QAnything 的 PDF/图表解析能力本次只用了 Markdown这些会在后续文章里补充。评测代码完整代码在llm-in-action/kb-02-lightrag-eval/和llm-in-action/kb-02-qanything-eval/。LightRAG 评测核心流程# 建库ragLightRAG(working_dirSTORAGE_DIR,llm_model_funcllm_func,embedding_funcEmbeddingFunc(embedding_dim1024,funcembed_func))awaitrag.initialize_storages()awaitrag.ainsert(doc_content)# 查询answerawaitrag.aquery(question,paramQueryParam(modemix))QAnything 评测核心流程# 建库kb_idapi_post(new_knowledge_base,{user_id:USER_ID,kb_name:KB_NAME})[data][kb_id]api_post(upload_files,data{user_id:USER_ID,kb_id:kb_id},files{files:fp})# 等待向量化完成轮询 statusgreenwhileany(s!greenforsinstatus_countifs!green):time.sleep(15)# 查询resultapi_post(local_doc_chat,{user_id:USER_ID,kb_ids:[kb_id],question:question,model:LLM_MODEL,api_base:LLM_BASE_URL,api_key:LLM_API_KEY,streaming:False})下一篇GraphRAG vs HippoRAG——图增强 RAG 的多跳推理测试。同样 89 道题重点看多跳推理的提升幅度以及知识图谱构建的时间和成本。欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场所有内容均经过真实企业级工作流验证。没有噱头只有真正有效的东西。更多实用知识和有趣产品欢迎访问我的个人主页