从零搭建企业级RAG系统:完整方案设计

为什么大多数RAG项目都失败了 2026年,几乎所有企业都在尝试RAG,但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统,忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块: 1. 数据接入层 文档解析:支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析,对表格使用专门的Table Transformer模型,对图片使用VLM生成描述。 数据源连接器:企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器,支持增量同步和变更检测。 权限映射:企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL(Access Control List),检索时根据用户身份过滤。 2. 文档处理管道 分块策略:分块质量直接决定检索质量。我们采用三级分块策略: 语义分块:按段落和章节边界分块,保持语义完整性 重叠窗口:相邻块之间保留10-20%的重叠,避免边界信息丢失 层级分块:同时生成小块(256 Token)和大块(1024 Token),检索时小块匹配、大块提供上下文 元数据标注:为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择:中文场景推荐BGE-M3或Qwen3-Embedding,英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token,嵌入模型必须能处理这个长度。 向量数据库:根据数据规模选择: <100万块:Qdrant单机版足够,部署简单 100万-1000万块:Milvus集群版,支持水平扩展 1000万块:需要考虑分片策略和混合检索 混合索引:纯向量检索在精确匹配场景(如产品型号、人名搜索)效果差。我们同时建立BM25全文索引,检索时融合向量检索和BM25的结果。 4. 检索层 多路召回: 向量召回:语义相似度检索Top-K 关键词召回:BM25检索Top-K 元数据过滤:根据用户权限和时间范围预过滤 重排序:使用Cross-Encoder模型(如bge-reranker-v2)对召回的50-100个候选项重排序,取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中,加入重排序后答案准确率提升约15%。 查询改写:用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板:精心设计的Prompt模板对RAG质量至关重要。我们的模板包含: 系统指令:定义AI的角色和回答边界 检索上下文:格式化的检索结果,包含来源标注 用户问题:原始用户问题 输出要求:要求引用来源、不确定时说明 幻觉抑制:在Prompt中明确要求"仅基于提供的上下文回答,如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集:每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架:对索引参数、检索策略、Prompt模板的变更进行A/B测试,用数据驱动优化决策。 自动评估流水线:定期使用测试集自动评估系统质量,监控质量回归。 7. 监控与运维层 关键指标: 检索质量:召回率、精确率、MRR 生成质量:答案准确率、幻觉率、引用准确率 系统性能:端到端延迟、吞吐量、错误率 用户满意度:反馈评分、重试率 告警机制:当检索质量或生成质量低于阈值时自动告警,触发排查流程。 部署建议 起步阶段(1-2个月):单机部署,Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段(3-6个月):引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段(6个月+):集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化:一开始就上复杂的GraphRAG或Agentic RAG,连基础RAG都没跑稳 忽视文档质量:垃圾进垃圾出,再好的检索算法也救不了低质量输入 分块策略一刀切:不同类型文档需要不同分块策略 不做重排序:仅靠向量检索的Top-K效果往往不够 没有评估体系:没有量化指标就无法判断优化是否有效 RAG不是一个项目,而是一个持续优化的工程。做好长期投入的准备,才能真正让它成为企业的知识引擎。 ...

2026-07-12 · 1 min · 78 words · 硅基 AGI 探索者

从零搭建企业级RAG系统:完整方案设计

为什么大多数RAG项目都失败了 2026年,几乎所有企业都在尝试RAG,但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统,忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块: 1. 数据接入层 文档解析:支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析,对表格使用专门的Table Transformer模型,对图片使用VLM生成描述。 数据源连接器:企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器,支持增量同步和变更检测。 权限映射:企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL(Access Control List),检索时根据用户身份过滤。 2. 文档处理管道 分块策略:分块质量直接决定检索质量。我们采用三级分块策略: 语义分块:按段落和章节边界分块,保持语义完整性 重叠窗口:相邻块之间保留10-20%的重叠,避免边界信息丢失 层级分块:同时生成小块(256 Token)和大块(1024 Token),检索时小块匹配、大块提供上下文 元数据标注:为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择:中文场景推荐BGE-M3或Qwen3-Embedding,英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token,嵌入模型必须能处理这个长度。 向量数据库:根据数据规模选择: <100万块:Qdrant单机版足够,部署简单 100万-1000万块:Milvus集群版,支持水平扩展 1000万块:需要考虑分片策略和混合检索 混合索引:纯向量检索在精确匹配场景(如产品型号、人名搜索)效果差。我们同时建立BM25全文索引,检索时融合向量检索和BM25的结果。 4. 检索层 多路召回: 向量召回:语义相似度检索Top-K 关键词召回:BM25检索Top-K 元数据过滤:根据用户权限和时间范围预过滤 重排序:使用Cross-Encoder模型(如bge-reranker-v2)对召回的50-100个候选项重排序,取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中,加入重排序后答案准确率提升约15%。 查询改写:用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板:精心设计的Prompt模板对RAG质量至关重要。我们的模板包含: 系统指令:定义AI的角色和回答边界 检索上下文:格式化的检索结果,包含来源标注 用户问题:原始用户问题 输出要求:要求引用来源、不确定时说明 幻觉抑制:在Prompt中明确要求"仅基于提供的上下文回答,如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集:每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架:对索引参数、检索策略、Prompt模板的变更进行A/B测试,用数据驱动优化决策。 自动评估流水线:定期使用测试集自动评估系统质量,监控质量回归。 7. 监控与运维层 关键指标: 检索质量:召回率、精确率、MRR 生成质量:答案准确率、幻觉率、引用准确率 系统性能:端到端延迟、吞吐量、错误率 用户满意度:反馈评分、重试率 告警机制:当检索质量或生成质量低于阈值时自动告警,触发排查流程。 部署建议 起步阶段(1-2个月):单机部署,Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段(3-6个月):引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段(6个月+):集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化:一开始就上复杂的GraphRAG或Agentic RAG,连基础RAG都没跑稳 忽视文档质量:垃圾进垃圾出,再好的检索算法也救不了低质量输入 分块策略一刀切:不同类型文档需要不同分块策略 不做重排序:仅靠向量检索的Top-K效果往往不够 没有评估体系:没有量化指标就无法判断优化是否有效 RAG不是一个项目,而是一个持续优化的工程。做好长期投入的准备,才能真正让它成为企业的知识引擎。 ...

2026-07-12 · 1 min · 78 words · 硅基 AGI 探索者

从RAG到GraphRAG:知识检索的范式跃迁

向量检索的天花板 传统RAG系统依赖向量相似度检索,在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时,纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职,那家公司又被谁收购了"这样的问题,需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段,无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于:在传统的向量索引之上,叠加一层知识图谱索引。具体流程分为四个阶段: 实体抽取:使用LLM从文档中抽取实体和关系,构建知识图谱。每个实体作为图节点,实体间关系作为边。 社区发现:对知识图谱运行社区检测算法(如Leiden算法),将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索:查询时同时进行向量检索和图遍历。向量检索找到相关文档片段,图遍历沿着实体关系路径发现关联信息。 答案生成:将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计: 索引阶段采用两遍处理——第一遍抽取实体和关系,第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题(叶子社区),也能回答宏观问题(根社区)。 查询阶段区分了local search和global search。local search针对具体实体相关问题,从实体邻域出发检索;global search针对全局性问题,直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中,我们发现了几个关键的trade-off: 索引成本显著增加。 相比纯向量RAG,GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库,索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时,不仅要更新向量索引,还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景,纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势:RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器,而是主动的知识探索者——它能根据问题复杂度自主选择检索策略,在检索结果不足时自主发起多轮检索,甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始,GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 32 words · 硅基 AGI 探索者

从RAG到GraphRAG:知识检索的范式跃迁

向量检索的天花板 传统RAG系统依赖向量相似度检索,在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时,纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职,那家公司又被谁收购了"这样的问题,需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段,无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于:在传统的向量索引之上,叠加一层知识图谱索引。具体流程分为四个阶段: 实体抽取:使用LLM从文档中抽取实体和关系,构建知识图谱。每个实体作为图节点,实体间关系作为边。 社区发现:对知识图谱运行社区检测算法(如Leiden算法),将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索:查询时同时进行向量检索和图遍历。向量检索找到相关文档片段,图遍历沿着实体关系路径发现关联信息。 答案生成:将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计: 索引阶段采用两遍处理——第一遍抽取实体和关系,第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题(叶子社区),也能回答宏观问题(根社区)。 查询阶段区分了local search和global search。local search针对具体实体相关问题,从实体邻域出发检索;global search针对全局性问题,直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中,我们发现了几个关键的trade-off: 索引成本显著增加。 相比纯向量RAG,GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库,索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时,不仅要更新向量索引,还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景,纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势:RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器,而是主动的知识探索者——它能根据问题复杂度自主选择检索策略,在检索结果不足时自主发起多轮检索,甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始,GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 32 words · 硅基 AGI 探索者
RAG框架对比

RAG框架对比2026:检索增强生成的最佳选择

引言 RAG(检索增强生成)是企业LLM应用最核心的技术。2026年,RAG框架已经从简单的"检索+生成"发展为包含查询重写、混合检索、重排序、上下文管理等完整技术链的复杂系统。本文将全面对比主流RAG框架。 参评框架 框架 版本 特点 适合场景 Haystack 2.6 企业级,Pipeline架构 企业RAG LlamaIndex 0.6 数据驱动,丰富索引 数据密集型 LangChain 0.3 通用框架,生态丰富 通用应用 RAGFlow 1.2 专注RAG,深度优化 纯RAG场景 DSPy 0.5 编程式RAG 研究型 核心能力对比 文档处理 能力 Haystack LlamaIndex LangChain RAGFlow PDF解析 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 表格识别 ★★★★☆ ★★★☆☆ ★★☆☆☆ ★★★★★ 图文混合 ★★★★☆ ★★★☆☆ ★★☆☆☆ ★★★★☆ 分块策略 ★★★★★ ★★★★★ ★★★☆☆ ★★★★☆ 多格式支持 ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ 检索能力 能力 Haystack LlamaIndex LangChain RAGFlow 稠密检索 ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ 稀疏检索 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 混合检索 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 重排序 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★☆ 多跳检索 ★★★★☆ ★★★★★ ★★★☆☆ ★★★☆☆ 生成质量 使用相同的检索结果,评估各框架的生成质量: ...

2026-07-02 · 2 min · 409 words · 硅基 AGI 探索者
LlamaIndex指南

LlamaIndex 2026指南:数据驱动的LLM应用

引言 LlamaIndex是专注于"将私有数据连接到LLM"的框架。2026年的LlamaIndex已经从简单的RAG工具发展为一个完整的数据驱动LLM应用平台。本文将全面介绍LlamaIndex 2026的使用。 核心概念 数据连接器 from llama_index.readers import ( PDFReader, WebPageReader, NotionReader, GitHubReader, DatabaseReader ) # 多种数据源 documents = PDFReader().load_data("report.pdf") web_docs = WebPageReader().load_data(["https://example.com"]) db_docs = DatabaseReader(uri="postgresql://...").load_data("SELECT * FROM articles") 索引 from llama_index.core import VectorStoreIndex, SummaryIndex, TreeIndex # 向量索引(最常用) vector_index = VectorStoreIndex.from_documents(documents) # 摘要索引(适合长文档) summary_index = SummaryIndex.from_documents(documents) # 树索引(适合层次化数据) tree_index = TreeIndex.from_documents(documents) # 关键词索引 from llama_index.core import KeywordTableIndex keyword_index = KeywordTableIndex.from_documents(documents) 查询引擎 # 基本查询 query_engine = vector_index.as_query_engine(similarity_top_k=5) response = query_engine.query("什么是AI?") # 流式查询 streaming_engine = vector_index.as_query_engine(streaming=True) response = streaming_engine.query("什么是AI?") for text in response.response_gen: print(text, end="") # 子问题查询 from llama_index.core.tools import QueryEngineTool from llama_index.core.query_engine import SubQuestionQueryEngine tools = [ QueryEngineTool.from_defaults( query_engine=vector_index, name="文档查询", description="查询内部文档" ) ] sub_engine = SubQuestionQueryEngine.from_defaults(query_engine_tools=tools) response = sub_engine.query("比较文档A和文档B的观点") 2026年新特性 1. LlamaCloud from llama_index.cloud import LlamaCloud # 云端索引管理 cloud = LlamaCloud(api_key="...") index = cloud.create_index( name="my-index", documents=documents, embed_model="bge-large-zh" ) 2. Agent支持 from llama_index.agent import FunctionAgent agent = FunctionAgent( tools=[ query_engine_tool, web_search_tool, code_execution_tool ], llm="gpt-5", system_prompt="你是一个研究助手..." ) response = agent.chat("分析最新的AI趋势并生成报告") 3. 工作流 from llama_index.workflow import Workflow, step class RAGWorkflow(Workflow): @step def retrieve(self, ctx, query): documents = self.retriever.retrieve(query) ctx.data["documents"] = documents return ctx @step def generate(self, ctx): response = self.llm.complete( prompt=ctx.data["query"], context=ctx.data["documents"] ) return response workflow = RAGWorkflow() result = await workflow.run("什么是AI?") 4. 多模态 from llama_index.multi_modal import MultiModalIndex # 多模态索引 mm_index = MultiModalIndex.from_documents( documents=[text_docs, image_docs, table_docs] ) RAG最佳实践 分块策略 from llama_index.core.node_parser import ( SentenceSplitter, SemanticSplitter, HierarchicalNodeParser ) # 句子分割 splitter = SentenceSplitter(chunk_size=500, chunk_overlap=50) # 语义分割 splitter = SemanticSplitter( embed_model=embed_model, buffer_size=1, breakpoint_percentile_threshold=95 ) # 层次化分割 splitter = HierarchicalNodeParser.from_defaults( chunk_sizes=[2048, 512, 128] # 三级层次 ) 检索优化 from llama_index.core.retrievers import ( VectorIndexRetriever, BM25Retriever, QueryFusionRetriever ) # 混合检索 vector_retriever = VectorIndexRetriever(index=vector_index, similarity_top_k=10) bm25_retriever = BM25Retriever.from_defaults(index=vector_index, similarity_top_k=10) fusion_retriever = QueryFusionRetriever( retrievers=[vector_retriever, bm25_retriever], num_queries=3, # 查询扩展 mode="reciprocal_rerank" ) 重排序 from llama_index.core.postprocessor import SentenceTransformerRerank reranker = SentenceTransformerRerank( model="bge-reranker-v2", top_n=5 ) query_engine = vector_index.as_query_engine( similarity_top_k=20, # 先检索20个 node_postprocessors=[reranker] # 重排序取5个 ) 上下文增强 from llama_index.core.indices.query.schema import QueryBundle # 查询重写 class QueryRewriter: def rewrite(self, query): prompt = f"将以下查询重写为更清晰的表述:\n{query}" return llm.complete(prompt).text # 在查询前重写 rewritten = QueryRewriter().rewrite("AI怎么样") response = query_engine.query(QueryBundle(rewritten)) 评估 from llama_index.core.evaluation import ( FaithfulnessEvaluator, RelevancyEvaluator, CorrectnessEvaluator ) # 评估RAG效果 faithfulness = FaithfulnessEvaluator(llm=eval_llm) relevancy = RelevancyEvaluator(llm=eval_llm) # 评估单个查询 faith_result = faithfulness.evaluate_response( query=query, response=response ) # faith_result.passing: True/False 部署 API服务 from llama_index.core.server import LlamaIndexServer server = LlamaIndexServer( query_engine=query_engine, port=8000 ) server.start() 批量处理 import asyncio async def batch_query(queries): tasks = [query_engine.aquery(q) for q in queries] results = await asyncio.gather(*tasks) return results 结语 LlamaIndex在2026年仍然是数据驱动LLM应用的首选框架。它的数据连接器丰富、索引类型多样、查询引擎灵活,特别适合需要处理大量私有数据的场景。 ...

2026-07-02 · 2 min · 393 words · 硅基 AGI 探索者
RAG vs 微调决策

RAG还是微调:决策框架

不是非此即彼 RAG和微调不是互斥的选择,而是互补的技术。很多场景下,两者结合使用效果最佳。关键在于理解各自的优势和局限,根据具体需求做出合理选择。 决策矩阵 ┌──────────────────────────────────┐ │ 知识更新频率 │ │ 低 中 高 │ ┌──────────┼──────────┬──────────┬────────────┤ 知识 │ 私有 │ 微调 │ RAG │ RAG │ 特有性 │ 公开 │ 微调 │ RAG │ Prompt │ 量 │ 大量 │ RAG │ RAG │ RAG │ │ 少量 │ 微调 │ 微调 │ Prompt │ └──────────┴──────────┴──────────┴────────────┘ 何时用RAG 适合场景: 知识库频繁更新(如产品文档、新闻) 需要精确引用来源 大量私有文档(数千篇以上) 需要多跳推理 # RAG的典型应用:企业知识库问答 class EnterpriseQABot: def __init__(self): self.retriever = VectorRetriever(documents=company_docs) self.llm = LLM(model="qwen3-32b") async def answer(self, question): docs = await self.retriever.search(question, top_k=5) context = "\n".join(d.content for d in docs) prompt = f"""基于以下参考资料回答问题。 参考资料: {context} 问题:{question} 要求标注引用来源。""" return await self.llm.generate(prompt) RAG优势: ...

2026-07-02 · 2 min · 340 words · 硅基 AGI 探索者
Haystack RAG

Haystack 2026 RAG实践:企业级检索增强生成

引言 Haystack是deepset开发的企业级NLP框架,在RAG领域有着深厚积累。2026年的Haystack已经发展成为一个完整的RAG解决方案框架。本文将分享Haystack在RAG实践中的经验。 Haystack 2026架构 Pipeline设计 from haystack import Pipeline from haystack.components.embedders import OllamaEmbedder from haystack.components.retrievers import ChromaRetriever from haystack.components.generators import OpenAIGenerator # 构建RAG Pipeline pipe = Pipeline() # 添加组件 pipe.add_component("embedder", OllamaEmbedder(model="bge-large-zh")) pipe.add_component("retriever", ChromaRetriever(top_k=5)) pipe.add_component("generator", OpenAIGenerator(model="gpt-5")) # 连接组件 pipe.connect("embedder.embedding", "retriever.query_embedding") pipe.connect("retriever.documents", "generator.documents") 文档处理 from haystack.components.converters import PDFToDocument, MarkdownToDocument from haystack.components.preprocessors import DocumentSplitter, DocumentCleaner # 文档转换pipeline indexing = Pipeline() # 转换器 indexing.add_component("pdf_converter", PDFToDocument()) indexing.add_component("md_converter", MarkdownToDocument()) # 预处理 indexing.add_component("cleaner", DocumentCleaner()) indexing.add_component("splitter", DocumentSplitter( split_by="word", split_length=500, split_overlap=50 )) # 嵌入 indexing.add_component("embedder", OllamaEmbedder(model="bge-large-zh")) indexing.add_component("writer", ChromaDocumentWriter()) # 连接 indexing.connect("pdf_converter.documents", "cleaner.documents") indexing.connect("cleaner.documents", "splitter.documents") indexing.connect("splitter.documents", "embedder.documents") indexing.connect("embedder.documents", "writer.documents") RAG优化实践 实践一:混合检索 from haystack.components.retrievers import ( ChromaRetriever, # 稠密检索 BM25Retriever # 稀疏检索 ) from haystack.components.joiners import DocumentJoiner # 混合检索pipeline hybrid_pipe = Pipeline() # 稠密检索 hybrid_pipe.add_component("dense_embedder", OllamaEmbedder(model="bge-large-zh")) hybrid_pipe.add_component("dense_retriever", ChromaRetriever(top_k=20)) # 稀疏检索 hybrid_pipe.add_component("sparse_retriever", BM25Retriever(top_k=20)) # 融合 hybrid_pipe.add_component("joiner", DocumentJoiner(join_mode="reciprocal_rank_fusion")) # 重排序 hybrid_pipe.add_component("reranker", SentenceTransformersRanker(model="bge-reranker-v2", top_k=5)) 实践二:查询扩展 from haystack.components.generators import OpenAIGenerator # 查询扩展组件 class QueryExpander: def __init__(self, llm): self.llm = llm def expand(self, query): prompt = f"请将以下查询扩展为3个不同表述:\n{query}" response = self.llm.run(prompt) return parse_queries(response) def run(self, query): expanded = self.expand(query) return {"queries": expanded} # 在pipeline中使用 pipe.add_component("expander", QueryExpander(llm=OpenAIGenerator())) 实践三:分块策略优化 from haystack.components.preprocessors import DocumentSplitter # 语义分块(基于段落) splitter = DocumentSplitter( split_by="paragraph", split_length=1, split_overlap=0 ) # 滑动窗口分块 splitter = DocumentSplitter( split_by="word", split_length=300, split_overlap=50 # 50词重叠 ) # 基于标题的分块 class HeadingBasedSplitter: def split(self, document): # 按Markdown标题分块 sections = re.split(r'^#+\s', document.content, flags=re.MULTILINE) return [Document(content=s.strip()) for s in sections if s.strip()] 实践四:上下文管理 # 上下文窗口管理 class ContextWindowManager: def __init__(self, max_tokens=4000): self.max_tokens = max_tokens def select_context(self, documents, query): """选择最相关的上下文,不超过token限制""" selected = [] token_count = 0 for doc in documents: doc_tokens = count_tokens(doc.content) if token_count + doc_tokens > self.max_tokens: # 截断最后一个文档 remaining = self.max_tokens - token_count if remaining > 100: # 至少100 token才包含 doc.content = doc.content[:remaining] selected.append(doc) break selected.append(doc) token_count += doc_tokens return selected 实践五:答案溯源 # 带来源标注的生成 class SourcedGenerator: def __init__(self, llm): self.llm = llm def run(self, query, documents): # 构造带来源编号的提示 context = "" for i, doc in enumerate(documents): context += f"[{i+1}] {doc.content}\n\n" prompt = f""" 基于以下参考信息回答问题。在回答中标注信息来源。 参考信息: {context} 问题:{query} 回答格式:答案内容[来源编号] """ response = self.llm.run(prompt) return {"answer": response} 企业级功能 权限控制 class AccessControlledRetriever: def __init__(self, retriever, acl): self.retriever = retriever self.acl = acl # 访问控制列表 def run(self, query, user_id): # 检索 documents = self.retriever.run(query) # 过滤:只返回用户有权限的文档 accessible = [ doc for doc in documents if self.acl.has_access(user_id, doc.metadata.get("doc_id")) ] return {"documents": accessible} 多租户 class MultiTenantStore: def __init__(self): self.stores = {} # tenant_id -> vector_store def get_store(self, tenant_id): if tenant_id not in self.stores: self.stores[tenant_id] = ChromaStore( collection_name=f"tenant_{tenant_id}" ) return self.stores[tenant_id] 缓存 from haystack.components.cachers import CacheChecker pipe.add_component("cache_checker", CacheChecker( cache_store=RedisCache(), cache_key="{{query}}" )) 2026年新特性 1. 多模态RAG from haystack.components.embedders import CLIPEmbedder # 图文混合RAG pipe.add_component("image_embedder", CLIPEmbedder()) pipe.add_component("text_embedder", OllamaEmbedder(model="bge-large-zh")) 2. 自适应检索 class AdaptiveRetriever: """根据查询复杂度自适应选择检索策略""" def run(self, query): complexity = self.assess_complexity(query) if complexity == "simple": return self.simple_retrieve(query) elif complexity == "medium": return self.hybrid_retrieve(query) else: return self.multi_hop_retrieve(query) 3. 评估集成 from haystack.components.evaluators import ( FaithfulnessEvaluator, AnswerRelevanceEvaluator, ContextRelevanceEvaluator ) # 在pipeline末尾加入评估 pipe.add_component("faithfulness", FaithfulnessEvaluator()) pipe.add_component("relevance", AnswerRelevanceEvaluator()) 性能对比 框架 索引速度 检索延迟 RAG准确率 功能丰富度 Haystack ★★★★☆ ★★★★☆ ★★★★★ ★★★★★ LlamaIndex ★★★★★ ★★★★☆ ★★★★☆ ★★★★☆ LangChain ★★★☆☆ ★★★☆☆ ★★★☆☆ ★★★★★ 结语 Haystack在2026年仍然是企业级RAG的首选框架。其Pipeline架构清晰、组件丰富、可扩展性强,特别适合需要精细控制RAG流程的企业应用。 ...

2026-07-02 · 3 min · 494 words · 硅基 AGI 探索者
RAG管线优化

RAG管线优化2026实战

RAG的核心挑战 RAG(检索增强生成)让LLM能够基于私有知识回答问题。但一个简单的RAG原型——文档切块→向量化→相似度检索→拼接到prompt——在实际使用中往往效果不佳。2026年的RAG优化需要从文档处理、检索质量、上下文管理和生成控制四个维度系统提升。 文档处理优化 智能分块 from langchain.text_splitter import RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter class SmartChunker: def __init__(self, chunk_size=512, chunk_overlap=64): self.chunk_size = chunk_size self.chunk_overlap = chunk_overlap # 通用分割器 self.general_splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=chunk_overlap, separators=["\n\n", "\n", "。", "!", "?", ".", "!", "?", " ", ""] ) # Markdown分割器 self.md_splitter = MarkdownHeaderTextSplitter( headers_to_split_on=[ ("#", "Header 1"), ("##", "Header 2"), ("###", "Header 3"), ] ) def chunk(self, text, doc_type="auto"): if doc_type == "auto": doc_type = self.detect_type(text) if doc_type == "markdown": # 先按标题分块,再按大小细分 md_chunks = self.md_splitter.split_text(text) final_chunks = [] for chunk in md_chunks: if len(chunk.page_content) > self.chunk_size * 2: sub_chunks = self.general_splitter.split_text(chunk.page_content) for sc in sub_chunks: sc.metadata = chunk.metadata final_chunks.append(sc) else: final_chunks.append(chunk) return final_chunks else: return self.general_splitter.split_text(text) def detect_type(self, text): md_indicators = ["# ", "## ", "- [", "```", "| "] if any(ind in text[:500] for ind in md_indicators): return "markdown" return "text" 表格与代码处理 class TableAwareChunker: """避免在表格中间切分""" def chunk(self, text): # 识别表格区域 table_pattern = r'(\|[^\n]+\|\n)+' chunks = [] last_end = 0 for match in re.finditer(table_pattern, text): # 表格前的文本正常切分 pre_text = text[last_end:match.start()] if pre_text.strip(): chunks.extend(self.split_text(pre_text)) # 表格作为完整块 chunks.append(text[match.start():match.end()]) last_end = match.end() # 剩余文本 if last_end < len(text): chunks.extend(self.split_text(text[last_end:])) return chunks 向量化优化 多向量表示 from sentence_transformers import SentenceTransformer class MultiVectorEncoder: def __init__(self): self.dense_model = SentenceTransformer('BAAI/bge-large-zh-v1.5') # 稀疏向量用于关键词匹配 self.sparse_model = None # 使用BM25或SPLADE def encode(self, text): # 密集向量:语义相似度 dense_vec = self.dense_model.encode(text, normalize_embeddings=True) # 稀疏向量:精确匹配 sparse_vec = self.sparse_model.encode(text) if self.sparse_model else None return { "dense": dense_vec, "sparse": sparse_vec, "text": text } 查询扩展 class QueryExpander: def __init__(self, llm): self.llm = llm async def expand(self, query): """使用LLM扩展查询""" prompt = f"""将以下查询改写为3个不同角度的表述,用于检索: 原始查询:{query} 输出格式: 1. [改写1] 2. [改写2] 3. [改写3]""" response = await self.llm.ainvoke(prompt) expansions = self.parse_expansions(response) expansions.append(query) # 保留原始查询 return expansions def parse_expansions(self, text): lines = text.strip().split('\n') return [line.split('.', 1)[1].strip() for line in lines if '.' in line] 检索优化 混合检索 import numpy as np class HybridRetriever: def __init__(self, vector_store, bm25_store, alpha=0.7): self.vector_store = vector_store # 密集向量检索 self.bm25_store = bm25_store # BM25稀疏检索 self.alpha = alpha # 混合权重 async def retrieve(self, query, k=5): # 密集检索 dense_results = await self.vector_store.asimilarity_search_with_score( query, k=k*2 ) # 稀疏检索 sparse_results = self.bm25_store.search(query, k=k*2) # 分数归一化 dense_scores = self.normalize_scores([s for _, s in dense_results]) sparse_scores = self.normalize_scores([s for _, s in sparse_results]) # 混合排序 combined = {} for (doc, _), score in zip(dense_results, dense_scores): doc_id = doc.metadata["id"] combined[doc_id] = combined.get(doc_id, 0) + self.alpha * score combined.setdefault(f"{doc_id}_doc", doc) for (doc, _), score in zip(sparse_results, sparse_scores): doc_id = doc.metadata["id"] combined[doc_id] = combined.get(doc_id, 0) + (1 - self.alpha) * score combined.setdefault(f"{doc_id}_doc", doc) # 排序返回top-k sorted_ids = sorted( [k for k in combined if not k.endswith("_doc")], key=lambda x: combined[x], reverse=True )[:k] return [combined[f"{did}_doc"] for did in sorted_ids] def normalize_scores(self, scores): if not scores: return [] scores = np.array(scores) if scores.max() > scores.min(): return (scores - scores.min()) / (scores.max() - scores.min()) return np.ones_like(scores) 重排序 from sentence_transformers import CrossEncoder class Reranker: def __init__(self, model_name="BAAI/bge-reranker-large"): self.model = CrossEncoder(model_name) def rerank(self, query, documents, top_k=5): # 构建query-document对 pairs = [(query, doc.page_content) for doc in documents] # 计算相关性分数 scores = self.model.predict(pairs) # 排序 ranked = sorted(zip(documents, scores), key=lambda x: x[1], reverse=True) return [doc for doc, _ in ranked[:top_k]] 上下文管理 动态上下文窗口 class ContextManager: def __init__(self, max_tokens=4096): self.max_tokens = max_tokens def build_context(self, query, retrieved_docs, conversation_history=None): # 预留生成空间 context_budget = self.max_tokens - 512 # 分配:历史对话30%,检索文档70% history_budget = int(context_budget * 0.3) docs_budget = context_budget - history_budget # 构建历史上下文 history_text = self.build_history(conversation_history, history_budget) # 构建文档上下文(按相关性排序) docs_text = self.build_docs(retrieved_docs, docs_budget) # 组装最终prompt context = f""" ## 历史对话 {history_text} ## 相关知识 {docs_text} ## 用户问题 {query} """ return context def build_docs(self, docs, budget): result = [] current_tokens = 0 for i, doc in enumerate(docs): doc_text = f"[{i+1}] {doc.page_content}\n" doc_tokens = len(doc_text) // 4 # 粗略估计 if current_tokens + doc_tokens > budget: break result.append(doc_text) current_tokens += doc_tokens return "\n".join(result) 引用标注 class CitationGenerator: def __init__(self, llm): self.llm = llm async def generate_with_citations(self, query, retrieved_docs): # 为每个文档分配编号 docs_context = "\n\n".join([ f"[{i+1}] {doc.page_content}" for i, doc in enumerate(retrieved_docs) ]) prompt = f"""基于以下参考资料回答问题。在回答中使用 [编号] 标注信息来源。 参考资料: {docs_context} 问题:{query} 要求: 1. 只使用参考资料中的信息 2. 用 [编号] 标注每条信息的来源 3. 如果资料中没有相关信息,说明"根据现有资料无法回答" """ response = await self.llm.ainvoke(prompt) return response 评估与迭代 RAG评估指标 class RAGEvaluator: def __init__(self, llm): self.llm = llm async def evaluate(self, query, response, retrieved_docs, ground_truth=None): metrics = {} # 1. 检索相关性 metrics["retrieval_relevance"] = await self.eval_retrieval( query, retrieved_docs ) # 2. 回答忠实度(是否基于检索内容) metrics["faithfulness"] = await self.eval_faithfulness( response, retrieved_docs ) # 3. 回答完整性 if ground_truth: metrics["completeness"] = await self.eval_completeness( response, ground_truth ) return metrics async def eval_faithfulness(self, response, docs): """评估回答是否忠实于检索内容""" prompt = f"""判断以下回答是否完全基于给定的参考资料。 参考资料:{' '.join(d.page_content[:200] for d in docs)} 回答:{response} 请输出: 1. 忠实/不忠实 2. 不忠实的部分(如有) """ result = await self.llm.ainvoke(prompt) return "忠实" in result 结语 RAG管线优化是一个系统性工程,从文档分块到检索策略、从上下文管理到生成控制,每个环节都需要精心设计。2026年的RAG最佳实践强调混合检索、重排序、动态上下文管理和引用标注——这些技术组合使用可以显著提升RAG系统的准确性和可靠性。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

2026-07-02 · 4 min · 748 words · 硅基 AGI 探索者
嵌入模型选型

嵌入模型选型2026:向量化的艺术与科学

引言 嵌入模型是RAG系统、语义搜索和推荐系统的基石。虽然不如生成模型那样引人注目,但嵌入模型的质量直接决定了上游应用的效果上限。2026年,嵌入模型在多语言、长文本和领域特化方面取得了显著进步。本文将为你提供全面的选型指南。 为什么嵌入模型很重要 嵌入模型将文本转化为高维向量,使得语义相似的文本在向量空间中距离更近。这个看似简单的操作是以下应用的核心: RAG系统:通过向量检索找到相关文档 语义搜索:理解用户查询的真实意图 推荐系统:基于内容相似度推荐 聚类分析:发现文本集合中的主题结构 去重与匹配:识别语义重复内容 嵌入模型的质量提升10%,可能带来RAG系统端到端效果提升20-30%。 主流嵌入模型 商业API OpenAI text-embedding-4-large — 3072维,综合最强 Voyage AI voyage-3 — 2048维,检索特化 Cohere Embed v4 — 1536维,多语言强 Google text-gecko-3 — 768维,速度快 开源模型 BGE-large-zh-v2 (智源) — 1024维,中文最强 E5-mistral-7b (微软) — 4096维,英文最强 GTE-large-zh (阿里) — 1024维,中文优秀 Jina embeddings v3 (Jina AI) — 1024维,长文本强 Nomic embed v2 (Nomic) — 768维,开源可复现 BGE-M3 (智源) — 1024维,多语言+多功能 核心基准对比 MTEB 2026 MTEB(Massive Text Embedding Benchmark)是最权威的嵌入模型评估基准: 英文检索 模型 维度 得分 特点 voyage-3 2048 72.8 检索之王 text-embedding-4-large 3072 71.5 综合最佳 E5-mistral-7b 4096 70.3 开源英文最佳 Cohere Embed v4 1536 69.7 多语言均衡 Jina embeddings v3 1024 68.5 长文本强 Nomic embed v2 768 66.2 轻量高效 中文检索 模型 维度 得分 特点 BGE-large-zh-v2 1024 74.5 中文之王 GTE-large-zh 1024 72.8 中文优秀 BGE-M3 1024 71.3 多语言兼中文 text-embedding-4-large 3072 70.2 商业中文最佳 Cohere Embed v4 1536 68.7 长文本检索 在处理长文档(>8K tokens)的检索任务上: ...

2026-07-02 · 2 min · 285 words · 硅基 AGI 探索者
鲁ICP备2026018361号