RAG

长尾问题：AI知识的冰山模型 AI模型的知识像一座冰山——水面之上是常见知识（高频、大量训练数据覆盖），水面之下是长尾知识（低频、训练数据稀少）。 GPT-6能回答关于Python编程、美国历史、量子力学的常见问题——这是冰山之上。但当被问到"15世纪蒙古萨满教的具体仪式"或"某种罕见遗传病的最新治疗方案"时，AI的表现急剧下降——这是冰山之下。 长尾知识的重要性 为什么长尾很重要 专业性：专家工作中最需要的就是长尾知识 创新性：突破性创新往往来自长尾领域的交叉 公平性：罕见疾病患者、少数族裔语言、小众领域——AI在这些领域的无能会造成实际伤害 可靠性：如果AI在长尾问题上"幻觉"，用户可能无法识别（因为用户也不懂） 长尾知识的类型 类型1：罕见但存在 罕见病（发病率<1/10000的疾病） 小众语言（使用人数<10万的语言） 冷门历史事件 类型2：新产生 2026年最新发表的论文 刚刚发生的新闻 新发布的软件版本 类型3：专业深度 某个特定法律条文的具体适用 某种材料的特定合成条件 某个算法在特定硬件上的优化参数 类型4：隐性知识 无法用文字充分描述的技能 行业内部的"潜规则" 需要实践经验才能理解的知识 当前AI在长尾上的表现 量化评估 知识频率 AI准确率 人类专家准确率 前1%（常见） 94.2% 92.1% 前1-5% 87.3% 88.5% 前5-20% 72.1% 79.3% 后20%（长尾） 41.6% 65.2% 在长尾知识上，AI的准确率急剧下降，而人类专家虽然也有下降，但幅度小得多。 典型问题 1. 幻觉 在长尾问题上，AI倾向于"编造"看似合理但实际错误的答案。因为训练数据稀少，模型无法区分"知道"和"不知道"。 2. 过度泛化 AI将常见知识错误地泛化到罕见场景： 罕见病的症状被误诊为常见病 小众语言的语法被按主流语言处理 冷门法律被按主流法律解释 3. 置信度校准失败 AI在长尾问题上的置信度通常过高——它"不知道自己不知道"。这比"不知道"更危险，因为用户可能信任高置信度的错误答案。 解决方案 1. 检索增强生成（RAG） 最直接的方案——在生成答案前检索外部知识库： 用户问题 → 判断是否需要外部知识 → 检索相关文档 → 结合检索结果生成答案 2026年RAG的改进： 多跳检索：支持多步骤的信息检索 混合检索：向量检索+关键词检索+语义重排序 自适应检索：根据问题难度调整检索深度 实时检索：连接实时数据源获取最新信息 局限：RAG的效果取决于外部知识库的覆盖度和质量。对于非常冷门的知识，可能根本没有可检索的文档。 ...

引言 基础RAG（检索-增强-生成）已经成为了AI应用的标配：用户提问→检索相关文档→LLM基于文档生成回答。但这种简单模式在面对复杂问题时力不从心。 2026年，RAG架构已经演进出多种高级模式：多跳检索、自适应检索、推理增强检索、迭代检索等。这些模式让RAG系统能够处理更复杂的问题、提供更准确的答案。本文将系统介绍这些高级模式。 一、基础RAG的局限 1.1 单次检索不够 复杂问题需要多步推理和多轮检索： 问题: "对比GPT-4和Claude在代码生成任务上的表现" 基础RAG: 一次检索"GPT-4 Claude 代码生成对比" → 可能找不到直接的对比文档 高级RAG: 检索1: "GPT-4 代码生成性能" 检索2: "Claude 代码生成性能" 检索3: "GPT-4 vs Claude benchmark" → 综合多个来源生成对比 1.2 检索质量不稳定 简单向量检索可能返回语义相关但信息不足的文档。 1.3 缺乏推理能力 基础RAG是"检索+拼接"，缺乏对检索结果的推理和整合。 二、多跳检索 2.1 原理 多跳检索（Multi-hop Retrieval）通过多轮检索逐步收集信息，每轮检索基于前一轮的结果。 问题: "那位发明了Transformer的作者后来创立了哪家公司？" 跳1: 检索"Transformer论文作者" → 得到作者列表（包括Ashish Vaswani等） 跳2: 检索"Ashish Vaswani 创立公司" → 得到Adept AI 答案: Adept AI 2.2 实现 class MultiHopRetriever: def __init__(self, retriever, llm, max_hops=3): self.retriever = retriever self.llm = llm self.max_hops = max_hops async def retrieve(self, question): accumulated_context = [] for hop in range(self.max_hops): # 1. 根据当前上下文生成下一步检索查询 if hop == 0: query = question else: query = await self.generate_next_query( question, accumulated_context ) if query is None: # 不需要更多检索 break # 2. 执行检索 results = await self.retriever.search(query, top_k=5) # 3. 过滤和评估结果 relevant = await self.filter_relevant(results, question, accumulated_context) accumulated_context.extend(relevant) # 4. 检查是否已有足够信息回答 if await self.has_enough_info(question, accumulated_context): break return accumulated_context async def generate_next_query(self, question, context): """基于当前上下文生成下一步查询""" prompt = f""" 原始问题: {question} 已知信息: {context} 还需要什么信息才能回答问题？请生成一个搜索查询。 如果已经有足够信息，返回"DONE"。 """ response = await self.llm.call(prompt) if "DONE" in response: return None return response.strip() 三、自适应检索 3.1 原理 不是所有问题都需要检索，也不是所有问题都需要相同类型的检索。自适应检索根据问题特征选择最优的检索策略。 ...

引言 检索增强生成（RAG）是2026年最实用的大模型应用架构之一。从基础的"检索-生成"流水线，到Agentic RAG的智能检索代理，RAG技术正在经历深刻的架构演进。本文系统梳理RAG的发展脉络和技术选型。 RAG 的演进阶段 第一阶段：基础 RAG（Naive RAG） 最原始的RAG架构，包含三个步骤： 将文档切分为片段 对片段进行向量化并存储 检索最相关的片段，拼接后输入模型 优点： 简单、快速、易于实现 缺点： 检索质量依赖单一向量相似度，无法处理复杂查询 第二阶段：增强 RAG（Enhanced RAG） 在基础RAG之上增加优化： 查询优化： 查询重写：将用户问题转化为更适合检索的形式 查询分解：将复杂问题拆分为多个子查询 多路检索：同时使用向量检索和关键词检索 后处理： 重排序（Reranking）：对检索结果进行精排 上下文压缩：去除冗余片段，保留关键信息 自适应窗口：根据问题类型调整上下文长度 第三阶段：Agentic RAG Agentic RAG的核心思想：让Agent自主决定如何检索、何时检索、检索什么。 ┌─────────────────────────────────────────────┐ │ Agentic RAG 架构 │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Agent │───▶│ 检索 │ │ │ │ 规划器 │ │ 策略 │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 反思 │◀───│ 多路 │ │ │ │ 与调整 │ │ 检索 │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────────────────────┐ │ │ │ 最终生成与验证 │ │ │ └──────────────────────────┘ │ └─────────────────────────────────────────────┘ 主流 RAG 框架对比 LangChain / LangGraph 特点： 生态最丰富，组件最全 适合： 快速原型开发、复杂RAG管线 ...

引言 幻觉（Hallucination）是大模型最顽固的问题之一。即使是最先进的模型，在回答事实性问题时仍会生成看似合理但完全错误的信息。2026年，随着大模型在更多关键场景中的应用，理解幻觉的根因并有效缓解成为刚需。 幻觉的五大根因 1. 训练数据局限 大模型的知识截止于训练数据，对于训练数据中不存在或过时的信息，模型会通过"推理"生成看似合理的答案。 典型表现： 引用不存在的论文或研究 编造公司或产品 给出过时的法律条款 2. 概率采样本质 语言模型基于概率分布生成文本，其本质是"最可能的下一个词"而非"最正确的事实"。当多个答案在概率上接近时，模型可能选择错误的那个。 3. 过度泛化 模型在训练中学到的一般规律被错误地应用到特定场景，导致"以偏概全"的错误推断。 4. 指令误解 当用户指令模糊或存在歧义时，模型可能以错误的方式理解意图，生成偏离事实的回答。 5. 自洽性缺失 大模型缺乏对自身输出的内在验证机制，无法区分"我知道的"和"我认为可能的"。 2026年主流缓解技术 技术一：RAG增强检索 通过检索外部知识库补充模型的知识，是当前最实用的方案。 # RAG 幻觉缓解流程 def rag_mitigate(query): # 1. 检索相关文档 docs = retriever.search(query, top_k=5) # 2. 相关性过滤 relevant_docs = filter_relevance(docs, query) # 3. 带检索的生成 response = model.generate( prompt=f"基于以下信息回答：{relevant_docs}\n\n问题：{query}" ) # 4. 事实一致性检查 if check_factuality(response, relevant_docs) < threshold: return "我无法确认该信息的准确性" return response 效果： 在事实性问题上的幻觉率降低60-80% 技术二：自我反思（Self-Reflection） 让模型对自己的输出进行二次检查，发现并修正可能的错误。 方法： Chain-of-Verification：先生成答案，再验证每个事实点 Self-Correction：让模型识别自己回答中的矛盾 Multi-Agent Debate：多个Agent相互质疑 技术三：不确定性校准 让模型学会表达"不知道"，而非强行编造答案。 实现方式： 置信度评分：对每个预测输出置信度 拒绝回答：当置信度低于阈值时，明确告知"不确定" 证据标注：要求模型标注每个事实点的来源 技术四：微调与对齐 通过偏好数据微调，让模型更倾向于给出准确而非"有趣"的答案。 ...

引言 记忆系统是Agent智能的核心支柱之一。一个没有记忆的Agent就像没有长期记忆的人类——每次对话都是第一次见面。2026年，Agent记忆系统从简单的向量检索演进为多层次、多模态的持久记忆架构。 记忆系统的三层架构 第一层：工作记忆（Working Memory） 工作记忆对应Agent的当前上下文窗口，负责处理当前任务所需的即时信息。 技术要点： 上下文窗口扩展：200K+ tokens成为主流 滑动窗口机制：保留最相关的历史片段 注意力蒸馏：从长上下文中提取关键信息 第二层：短期记忆（Short-term Memory） 短期记忆存储最近几天到几周内与当前任务相关的数据。 实现方案： 向量数据库（Milvus、Qdrant、Weaviate） 增量索引与自动清理 基于任务相似度的检索优化 第三层：长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过整理、抽象后的持久化信息。 关键技术： 知识图谱（Neo4j、NebulaGraph） 结构化摘要生成 记忆融合与冲突解决 2026年记忆系统的前沿进展 1. 神经符号记忆 将神经网络的感知能力与符号推理的逻辑能力结合，实现更可靠的长期记忆。 # 伪代码：神经符号记忆融合 class NeuroSymbolicMemory: def store(self, experience): # 神经网络提取特征 embedding = self.encoder(experience) # 符号系统提取关系 schema = self.knowledge_extractor(experience) # 联合存储 self.vector_db.upsert(embedding) self.graph_db.merge(schema) def recall(self, query): # 双通道检索 vector_hits = self.vector_db.search(query) graph_hits = self.graph_db.traverse(query) # 重排序融合 return self.reranker(vector_hits + graph_hits) 2. 记忆压缩与摘要 面对无限增长的记忆数据，如何高效压缩和摘要成为关键问题。 主流方法： 基于重要性的记忆保留 周期性记忆摘要生成 基于任务的记忆激活 3. 多模态记忆 2026年的Agent记忆不再局限于文本，而是支持图像、音频、视频等多模态数据的存储与检索。 工程实践建议 选型指南 场景 推荐方案 快速原型 Chroma + 本地存储 生产环境 Milvus / Qdrant 集群 复杂关系 Neo4j + 向量混合 多模态 Milvus + CLIP编码 常见陷阱 记忆污染：错误信息被永久存储 检索延迟：大规模向量检索的性能瓶颈 记忆冲突：不同时期信息之间的矛盾 隐私泄露：敏感信息未做脱敏处理 结语 Agent记忆系统是通向真正智能的关键一步。随着技术的持续演进，未来的Agent将拥有越来越接近人类的记忆能力——不仅记得住，还能想得深。 ...

从Naive RAG到Agentic RAG的演进 RAG技术的发展经历了三个阶段： Naive RAG (2023) → Advanced RAG (2024) → Agentic RAG (2025-2026) 朴素检索 增强检索 智能体检索 单次查询 多次优化 自主决策 固定管道 模块化 动态规划 传统RAG是一个"固定管道"：查询→检索→拼接→生成，一锤子买卖。Agentic RAG将LLM作为"大脑"，让它自主决定是否需要检索、检索什么、检索几次、何时停止。这就像从"查字典"升级为"咨询一个会查资料的研究员"。 Agentic RAG的核心架构 ┌─────────────────────────────────────────────────────┐ │ Agentic RAG Architecture │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────────────────────┐ │ │ │ User │───▶│ Agent Controller │ │ │ │ Query │ │ (LLM + Planning + Memory) │ │ │ └──────────┘ └──────────┬───────────────────┘ │ │ │ │ │ ┌─────────┼─────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌───────┐ ┌─────────┐ │ │ │ Router │ │ Query │ │ Evaluator│ │ │ │ (路由) │ │Rewrite│ │ (评估器) │ │ │ └────┬────┘ └───┬───┘ └────┬────┘ │ │ │ │ │ │ │ ┌─────────┼──────────┼──────────┘ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ │ │ │ Vector │ │ Web │ │ SQL │ │ Graph │ │ │ │ Store │ │ Search │ │ DB │ │ Store │ │ │ └──────────┘ └────────┘ └──────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 四大核心组件 组件 职责 关键能力 Agent Controller 任务规划与决策 分解问题、决定工具调用顺序 Router 工具路由 选择合适的数据源（向量库/搜索引擎/数据库） Query Rewriter 查询改写 将用户问题改写为更有效的检索查询 Evaluator 结果评估 判断检索结果是否充分，决定是否需要追加检索 核心模式解析 模式1：迭代检索（Iterative Retrieval） from langgraph.graph import StateGraph, END from typing import TypedDict, List, Annotated import operator class AgentState(TypedDict): question: str retrieved_docs: Annotated[List[str], operator.add] answer: str iteration: int sufficient: bool def retrieve_node(state: AgentState) -> dict: """基于当前问题+已有信息生成查询并检索""" query = query_rewriter(state["question"], state["retrieved_docs"]) docs = vector_store.similarity_search(query, k=5) return {"retrieved_docs": docs, "iteration": state["iteration"] + 1} def evaluate_node(state: AgentState) -> dict: """评估检索结果是否足以回答问题""" if state["iteration"] >= 3: return {"sufficient": True} prompt = f"""基于以下检索到的文档，能否完整回答用户问题？ 问题: {state['question']} 文档: {state['retrieved_docs']} 如果信息充分回答"SUFFICIENT"，否则回答"INSUFFICIENT"并说明缺什么。""" response = llm.invoke(prompt) sufficient = "SUFFICIENT" in response return {"sufficient": sufficient} def answer_node(state: AgentState) -> dict: """基于所有检索文档生成最终回答""" prompt = f"问题: {state['question']}\n\n参考资料:\n{state['retrieved_docs']}" return {"answer": llm.invoke(prompt)} # 构建工作流 workflow = StateGraph(AgentState) workflow.add_node("retrieve", retrieve_node) workflow.add_node("evaluate", evaluate_node) workflow.add_node("answer", answer_node) workflow.set_entry_point("retrieve") workflow.add_edge("retrieve", "evaluate") workflow.add_conditional_edges( "evaluate", lambda state: "answer" if state["sufficient"] else "retrieve" ) workflow.add_edge("answer", END) agent = workflow.compile() 模式2：多路检索（Multi-Route Retrieval） def route_query(state: AgentState) -> str: """根据问题类型选择检索路径""" routing_prompt = f""" 分析以下问题，选择最合适的数据源： 问题: {state['question']} 选项: - "vector": 适合从内部文档库检索事实性信息 - "web": 适合需要最新信息的时效性问题 - "sql": 适合结构化数据查询 - "graph": 适合关系推理和多方关联 返回JSON: {{"route": "...", "reason": "..."}} """ decision = llm.invoke(routing_prompt) return json.loads(decision)["route"] 模式3：自我纠正检索（Self-Corrective RAG） def grade_documents(state: AgentState) -> dict: """对检索文档打分，过滤低质量结果""" graded_docs = [] for doc in state["retrieved_docs"]: score_prompt = f"""评估文档与问题的相关性(0-10): 问题: {state['question']} 文档: {doc.page_content[:500]} 只返回数字。""" score = int(llm.invoke(score_prompt).strip()) if score >= 6: graded_docs.append(doc) # 如果所有文档都不相关，触发查询改写 if not graded_docs: new_query = llm.invoke(f"改写这个查询以获得更好的检索结果: {state['question']}") return {"retrieved_docs": [], "question": new_query} return {"retrieved_docs": graded_docs} 工程实现：基于LangGraph的完整Agentic RAG from langgraph.graph import StateGraph, END from langgraph.prebuilt import ToolNode from langchain_core.tools import tool from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage # 定义工具 @tool def vector_search(query: str) -> str: """从内部知识库检索相关文档""" docs = vector_store.similarity_search(query, k=5) return "\n\n".join([d.page_content for d in docs]) @tool def web_search(query: str) -> str: """从网络搜索最新信息""" results = search_api.search(query, num_results=5) return "\n\n".join([r["content"] for r in results]) @tool def sql_query(question: str) -> str: """查询业务数据库""" sql = text2sql(question) return db.execute(sql) # Agent决策循环 tools = [vector_search, web_search, sql_query] llm = ChatOpenAI(model="gpt-4o", temperature=0) llm_with_tools = llm.bind_tools(tools) def agent_decision(state): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def should_continue(state): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END # 构建Graph graph = StateGraph(dict) graph.add_node("agent", agent_decision) graph.add_node("tools", ToolNode(tools)) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") # 工具执行后回到agent做下一轮决策 app = graph.compile() # 执行 result = app.invoke({ "messages": [HumanMessage(content="对比2026年Q1三大云厂商的AI服务收入")] }) 性能基准对比 我们在三个数据集上对比了不同RAG架构的表现： ...

核心矛盾：检索 vs 全量上下文 随着GPT-5（2M token）、Claude 4（200K token）、Gemini 2.5 Pro（1M token）的发布，“长上下文模型能否替代RAG"成为2026年最热门的技术争论之一。 两种思路的对比： RAG思路：只给LLM看相关的片段 ┌─────────┐ ┌──────────┐ ┌─────────┐ │ 用户查询 │───▶│ 检索Top-K │───▶│ LLM生成 │ └─────────┘ │ 相关文档 │ └─────────┘ └──────────┘ Long Context思路：把所有文档都塞给LLM ┌─────────┐ ┌────────────────────┐ ┌─────────┐ │ 用户查询 │───▶│ 全部文档(长上下文) │───▶│ LLM生成 │ └─────────┘ └────────────────────┘ └─────────┘ 表面上看，长上下文模型让RAG变得多余——既然能塞下整个知识库，为什么还要检索？但实际情况远没有这么简单。 六大维度全面对比 1. 上下文利用率（Context Utilization） LLM对长上下文的中间部分利用率低，这是经过大量研究验证的"Lost in the Middle"现象。 文档位置对注意力的影响（GPT-5实测）： 文档开头 ──► 注意力权重高 ▼ ──► 文档结尾 ▲ ▲ 用户问题 系统提示 容易引用 容易引用 文档中间 ──► 注意力权重低 ◄── 关键信息 ▼ 容易被忽略 实测数据（1000份文档，每篇500字，共500K token上下文）： ...

为什么分块策略如此重要？ 在RAG系统中，分块（Chunking）是影响检索质量的第一道关卡。同样的文档、同样的Embedding模型、同样的LLM，仅仅因为分块策略不同，检索准确率可以相差30%以上。 核心矛盾在于：块太大，检索精度下降（噪声多）；块太小，上下文不足（语义不完整）。 好的分块策略要在这两端之间找到最优解。 六种分块策略全面对比 1. 固定大小分块（Fixed-Size Chunking） 最简单的策略：按固定token数切分，带overlap。 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "，", " "], ) chunks = splitter.split_text(document) 参数 推荐值 说明 chunk_size 256-1024 取决于文档类型，技术文档建议512 chunk_overlap 10-20% 防止语义在切分边界断裂 优点：实现简单、速度快、可预测 缺点：可能在句子中间切断，破坏语义完整性 适用：快速原型、均匀文本（如日志、评论） 2. 语义分块（Semantic Chunking） 不按固定大小切，而是按语义相似度断点切。当相邻句子的语义相似度低于阈值时，在此处分块。 from semantic_chunker import SemanticChunker from langchain_openai import OpenAIEmbeddings # 基于Embedding相似度的语义分块 chunker = SemanticChunker( OpenAIEmbeddings(model="text-embedding-3-large"), breakpoint_threshold_type="percentile", # 或 "standard_deviation" breakpoint_threshold_amount=95, # 百分位阈值 ) chunks = chunker.split_text(document) 工作原理： 句子1 → 句子2 → 句子3 → 句子4 → 句子5 0.92 0.88 0.45↓ 0.91 0.87 ↑ 语义断点（相似度骤降） 在这里切分 # 自定义语义分块实现 import numpy as np from sklearn.metrics.pairwise import cosine_similarity def semantic_chunk(text, embeddings_model, threshold=0.5): """基于句子间语义相似度的自适应分块""" sentences = split_into_sentences(text) # 计算每对相邻句子的相似度 embeddings = [embeddings_model.embed(s) for s in sentences] similarities = [ cosine_similarity([embeddings[i]], [embeddings[i+1]])[0][0] for i in range(len(embeddings) - 1) ] # 找到相似度低于阈值的位置作为断点 chunks = [] current_chunk = [sentences[0]] for i, sim in enumerate(similarities): if sim < threshold: chunks.append(" ".join(current_chunk)) current_chunk = [sentences[i + 1]] else: current_chunk.append(sentences[i + 1]) chunks.append(" ".join(current_chunk)) return chunks 优点：语义完整、适应文档结构 缺点：计算开销大（每句话都要Embedding）、块大小不可控 适用：长文章、研究报告、新闻 ...

前言：RAG从Demo到生产的鸿沟 写一个RAG Demo只需要30分钟——加载文档、Embedding、存向量库、检索、生成，完成。但把它放到生产环境，你会发现： 幻觉：LLM明明拿到了正确文档，还是编造了不存在的信息 漏检：库里明明有相关文档，检索就是找不到 延迟：用户等了8秒还没返回，体验崩溃 这三个问题构成了RAG生产环境的"不可能三角"。本文分享2026年我们在生产环境中踩过的坑和解决方案。 难题一：幻觉问题 幻觉的三种形态 类型 表现 根因 忠实性幻觉 答案与检索文档矛盾 LLM忽略上下文，依赖自身参数知识 编造型幻觉 答案包含文档中不存在的信息 LLM"脑补"细节 来源混淆 将多个文档的信息错误组合 多文档检索时上下文混淆 解决方案矩阵 方案1：强约束Prompt # ❌ 容易幻觉的Prompt prompt = f"""基于以下资料回答问题： {context} 问题：{question} """ # ✅ 抗幻觉的Prompt prompt = f"""你是一个严格的信息提取助手。请遵循以下规则： 1. **只使用**以下参考资料回答问题 2. 如果参考资料中没有相关信息，直接回答"根据现有资料无法回答此问题" 3. 不要添加任何参考资料中未提及的信息 4. 不要进行推理、猜测或补全 5. 回答中需要引用具体的资料来源 参考资料： --- {context} --- 问题：{question} 回答格式： [来源：文档名] 回答内容... """ 方案2：置信度校准 def answer_with_confidence(question, retrieved_docs): """带置信度的回答""" # 第一步：评估检索质量 relevance_prompt = f"""评估以下文档与问题的相关性(0-10): 问题: {question} 文档: {retrieved_docs[0].page_content[:500]} 只返回数字。""" relevance_score = int(llm.invoke(relevance_prompt).strip()) if relevance_score < 4: return { "answer": "抱歉，知识库中没有找到与您问题相关的信息。", "confidence": 0.2, "should_answer": False, } # 第二步：生成回答并自我验证 answer = rag_chain.invoke(question) # 第三步：验证回答是否忠于上下文 verify_prompt = f"""判断以下回答的每个陈述是否能在参考资料中找到支撑。 参考资料: {retrieved_docs} 回答: {answer} 返回JSON: {{"faithful": true/false, "unsupported_claims": [...]}}""" verification = json.loads(llm.invoke(verify_prompt)) return { "answer": answer if verification["faithful"] else "无法确认回答准确性", "confidence": relevance_score / 10.0, "should_answer": verification["faithful"], } 方案3：Citation机制 def generate_with_citations(question, retrieved_docs): """强制引用来源的生成""" # 给每个文档编号 numbered_context = "\n\n".join([ f"[{i+1}] {doc.page_content}" for i, doc in enumerate(retrieved_docs) ]) prompt = f"""基于以下编号的参考资料回答问题。每个陈述后必须标注来源编号[1]。 参考资料： {numbered_context} 问题：{question} 要求： - 每个事实陈述后标注来源编号，如"GraphRAG由微软提出[1]" - 如果某个陈述来自多个文档，标注所有来源，如"[1][3]" - 无法找到来源的陈述不要写出 回答：""" return llm.invoke(prompt) 幻觉抑制效果实测 方案 幻觉率↓ 答案完整度↓ 延迟增加 强约束Prompt 45% 15% +0s 置信度校准 68% 8% +1.5s Citation机制 72% 5% +0.8s 三者结合 85% 22% +2.3s 建议组合：强约束Prompt + Citation机制，性价比最高。 ...

LlamaIndex 2026：RAG之王的Agent转型 LlamaIndex（原GPT Index）最初是一个专注于RAG（检索增强生成）的框架。2024年，它是构建知识增强LLM应用的事实标准。但市场在变——单纯的RAG已经不够了，用户需要Agent：能够自主检索、推理、行动的智能体。2026年，LlamaIndex完成了从"RAG框架"到"Agent平台"的战略转型。 转型背景：为什么RAG不够了 RAG的局限 RAG能力 局限性 单轮检索 无法处理需要多步推理的复杂问题 静态知识库 无法实时更新和动态检索 被动回答 不能主动行动（发邮件、调API） 单一数据源 难以跨多个异构数据源联合查询 无任务规划 无法分解复杂任务为子任务 Agent化解决方案 传统RAG：用户提问 → 检索 → 生成回答 Agent化：用户提问 → 理解意图 → 规划任务 → 多步检索/行动 → 综合回答 AgentWorkflow：LlamaIndex的Agent编排引擎 2026版本引入了AgentWorkflow作为核心Agent编排组件： from llama_index.core.agent.workflow import ( AgentWorkflow, FunctionAgent, ReActAgent, RouterAgent ) from llama_index.core.tools import QueryEngineTool, ToolMetadata # 创建RAG工具 stock_engine = create_stock_query_engine() # 股票数据引擎 news_engine = create_news_query_engine() # 新闻数据引擎 report_engine = create_report_query_engine() # 财报数据引擎 # 定义工具 tools = [ QueryEngineTool( query_engine=stock_engine, metadata=ToolMetadata( name="stock_data", description="查询股票实时行情和历史数据" ) ), QueryEngineTool( query_engine=news_engine, metadata=ToolMetadata( name="news_data", description="搜索财经新闻和公告" ) ), QueryEngineTool( query_engine=report_engine, metadata=ToolMetadata( name="report_data", description="查询上市公司财报数据" ) ) ] # 创建专业Agent analyst_agent = ReActAgent( name="分析Agent", description="负责数据分析和技术指标计算", tools=[stock_engine, report_engine], llm=OpenAI(model="gpt-4o"), system_prompt="你是一位专业的金融分析师..." ) research_agent = ReActAgent( name="研究Agent", description="负责新闻搜集和信息检索", tools=[news_engine], llm=OpenAI(model="gpt-4o"), system_prompt="你是一位财经研究员..." ) writer_agent = FunctionAgent( name="撰写Agent", description="负责综合分析报告撰写", llm=OpenAI(model="gpt-4o"), system_prompt="你是一位专业的金融报告撰写人..." ) # 创建工作流 workflow = AgentWorkflow( agents=[analyst_agent, research_agent, writer_agent], root_agent=analyst_agent, # 主入口Agent max_steps=20, # 最大执行步数 max_time=180, # 最大执行时间（秒） ) # 执行 response = await workflow.run( "分析贵州茅台2025年年报，结合近期新闻，给出投资建议" ) Agent类型对比 Agent类型 决策方式 适合场景 灵活性 ReActAgent 推理-行动循环 需要多步推理的任务 高 FunctionAgent 直接函数调用 简单确定性任务 低 RouterAgent 路由到子Agent 需要分领域处理 中 CustomAgent 自定义逻辑 特殊需求 完全可控 数据代理：RAG的Agent化升级 LlamaIndex 2026提出了"Data Agent"概念——专门处理数据的智能Agent： ...