NexusRAG：混合检索增强生成系统实战解析与部署指南

1. 项目概述一个面向复杂文档的智能问答系统如果你正在寻找一个能真正“读懂”你公司年报、技术白皮书或产品手册并能像专家一样回答其中问题的工具那么NexusRAG可能就是你折腾半天后最终会停下来的那个答案。这不是又一个简单的“上传PDF然后问问题”的玩具而是一个融合了向量搜索、知识图谱和智能体式对话的混合检索增强生成系统。简单来说它试图解决传统RAG检索增强生成在面对复杂、结构化文档时最头疼的几个问题表格和图片成了摆设、上下文割裂、回答缺乏依据、以及无法进行跨文档的关联推理。我花了相当长时间去研究和复现这个项目核心原因在于它的设计思路非常“工程化”没有停留在论文里的理想状态而是针对实际落地中的痛点做了大量妥协与增强。比如它没有盲目追求单一的、最先进的嵌入模型而是采用了“双模型”策略用一个轻快的小模型BAAI/bge-m3负责海量文本的快速向量检索再用一个能力更强的大模型如Gemini Embedding或本地Sentence Transformers专门为知识图谱提取高质量的实体语义。这种“分工协作”的思路在资源有限的情况下是保证效果和效率平衡的务实选择。整个系统适合两类人一是希望为自己的知识库或内部文档系统添加智能问答能力的开发者你可以基于它快速搭建一个原型甚至生产系统二是对RAG技术演进感兴趣的研究者或工程师通过拆解它的混合检索管道、知识图谱构建以及多模型调度策略你能学到很多在教科书里看不到的实战经验。接下来我会带你深入它的架构核心看看它是如何一步步把零散的文档变成可查询、可推理的智能体的。2. 核心架构与设计哲学拆解2.1 为什么是“混合”知识库超越传统RAG的局限性传统RAG的流程可以概括为“切分-嵌入-检索-生成”听起来很顺畅但一遇到真实的商业或技术文档就漏洞百出。NexusRAG的“混合”特性正是为了填补这些漏洞而设计的。我们可以通过一个对比来直观感受假设你有一份包含财务报表复杂表格和技术架构图图片的年度报告。传统RAG可能会把表格数据切得支离破碎图片则完全忽略。当你问“去年营收增长了多少主要来自哪个产品线”时系统要么找不到数据要么找到的文本片段无法支撑一个准确的回答。NexusRAG的应对策略是多管齐下深度文档解析不是简单提取纯文本而是用Docling或Marker这类解析器保留文档的结构信息标题层级、页码、段落归属和非文本元素表格、公式、图片位置。这意味着系统知道“营收增长率15%”这个数字是位于“第三章财务摘要”下的一个4x5的表格中。混合检索管道检索时不再是向量相似度“一锤子买卖”。它会并行执行三件事向量搜索召回大量相关片段、知识图谱查询查找相关的实体和关系、再用交叉编码器对召回结果进行精排。这相当于先用广撒网再用实体关系过滤最后用更精细的模型判断哪个片段最相关极大提高了答案的准确性和可解释性。带引用的生成LLM生成答案时会被强制要求引用来源。每个引用都是一个4字符的ID如[a3z1]点击可以直接定位到原文的特定页面和章节。这不仅是可解释性更是对LLM“胡说八道”的一种强力约束。这种设计哲学的核心是尊重文档的复杂性。它承认现实世界的知识不是扁平的文字流而是结构、数据、图像和语义关系的混合体。因此它的解决方案也必须是混合的、分层的。2.2 技术栈选型背后的逻辑务实与性能的权衡NexusRAG的技术栈选择体现了明显的“生产导向”思维每一项都不是盲目追新而是有明确的考量。后端核心FastAPI 异步生态 选择FastAPI而非Django或Flask核心诉求是高性能异步和简洁的API设计。RAG流程中文档解析、模型推理、数据库查询都是I/O密集型操作异步处理能极大提升并发吞吐量。FastAPI基于Pydantic的自动请求/响应验证和Swagger UI自动生成也大幅降低了API开发和维护成本。搭配SQLAlchemy 2.0的异步模式和asyncpg驱动确保了从Web层到数据层全链路的异步能力。向量数据库ChromaDB 在Milvus、Pinecone、Weaviate等众多选手中选择ChromaDB主要原因在于其轻量、易嵌入和Python原生的特性。NexusRAG采用Docker Compose部署ChromaDB可以作为一个独立的容器服务无需复杂的外部集群。它的Python客户端API非常直观对于实现“每个工作区一个集合”这种多租户隔离模式非常友好。虽然它在超大规模向量索引方面可能不是最强但对于大多数企业级知识库应用文档量在万到百万级来说其性能和功能已经完全足够。知识图谱LightRAG 这里的选择非常巧妙。它没有用Neo4j、NebulaGraph这类重型图数据库而是采用了LightRAG一个基于NetworkX内存图计算和NanoVectorDB轻量向量存储的库。这带来了两个巨大好处零外部依赖无需额外部署和维护一个图数据库服务和极低的资源开销。知识图谱在这里的角色是“语义增强索引”而非需要复杂图遍历查询的独立系统因此轻量级的实现是完全合理的也简化了整体部署复杂度。前端React 现代工具链 React 19 TypeScript Vite的组合是当前前端开发的事实标准。Zustand用于轻量级状态管理React Query处理服务器状态如聊天历史、文档列表的缓存、更新和同步Framer Motion提供流畅的交互动画。这个组合保证了开发体验和用户体验的平衡。特别值得一提的是前端实现了SSEServer-Sent Events流式响应让用户能实时看到“分析中 - 检索中 - 生成中”的智能体思考过程这种即时反馈对用户体验至关重要。实操心得技术栈的“时髦度”不如“合适度”重要。这个选型清单里几乎没有“炫技”的成分每一项都是为了解决特定问题且彼此之间的集成成本很低。在自研项目初期这种务实的选择能让你更快地推出可用版本而不是陷入技术债的泥潭。3. 混合检索管道的深度解析与实操要点3.1 双嵌入模型策略分工的艺术这是NexusRAG设计中非常精彩的一环。很多项目会纠结于选一个“全能”的嵌入模型但往往顾此失彼大模型效果好但慢且贵小模型快但语义捕捉能力弱。NexusRAG的解决方案是“让专业的模型做专业的事”。向量搜索嵌入模型BAAI/bge-m3角色负责从海量文本块中快速召回候选片段。选型理由BAAI/bge-m3是一个1024维的多语言模型在MTEB等基准测试上表现优异。关键是它足够轻量可以轻松在CPU或消费级GPU上运行实现毫秒级的相似度计算。它的任务是“广撒网”所以速度和召回率Recall是首要指标对绝对精准度Precision的要求可以靠后续环节弥补。实操配置这个模型是写死在代码里的核心依赖通常无需改动。项目启动时会自动下载约数百MB。你需要确保运行环境有足够的网络带宽和磁盘空间。知识图谱嵌入模型可配置角色为从文本中提取出的实体和关系生成高质量的语义表示用于图谱内部的语义查询和匹配。选型理由实体和关系的语义通常更复杂、更抽象需要更强的模型来理解。这里提供了三个选项对应不同的资源和技术路线Gemini Embedding默认维度高达3072由Google云服务提供语义理解能力最强但需要API Key且有网络延迟和费用。Ollama可以运行nomic-embed-text等本地嵌入模型平衡了效果和隐私性。Sentence Transformers完全离线的最佳选择。你可以指定如BAAI/bge-m3与向量搜索复用同一模型零额外开销、intfloat/e5-large-v2等模型。这实现了KG功能的完全离线化对数据安全要求高的场景是必选项。实操配置通过环境变量KG_EMBEDDING_PROVIDER和KG_EMBEDDING_MODEL控制。我强烈建议在内部部署时使用sentence_transformers并指定一个与bge-m3不同的、更强大的模型如果资源允许以实现更好的实体区分度。# 在 .env 文件中的关键配置示例 # 使用完全离线的KG嵌入方案 KG_EMBEDDING_PROVIDERsentence_transformers KG_EMBEDDING_MODELintfloat/e5-large-v2 # 可选使用不同的模型 KG_EMBEDDING_DIMENSION1024 # 必须与所选模型的维度一致3.2 三阶段检索流程从召回、精排到融合检索流程是RAG的“心脏”NexusRAG设计了一个严谨的三阶段流水线第一阶段并行召回向量搜索召回使用BAAI/bge-m3模型将用户查询编码为向量在ChromaDB中进行余弦相似度搜索过度召回Top-K个候选片段默认K20。这一步追求高召回率宁可多找一些可能相关的也不能漏掉关键信息。知识图谱实体召回同时对用户查询进行实体抽取和关键词分析在LightRAG构建的知识图谱中查找匹配的实体节点及其关联的文本片段。例如查询“苹果公司的CEO在2023年说了什么”会提取实体“苹果公司”、“CEO”并在图谱中找到与之相连的文本块。第二阶段交叉编码器重排序这是提升精度的关键一步。将用户查询和第一阶段召回的所有候选文本片段比如20个成对地输入到一个专门的“重排序模型”BAAI/bge-reranker-v2-m3中。这个交叉编码器会同时编码查询和文档计算出一个比单纯向量相似度更精确的相关性分数。原理解释双编码器如BGE-M3是“编码后比较”速度快但精度有损失。交叉编码器是“一起编码再判断”计算量更大但能捕捉更细微的语义交互精度显著更高。NexusRAG先用快的双编码器召回再用慢但准的交叉编码器对少量候选进行精排是经典的“召回-排序”两阶段策略。第三阶段结果过滤与融合根据重排序分数保留排名前N默认N8且分数超过某个阈值如0.15的片段。如果所有片段分数都低于阈值则作为安全回退只保留前3个。最后将向量搜索和知识图谱召回的结果基于分数进行融合、去重形成最终的上下文片段列表送入LLM生成答案。这个流程确保了结果既全面靠向量和KG双路召回又精准靠交叉编码器精排是效果优于简单向量搜索的核心。3.3 文档解析与视觉智能让图片和表格“说话”这是NexusRAG的另一大亮点。它通过一套流程让非文本内容也能被检索到。图像处理流程解析提取Docling或Marker在解析PDF/DOCX时会将其中的图片每页最多50张提取出来保存为文件并在元数据中记录它们属于哪一页。LLM描述生成使用多模态LLMGemini Vision或支持视觉的Ollama模型为每张图片生成一段详细的文字描述。例如一张折线图可能被描述为“[第5页图片]一张展示2019-2023年季度营收的折线图其中2023年Q4营收达到峰值1200万美元。”描述注入与嵌入将这段描述文本追加到图片所在页面的所有文本块后面。然后对整个文本块包含原始文字和图片描述进行向量嵌入。检索与展示当用户搜索“营收增长图表”时系统通过语义匹配找到包含该图片描述的文本块从而间接“找到”了图片。在返回答案时会以[IMG-p5f2]的形式引用该图片并可在文档查看器中定位。表格处理流程结构化提取解析器将表格转换为结构化的Markdown格式保留行、列和表头信息。LLM摘要生成使用文本LLM为每个表格生成一个简洁的摘要说明表格的主题和关键数据点。例如“[第8页表格 (5x3)]2023年各地区销售数据汇总显示亚太地区增长率最高达25%。”摘要注入同样将表格摘要注入到对应页面的文本块中使其参与嵌入和检索。注意事项图片描述和表格摘要的质量完全取决于所用的多模态/文本LLM的能力。如果使用较小的本地模型如7B参数以下生成的描述可能过于笼统或不准这会直接影响后续检索效果。因此在资源允许的情况下为这个环节配置一个能力较强的模型是值得的。4. 从零到一的完整部署与配置实操4.1 环境准备与Docker一键部署推荐对于大多数用户尤其是想快速体验或用于生产环境Docker Compose部署是最省心、依赖冲突最少的方式。步骤1克隆项目与基础配置git clone https://github.com/LeDat98/NexusRAG.git cd NexusRAG cp .env.example .env接下来是关键的.env文件配置。你需要决定使用云端LLM还是本地LLM。方案A使用Google Gemini云端需API Key效果最好# 编辑 .env 文件 LLM_PROVIDERgemini GOOGLE_AI_API_KEYyour_actual_google_ai_api_key_here # KG嵌入也可以用Gemini保持默认即可 KG_EMBEDDING_PROVIDERgemini去Google AI Studio获取一个API Key填入。Gemini模型在知识提取、复杂推理和表格处理上通常表现更稳定。方案B使用本地Ollama完全离线数据隐私高# 编辑 .env 文件 LLM_PROVIDERollama # 注释掉Gemini的API Key # GOOGLE_AI_API_KEYyour_key OLLAMA_MODELgemma4:e4b # 推荐使用Gemma 4 8B模型工具调用支持好 OLLAMA_HOSThttp://host.docker.internal:11434 # 让Docker容器能访问宿主机Ollama # KG嵌入也切换到本地 KG_EMBEDDING_PROVIDERollama KG_EMBEDDING_MODELnomic-embed-text # 需要在Ollama中先pull这个模型确保宿主机上已经安装并运行了Ollama并且已经拉取了gemma4:e4b和nomic-embed-text模型ollama pull gemma4:e4b。步骤2启动所有服务docker compose up -d这个命令会启动四个容器postgresPostgreSQL数据库存储元数据、聊天记录。chromadbChromaDB向量数据库。backendNexusRAG的后端FastAPI服务。frontendReact前端界面。mcpModel Context Protocol服务器可选用于连接Cursor/Claude等AI助手。首次启动会下载所需的机器学习模型主要是BAAI/bge-m3和BGE重排序模型总计约2.5GB所以需要一定时间请保持网络通畅。步骤3访问与验证访问http://localhost:5174你应该能看到前端界面。首先创建一个工作区Workspace然后就可以上传文档进行测试了。4.2 本地开发环境搭建如果你需要二次开发或深度定制本地开发环境能提供更好的调试体验。步骤1运行自动化安装脚本项目提供了一个非常方便的setup.sh脚本它会检查并安装所有前置依赖Python, Node.js, PostgreSQL, ChromaDB等。git clone https://github.com/LeDat98/NexusRAG.git cd NexusRAG ./setup.sh跟着脚本提示操作即可。它会创建Python虚拟环境安装后端和前端依赖并启动本地的PostgreSQL和ChromaDB服务。步骤2分别启动后端和前端# 终端1启动后端服务 (端口 8080) ./run_bk.sh # 终端2启动前端开发服务器 (端口 5174) ./run_fe.sh之后同样通过http://localhost:5174访问。避坑指南模型下载问题首次运行后端时会自动从Hugging Face下载模型。如果网络不稳定可能导致失败。你可以手动提前下载BAAI/bge-m3和BAAI/bge-reranker-v2-m3模型文件放到~/.cache/huggingface/hub/对应的目录下。Ollama连接问题在Docker中使用Ollama时OLLAMA_HOST不能设为localhost因为localhost指向容器内部。应设为host.docker.internalMac/Windows或宿主机真实IPLinux。内存不足文档解析尤其是Docling和LLM推理比较耗内存。确保你的开发机或服务器至少有8GB以上可用内存处理复杂PDF时建议16GB。4.3 关键配置项详解.env配置文件是系统的控制中枢理解几个关键配置能帮你更好地调优系统。文档解析器选择 (NEXUSRAG_DOCUMENT_PARSER)docling默认功能全面支持格式多但处理复杂数学公式时可能有LaTeX问题且GPU内存占用高~18-20GB。marker数学公式提取能力更强基于Surya OCRGPU内存占用低~2-4GB但对某些文档格式的支持可能稍弱。建议如果你的文档包含大量数学、科学公式或者GPU资源紧张优先尝试marker。对于常规商业文档docling可能更稳定。检索管道参数NEXUSRAG_VECTOR_PREFETCH20向量搜索初步召回的数量。增加此值会提高召回率但会增加重排序的计算开销。一般20-50是合理范围。NEXUSRAG_RERANKER_TOP_K8重排序后保留的最终片段数量。这个数量会直接作为上下文送给LLM。太多会稀释关键信息并增加token消耗太少可能信息不全。根据你的文档平均长度和LLM上下文窗口调整5-10是常见设置。NEXUSRAG_ENABLE_KGtrue/false是否启用知识图谱。关闭后系统退化为“增强版向量检索”部署更简单但会失去实体关联和多跳推理能力。LLM与生成控制LLM_THINKING_LEVELGemini 3.x控制模型的“思考深度”从minimal到high。越深思考时间越长答案质量可能更高特别是对于复杂问题。可以从medium开始调整。LLM_MAX_OUTPUT_TOKENS8192限制LLM回答的最大长度。需结合你的上下文长度检索到的片段总token数来设置避免超出模型总上下文窗口。5. 核心功能使用技巧与高级场景5.1 利用自定义元数据进行精准过滤这是企业级应用中的一个杀手级功能。你可以在上传文档时附加自定义的键值对元数据如{“department”: “finance”, “year”: “2023”, “project”: “project_alpha”}。在后续查询或聊天时可以指定metadata_filter来缩小搜索范围。使用场景权限隔离不同部门的员工只能查询本部门文档。版本控制只检索最新年份的报告。项目知识库在混合了多个项目文档的知识库中精准定位某个项目的资料。API调用示例上传时附加元数据curl -X POST http://localhost:8080/api/v1/documents/upload/{workspace_id} \ -H accept: application/json \ -H Content-Type: multipart/form-data \ -F fileannual_report.pdf \ -F custom_metadata[{key: year, value: 2023}, {key: type, value: financial}]查询时过滤 在查询或聊天请求的JSON body中加入{ query: 去年的营收是多少, metadata_filter: [ {key: year, value: 2023}, {key: type, value: financial} ] }这样系统会先在ChromaDB中根据元数据过滤出符合条件的文档集合然后只在这个子集中进行语义搜索极大地提升了检索的准确性和效率避免了从无关文档中搜到干扰信息。5.2 知识图谱的实战应用与查询模式知识图谱不是个花架子在NexusRAG中它通过四种查询模式直接影响检索结果混合模式Hybrid默认同时使用向量搜索和知识图谱查询结果融合。这是最全面、效果通常最好的模式。向量模式Vector仅使用向量搜索。相当于关闭KG功能用于对比或诊断问题。局部图谱模式Local KG在知识图谱中从查询匹配到的实体出发进行多跳遍历例如2-3跳找出相关联的其他实体和文本。适合探索性、关联性问题比如“与张三合作过的同事都参与了哪些项目”。系统会先找到“张三”节点然后沿着“合作”关系找到“同事”节点再找到这些同事参与的“项目”节点及其关联文本。全局图谱模式Global KG不进行具体查询而是返回整个知识图谱的摘要视图例如最重要的实体、核心关系等。适合对知识库内容进行宏观摸底。实操建议对于常规的事实问答用混合模式。当你感觉问题涉及多个实体及其关系时可以尝试局部图谱模式它可能发现向量搜索忽略的深层关联。前端界面提供了这四种模式的切换多试试不同模式对同一问题的回答你能更直观地理解KG带来的价值。5.3 工作区Workspace系统实现多租户隔离工作区是NexusRAG进行数据隔离的核心概念。每个工作区完全独立拥有自己的文档集合。独立的ChromaDB向量集合Collection。独立的知识图谱LightRAG实例。独立的聊天历史。可自定义的系统提示词System Prompt。使用场景企业内部为不同团队研发、市场、人事创建独立的工作区数据互不干扰。个人使用为不同主题学习笔记、项目文档、个人日记创建不同工作区。客户项目为每个客户创建一个工作区管理其专属的项目文档和沟通记录。通过工作区你可以在一个NexusRAG实例上安全地管理多个完全隔离的知识库无需部署多套系统。6. 性能调优、问题排查与评估实践6.1 性能瓶颈分析与调优建议在实际使用中你可能会遇到速度慢或效果不佳的情况。以下是常见的瓶颈点及优化思路环节可能瓶颈优化建议文档解析Docling解析大型PDF慢GPU内存不足。1. 切换到marker解析器设置NEXUSRAG_DOCUMENT_PARSERmarker。2. 对于纯文本PDF可考虑在上传前用其他工具如pdftotext先转换为文本再以TXT格式上传。向量检索ChromaDB集合中文档过多检索延迟高。1. 确保对metadata_filter的有效利用缩小检索范围。2. 考虑对ChromaDB集合建立索引如果版本支持。3. 检查NEXUSRAG_VECTOR_PREFETCH值是否过大适当调低。重排序交叉编码器模型推理慢CPU上尤其明显。1. 如果有GPU确保transformers库能使用CUDA。2. 调低NEXUSRAG_VECTOR_PREFETCH如从20降到15减少需要重排序的候选数。3. 在效果可接受的前提下临时关闭重排序需修改代码非配置项。LLM生成Gemini API网络延迟高或本地Ollama模型响应慢。1. 对于Gemini考虑使用延迟更低的区域端点如果可用。2. 对于Ollama升级到更快的模型如gemma4:e2b比e4b快或使用量化版本如qwen2.5:7b-q4_K_M。3. 调整LLM_MAX_OUTPUT_TOKENS避免生成过长内容。知识图谱提取实体和关系提取耗时特别是用大模型时。1. 文档处理是后台任务不影响查询可接受异步处理。2. 如果不需要KG功能可在.env中设置NEXUSRAG_ENABLE_KGfalse以跳过此步骤。6.2 常见问题排查实录问题1上传文档后状态一直卡在“处理中”或失败。检查后端日志运行docker compose logs backend查看具体错误。常见原因解析器失败文档格式解析器不支持或文件已损坏。尝试转换为PDF再上传。LLM调用失败Gemini API Key无效或额度不足Ollama服务未启动或模型未加载。检查.env配置和相应服务状态。内存不足处理大文档时内存耗尽。查看系统资源监控考虑增加内存或分拆文档。问题2问答效果差回答不相关或胡编乱造。诊断步骤检查检索结果在前端搜索界面使用“Vector Only”模式进行查询查看系统召回的前几个文本片段是否真的与问题相关。如果不相关问题出在检索阶段。调整检索参数尝试增加NEXUSRAG_VECTOR_PREFETCH如调到30让更多候选进入重排序环节。检查上下文在聊天回答中点击引用标记查看LLM实际收到的源文本是什么。如果源文本本身信息不足或模糊LLM自然无法生成好答案。这可能需要对文档进行预处理如合并过短的段落、添加更清晰的标题。切换LLM如果检索到的片段很好但答案依然不好可能是LLM能力问题。尝试从本地小模型切换到Gemini看是否有改善。问题3知识图谱可视化中看不到实体和关系。确认KG已启用检查.env中NEXUSRAG_ENABLE_KGtrue。检查文档处理日志文档处理完成后日志中应有“KG extraction completed”类似信息。实体提取依赖LLM如果使用的模型太小如4B参数可能无法有效提取实体。建议为KG提取使用至少7B以上参数的模型。检查图谱查询模式在前端确保选择了“Hybrid”或“Local KG”模式。纯“Vector”模式不会使用KG结果。问题4本地Ollama模型无法进行工具调用Function Calling。确认模型支持确保使用的Ollama模型原生支持工具调用。Gemma 4系列gemma4:e4b和Qwen 3.5系列是已知支持的。使用ollama list查看模型详情。升级Ollama版本工具调用需要Ollama v0.20.0版本的支持。运行ollama --version检查并升级。查看后端探测日志NexusRAG启动时会自动探测Ollama模型是否支持原生工具调用。如果不支持会回退到提示词prompt-based模式效果可能不稳定。6.3 效果评估如何客观衡量你的RAG系统NexusRAG作者提供了两种评估方法这为我们评估自己的部署效果提供了范本。方法一基于规则的测试快速验证核心功能你可以仿照项目中的测试案例针对自己的文档设计一系列问题并定义明确的判断规则。例如事实提取“文档中提到的2023年营收具体数字是多少”检查答案是否与原文完全一致拒答能力“请问明天的天气怎么样”检查系统是否明确拒绝回答无关问题引用格式检查答案中的引用[abcd]格式是否正确且能定位到真实来源。跨文档推理如果上传了A、B两份文档问“A文档中提到的X项目在B文档中的进展如何”检查是否能综合两处信息。方法二使用RAGAS等框架进行自动化评估更全面RAGAS是一个流行的RAG评估框架它可以基于LLM作为裁判自动生成测试问题并从多个维度忠实度、答案相关性、上下文召回率等进行评分。准备一个包含“问题-标准答案-上下文”的测试集。使用你的NexusRAG系统回答这些问题。调用RAGAS或类似框架的评估API将你的答案与标准答案、提供的上下文进行对比得到量化分数。通过对比不同配置如切换LLM、调整重排序Top-K值下的分数来科学地优化你的系统。个人体会不要只看重“答案看起来通顺”。一个RAG系统的好坏忠实度Faithfulness和答案相关性Answer Relevance是更关键的指标。前者衡量是否“胡编乱造”后者衡量是否“答非所问”。在项目初期投入时间建立一个小而精的评估测试集能帮你快速定位问题避免在错误的方向上越走越远。NexusRAG在评估中暴露的“检索覆盖不足”和“LLM在阐述时添加未支持细节”的问题正是大多数RAG系统需要持续攻坚的难点。