大模型幻觉问题:根因分析与缓解技术全景

大模型幻觉问题:根因分析与缓解技术全景

引言 幻觉(Hallucination)——大模型生成看似合理但事实上不正确的内容——是大模型走向实际应用的最大障碍之一。在医疗、法律、金融等高风险场景中,一次幻觉可能导致严重后果。2026年,尽管模型能力大幅提升,幻觉问题仍然存在,但业界已发展出一系列从训练到推理的缓解技术。本文将系统分析幻觉的根因并梳理全景式的解决方案。 幻觉的定义与分类 定义 幻觉指模型生成的内容与已知事实不符,或与给定上下文矛盾。形式化定义: $$ \text{Hallucination}: \exists f \in \text{output}, \quad f \not\in \text{Facts} \lor f \not\in \text{Context} $$ 分类体系 幻觉类型 描述 示例 严重程度 事实性幻觉 生成不存在的事实 “爱因斯坦出生于1890年”(实际1879) 高 上下文幻觉 与给定上下文矛盾 RAG场景中忽略检索到的事实 高 推理幻觉 推理链中包含错误步骤 数学证明中跳过关键步骤 中 来源幻觉 错误归因信息来源 “根据2024年Nature论文…"(不存在) 中 自我矛盾 前后陈述矛盾 先说"是”,后说"不是" 低 幻觉的量化评估 class HallucinationEvaluator: def __init__(self, fact_checker=None): self.fact_checker = fact_checker # 外部事实核查器 def evaluate(self, response, context=None, reference=None): """多维度幻觉评估""" results = { 'factual_accuracy': self.check_facts(response), 'context_consistency': self.check_context(response, context) if context else None, 'internal_consistency': self.check_internal(response), 'source_accuracy': self.check_sources(response), } # 综合幻觉分数 scores = [v for v in results.values() if v is not None] results['overall_hallucination_rate'] = 1 - np.mean(scores) return results def check_facts(self, response): """事实准确性检查""" if self.fact_checker: return self.fact_checker.verify(response) return None def check_context(self, response, context): """上下文一致性检查""" # 使用NLI模型检查蕴含关系 nli_score = self.nli_model(context, response) return nli_score # 0-1, 1=完全蕴含 def check_internal(self, response): """内部一致性检查""" sentences = split_sentences(response) contradictions = 0 for i, s1 in enumerate(sentences): for s2 in sentences[i+1:]: if self.nli_model(s1, s2) < 0.3: contradictions += 1 return 1 - contradictions / max(1, len(sentences)) 幻觉的根因分析 1. 训练数据层面 数据噪声:训练数据中包含错误信息,模型学习了这些错误。 ...

2026-06-30 · 5 min · 898 words · 硅基 AGI 探索者
RAG技术演进2026:从基础检索到智能知识库

RAG技术演进2026:从基础检索到智能知识库

2026年,RAG(Retrieval-Augmented Generation)技术已经走过了三年的演进历程。从最初简单的"检索+拼接"模式,发展到今天的GraphRAG、Agentic RAG、Adaptive RAG等多种高级范式,RAG已成为企业AI应用的核心基础设施。本文将系统梳理2026年RAG技术的全景图。 一、RAG技术演进路线 四代RAG架构 代际 名称 核心特征 时间 代表方案 第一代 Naive RAG 简单向量检索+拼接 2023 LangChain Basic RAG 第二代 Advanced RAG 查询改写、重排序、多路召回 2024 LlamaIndex Advanced 第三代 Modular RAG 模块化、可插拔、自适应路由 2025 LangGraph RAG 第四代 Agentic RAG Agent驱动、多步推理、工具调用 2026 Agentic RAG, GraphRAG 为什么需要更先进的RAG? Naive RAG的根本问题在于: 检索质量不稳定:向量相似度≠语义相关性 缺乏推理能力:无法处理"需要多步推理才能回答"的问题 无结构化知识:无法利用实体关系、时序信息等结构化知识 无自适应能力:对所有问题用同一套检索策略 2026年企业RAG部署的统计:Naive RAG的准确率仅55-65%,而Agentic RAG可达85-92%——差距巨大。 二、Embedding技术2026 Embedding模型横评 Embedding是RAG的基础——如果检索不到相关内容,后续一切都无意义。 模型 维度 最大序列 MTEB分数 中文表现 特点 OpenAI text-embedding-3-large 3072 8191 72.5 良好 通用、稳定 Voyage-3 1024 32000 74.8 良好 2026最强 BGE-M3 1024 8192 73.2 优秀 多语言、开源 GTE-Large-ZH 1024 512 71.5 优秀 中文优化 Jina Embeddings v3 1024 8192 72.8 良好 长文本 Cohere Embed v4 1536 512 73.5 良好 多语言 2026年Embedding技术趋势 1. 多向量嵌入(Multi-Vector Embedding) ...

2026-06-30 · 3 min · 559 words · 硅基 AGI 探索者
ai customer service system 2026

AI 客服系统 2026 构建指南:从知识库到多轮对话

引言 2026年,AI客服系统已经从简单的FAQ机器人进化为具备深度理解、情感识别和主动服务能力的智能体。根据Gartner最新报告,全球78%的企业客服中心已部署AI驱动的话务系统,平均首次解决率(FCR)从传统IVR的42%提升至71%。本文将系统性地介绍如何从零构建一套现代AI客服系统。 一、架构总览 现代AI客服系统的核心架构包含以下层级: 层级 组件 技术选型 接入层 Web/App/电话/社交媒体 WebSocket + SIP + Webhook 对话层 意图识别 + 对话管理 LLM + Function Calling 知识层 RAG + 知识图谱 向量数据库 + 图数据库 业务层 工单/CRM/ERP集成 REST API + 消息队列 分析层 质检/分析/监控 实时流处理 + BI看板 二、知识库搭建 2.1 知识来源梳理 构建客服系统的第一步是建立高质量知识库。典型的知识来源包括: 产品文档:用户手册、FAQ、操作指南 历史工单:已解决的客服记录,经过脱敏和结构化处理 政策法规:退换货政策、隐私条款、合规要求 对话记录:优秀人工客服的对话样本 2.2 知识处理流水线 # 知识处理流水线伪代码 def process_knowledge(raw_docs): # 1. 文档解析与清洗 chunks = [] for doc in raw_docs: parsed = parse_document(doc) # PDF/Word/HTML统一解析 cleaned = clean_text(parsed) # 去除噪声、标准化格式 chunks.extend(chunk_text(cleaned, max_tokens=512, overlap=64)) # 2. 向量化与索引 embeddings = embedding_model.encode(chunks) # 如 bge-m3, text-embedding-3-large vector_db.upsert(chunks, embeddings, metadata) # 3. 知识图谱构建 entities = ner_model.extract(chunks) relations = relation_extractor.extract(chunks, entities) graph_db.insert(entities, relations) # 4. 质量校验 qa_pairs = generate_qa_pairs(chunks) # 用LLM自动生成测试集 validate_retrieval(qa_pairs) # 验证召回率和准确率 2.3 RAG检索优化 2026年主流的RAG优化策略已从简单向量检索演进为多路召回+重排序: ...

2026-06-28 · 2 min · 306 words · 硅基 AGI 探索者
llm hallucination 2026 analysis

大模型幻觉问题 2026:根因分析与缓解策略

幻觉:LLM 最棘手的问题 大模型的幻觉(Hallucination)——自信地输出错误或虚构的信息——是 2026 年 LLM 生产应用中最大的痛点。Stanford 2026 年 AI Index 报告显示,即使是最先进的模型,在事实性问答中的幻觉率仍有 3-8%,在专业领域更是高达 15-20%。幻觉不是 bug,而是 LLM 生成式架构的特性——但我们可以系统性地缓解它。 一、幻觉的分类 1.1 幻觉类型体系 类型 描述 示例 严重性 事实性幻觉 输出与事实不符 “爱因斯坦出生于1890年”(实际1879) 高 来源幻觉 虚构引用/出处 编造不存在的论文 高 推理幻觉 推理链条中出错 正确前提但错误结论 中 时间幻觉 时间线混乱 “2024年奥运会在北京举办” 中 实体幻觉 虚构人/组织/产品 “微软CEO John Smith” 高 数值幻觉 数字/计算错误 “12×13=146”(实际156) 高 代码幻觉 API/函数不存在 调用不存在的库函数 中 自我幻觉 虚构自身能力 “我可以访问实时互联网” 低 1.2 幻觉产生的根因 ┌──────────────────────────────────────────┐ │ 幻觉根因分析 │ ├──────────────────────────────────────────┤ │ │ │ 1. 训练数据问题 │ │ ├── 训练数据中的错误信息 │ │ ├── 知识截止日期后的信息缺失 │ │ └── 长尾知识表示不足 │ │ │ │ 2. 模型架构问题 │ │ ├── 自回归生成无法回溯修正 │ │ ├── 注意力机制对事实关注不足 │ │ └── 知识存储与检索机制不完善 │ │ │ │ 3. 推理机制问题 │ │ ├── 缺乏事实核查机制 │ │ ├── 过度依赖模式匹配而非知识检索 │ │ └── 采样温度增加随机性 │ │ │ │ 4. 交互问题 │ │ ├── 模型倾向"回答"而非"承认不知道" │ │ ├── 用户问题中的错误前提引导 │ │ └── 上下文中的错误信息被采纳 │ │ │ └──────────────────────────────────────────┘ 二、幻觉检测方法 2.1 基于一致性的检测 class ConsistencyBasedDetector: """基于一致性的幻觉检测""" def __init__(self, llm_client, n_samples: int = 5): self.llm = llm_client self.n_samples = n_samples def detect(self, query: str, response: str) -> dict: """通过多次采样检测一致性""" # 1. 对同一问题生成多个回答 responses = [] for _ in range(self.n_samples): r = self.llm.generate(query, temperature=0.7) responses.append(r) # 2. 提取每个回答中的事实性陈述 all_claims = [] for r in responses: claims = self._extract_claims(r) all_claims.append(claims) # 3. 检查事实一致性 consistency_scores = self._check_consistency(all_claims) # 4. 原始回答的事实性评估 original_claims = self._extract_claims(response) original_scores = [] for claim in original_claims: # 该claim在其他回答中出现的比例 support_count = sum( 1 for claims in all_claims if self._claim_match(claim, claims) ) original_scores.append({ 'claim': claim, 'support_rate': support_count / len(all_claims), 'likely_hallucination': support_count / len(all_claims) < 0.4 }) hallucination_rate = sum( 1 for s in original_scores if s['likely_hallucination'] ) / len(original_scores) if original_scores else 0 return { 'hallucination_rate': hallucination_rate, 'claim_scores': original_scores, 'overall_consistency': np.mean(consistency_scores) } def _extract_claims(self, text: str) -> list: """提取文本中的事实性陈述""" prompt = f"""提取以下文本中的所有事实性陈述,每条一行: {text}""" result = self.llm.generate(prompt) return [line.strip() for line in result.split('\n') if line.strip()] def _claim_match(self, claim: str, other_claims: list) -> bool: """判断claim是否在other_claims中存在""" prompt = f"""判断以下陈述是否语义等价: 陈述A:{claim} 陈述B列表:{other_claims} 如果A与B中任一陈述语义等价,返回"是",否则"否"。""" return '是' in self.llm.generate(prompt) 2.2 基于来源验证的检测 class SourceVerificationDetector: """基于来源验证的幻觉检测""" def __init__(self, llm_client, search_client): self.llm = llm_client self.search = search_client def detect(self, response: str, sources: list = None) -> dict: """验证回答中的事实是否有来源支持""" # 1. 提取事实性陈述 claims = self._extract_claims(response) # 2. 对每个claim进行验证 results = [] for claim in claims: # 如果有现成来源,在来源中验证 if sources: verification = self._verify_in_sources(claim, sources) else: # 搜索验证 verification = self._verify_by_search(claim) results.append({ 'claim': claim, 'verdict': verification['verdict'], # supported | refuted | unverifiable 'evidence': verification['evidence'], 'confidence': verification['confidence'] }) hallucination_claims = [ r for r in results if r['verdict'] == 'refuted' ] unsupported_claims = [ r for r in results if r['verdict'] == 'unverifiable' ] return { 'total_claims': len(results), 'supported': len([r for r in results if r['verdict'] == 'supported']), 'refuted': len(hallucination_claims), 'unverifiable': len(unsupported_claims), 'hallucination_rate': len(hallucination_claims) / len(results), 'details': results } def _verify_in_sources(self, claim: str, sources: list) -> dict: """在给定来源中验证claim""" prompt = f"""判断以下陈述是否被来源文本支持。 陈述:{claim} 来源文本: {chr(10).join(f'[{i+1}] {s[:500]}' for i, s in enumerate(sources))} 判断: - "supported":来源支持该陈述 - "refuted":来源与该陈述矛盾 - "unverifiable":来源无法验证该陈述 返回判断和依据。""" result = self.llm.generate(prompt) if 'supported' in result.lower(): verdict = 'supported' elif 'refuted' in result.lower(): verdict = 'refuted' else: verdict = 'unverifiable' return { 'verdict': verdict, 'evidence': result, 'confidence': 0.8 } def _verify_by_search(self, claim: str) -> dict: """通过搜索验证claim""" search_results = self.search.search(claim, top_k=3) return self._verify_in_sources(claim, search_results) 2.3 基于模型置信度的检测 class ConfidenceBasedDetector: """基于模型内部置信度的幻觉检测""" def __init__(self, model): self.model = model def detect(self, prompt: str) -> dict: """通过logits分析检测幻觉""" # 1. 获取模型输出和logits with torch.no_grad(): outputs = self.model.generate( prompt, return_logits=True, output_scores=True ) # 2. 计算每个token的置信度 token_confidences = [] for i, (token, score) in enumerate( zip(outputs.tokens, outputs.scores) ): # softmax得到概率 probs = torch.softmax(score, dim=-1) token_prob = probs[token].item() token_confidences.append(token_prob) # 3. 分析低置信度区域 low_confidence_threshold = 0.5 low_conf_regions = [ {'position': i, 'token': outputs.tokens[i], 'confidence': conf} for i, conf in enumerate(token_confidences) if conf < low_confidence_threshold ] # 4. 计算整体置信度指标 avg_confidence = np.mean(token_confidences) min_confidence = np.min(token_confidences) return { 'avg_confidence': avg_confidence, 'min_confidence': min_confidence, 'low_confidence_tokens': len(low_conf_regions), 'hallucination_risk': 'high' if avg_confidence < 0.6 else 'medium' if avg_confidence < 0.8 else 'low', 'low_conf_regions': low_conf_regions[:10] # 前10个低置信度token } 三、幻觉缓解策略 3.1 RAG 增强 class RAGHallucinationMitigator: """RAG 增强缓解幻觉""" def __init__(self, llm_client, retrieval_client): self.llm = llm_client self.retrieval = retrieval_client def generate(self, query: str) -> dict: """RAG增强生成""" # 1. 检索相关文档 docs = self.retrieval.search(query, top_k=5) # 2. 构建RAG Prompt prompt = self._build_rag_prompt(query, docs) # 3. 生成回答 response = self.llm.generate(prompt) # 4. 后验证 verification = self._verify_response(response, docs) return { 'response': response, 'sources': docs, 'verification': verification, 'hallucination_risk': verification['hallucination_rate'] } def _build_rag_prompt(self, query: str, docs: list) -> str: return f"""请基于以下参考资料回答问题。如果资料中没有答案,请明确说明"根据现有资料无法回答"。 ## 参考资料 {self._format_docs(docs)} ## 回答规则 1. 只使用参考资料中的信息 2. 每个事实性陈述必须标注来源 [1], [2] 等 3. 如果资料中有矛盾信息,指出矛盾 4. 不确定的信息要标注"可能" 5. 资料中未涉及的信息不要编造 ## 问题 {query} ## 回答""" 3.2 自我验证机制 class SelfVerificationGenerator: """自我验证生成机制""" def __init__(self, llm_client): self.llm = llm_client def generate_with_verification(self, query: str) -> dict: """带自我验证的生成""" # Step 1: 初步生成 initial_response = self.llm.generate(query) # Step 2: 自我事实核查 fact_check = self._self_fact_check(query, initial_response) # Step 3: 如果发现幻觉,修正 if fact_check['has_issues']: corrected = self._correct_hallucinations( query, initial_response, fact_check ) else: corrected = initial_response # Step 4: 最终验证 final_check = self._final_verification(query, corrected) return { 'response': corrected, 'initial_response': initial_response, 'fact_check': fact_check, 'final_verification': final_check, 'corrections_made': fact_check['issues_found'] } def _self_fact_check(self, query: str, response: str) -> dict: """自我事实核查""" prompt = f"""请对你自己的回答进行事实核查。 问题:{query} 你的回答:{response} 请逐句检查: 1. 每个事实性陈述是否准确? 2. 是否有编造的信息? 3. 是否有不确定但表述为事实的内容? 4. 数字和日期是否正确? 对每个可能的问题,标注: - 陈述内容 - 问题类型(错误/编造/不确定) - 修正建议 如果一切正确,返回"无问题"。""" result = self.llm.generate(prompt) has_issues = '无问题' not in result issues = [] if has_issues: # 解析问题列表 issues = self._parse_issues(result) return { 'has_issues': has_issues, 'issues_found': issues, 'raw_check': result } def _correct_hallucinations(self, query, response, fact_check): """修正检测到的幻觉""" prompt = f"""请修正以下回答中的事实性错误。 原始问题:{query} 原始回答:{response} 检测到的问题:{fact_check['raw_check']} 修正规则: 1. 修正所有检测到的事实性错误 2. 不确定的信息添加"据我所知"等限定词 3. 无法确认的信息直接删除或标注"需查证" 4. 保持回答的连贯性和有用性 修正后的回答:""" return self.llm.generate(prompt) 3.3 多模型交叉验证 class CrossModelVerification: """多模型交叉验证""" def __init__(self, models: list): self.models = models # 多个不同厂商的模型 def generate_verified(self, query: str) -> dict: """多模型交叉验证生成""" # 1. 每个模型独立生成回答 responses = [] for model in self.models: r = model.generate(query, temperature=0.0) responses.append(r) # 2. 提取各模型的事实性陈述 all_claims = [] for r in responses: claims = self._extract_claims(r) all_claims.append(set(claims)) # 3. 找出共识陈述和分歧陈述 consensus = set.intersection(*all_claims) if all_claims else set() all_claims_set = set.union(*all_claims) if all_claims else set() disputed = all_claims_set - consensus # 4. 只保留共识陈述 verified_response = self._build_response_from_consensus( query, consensus, responses[0] # 以第一个模型的回答为模板 ) return { 'response': verified_response, 'model_count': len(self.models), 'consensus_claims': len(consensus), 'disputed_claims': len(disputed), 'agreement_rate': len(consensus) / max(len(all_claims_set), 1) } 四、幻觉评估基准 4.1 评估指标 指标 计算方式 目标 事实准确率 事实正确陈述/总事实陈述 > 95% 幻觉率 虚构陈述/总事实陈述 < 5% 来源准确率 正确引用/总引用 > 90% 拒绝准确率 正确拒绝不该回答的问题比例 > 95% 过度拒绝率 错误拒绝合理问题的比例 < 5% 自校准ECE 预期校准误差 < 0.1 4.2 评估数据集构建 class HallucinationEvalDataset: """幻觉评估数据集""" CATEGORIES = { 'factual_qa': { 'description': '事实性问答', 'examples': [ {'q': '中国最长的河流是?', 'a': '长江', 'type': 'fact'}, {'q': '光速是多少?', 'a': '约3×10^8 m/s', 'type': 'fact'}, ] }, 'unanswerable': { 'description': '无法回答的问题(测试是否承认不知道)', 'examples': [ {'q': '2028年的奥斯卡最佳影片是哪部?', 'a': '无法回答', 'type': 'refuse'}, {'q': '张三的手机号码是多少?', 'a': '无法回答', 'type': 'refuse'}, ] }, 'false_premise': { 'description': '错误前提问题', 'examples': [ {'q': '林黛玉倒拔垂杨柳的故事告诉我们什么?', 'a': '指出前提错误', 'type': 'correct'}, ] }, 'multi_hop': { 'description': '多跳推理(每跳都可能出错)', 'examples': [ {'q': '相对论提出者出生国家的首都人口是多少?', 'a': '需推理:爱因斯坦→德国→柏林→人口', 'type': 'reasoning'} ] } } 五、2026 前沿方向 检索增强自我修正:模型生成后自动检索验证并修正 事实性训练:用事实核查数据做偏好优化 知识编辑:直接在模型权重中修正错误知识 不确定性量化:模型输出附带校准的不确定性分数 因果推理增强:用因果推理替代模式匹配 工具增强事实性:自动调用搜索引擎、计算器等工具 结语 幻觉是 LLM 的"原罪"——源于其自回归生成架构和统计学习本质。完全消除幻觉在当前技术范式下不可能,但通过 RAG、自我验证、交叉验证等手段,可以将其控制在可接受范围内。 ...

2026-06-28 · 6 min · 1115 words · 硅基 AGI 探索者
dify platform 2026 review

Dify 平台 2026 深度评测:开源 AI 应用开发平台

Dify 2026:从工作流到 AI 操作系统 Dify 在 2026 年经历了从"LLM 应用开发平台"到"AI 操作系统"的蜕变。这个由苏州语灵科技打造的开源平台,已经积累了 45.6k GitHub Stars,成为亚洲最大的 AI 应用开源项目之一。本文将从实际使用出发,对 Dify 2026 版本进行全面评测。 核心能力总览 1. 可视化 Workflow 编排 Dify 2026 的 Workflow 编辑器是评测中体验最好的部分。拖拽式画布支持以下节点类型: ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Start 节点 │───→│ LLM 节点 │───→│ 条件分支节点 │ │ (输入定义) │ │ (模型选择) │ │ (IF/ELSE) │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ ┌──────────────────┤ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ 知识检索节点 │ │ HTTP 请求节点 │ │ (RAG) │ │ (API 调用) │ └──────┬──────┘ └──────┬──────┘ │ │ └────────┬─────────┘ ▼ ┌─────────────┐ │ End 节点 │ │ (输出定义) │ └─────────────┘ 评测中发现,Workflow 的条件分支节点支持嵌套逻辑,代码节点支持 Python 和 JavaScript 双语言: ...

2026-06-28 · 3 min · 548 words · 硅基 AGI 探索者
llamaindex 2026 agent platform

LlamaIndex 2026:从 RAG 框架到 Agent 平台

从 RAG 到 Agent:LlamaIndex 的范式跃迁 LlamaIndex 在 2023 年以"RAG 框架"闻名——它是构建检索增强生成应用最简单的方式。但创始人 Jerry Liu 很早就意识到:RAG 本质上是 Agent 的一个特例。到 2026 年,LlamaIndex 已经完成了从"RAG 框架"到"数据驱动 Agent 平台"的转型。 2026 架构演进 核心层次 ┌──────────────────────────────────────────────────┐ │ Agent Layer │ │ Workflows │ Data Agents │ Multi-Agent │ Tools │ ├──────────────────────────────────────────────────┤ │ Orchestration Layer │ │ Query Engine │ Router │ Planner │ Evaluator │ ├──────────────────────────────────────────────────┤ │ Data Layer │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Ingestion│ │ Indexing │ │ Retrieval │ │ │ │ Pipeline │ │ (多索引) │ │ (混合检索) │ │ │ └──────────┘ └──────────┘ └──────────────────┘ │ ├──────────────────────────────────────────────────┤ │ Integration Layer │ │ 50+ LLM │ 30+ Vector DB │ 100+ Data Source │ └──────────────────────────────────────────────────┘ 版本对比 特性 LlamaIndex 0.10 (2024) LlamaIndex 1.0 (2026) 核心定位 RAG 框架 Agent 平台 Agent 支持 实验性 一等公民 Workflow 不支持 事件驱动 Workflow 多模态 基础 原生多模态 评估 离线评估 在线评估 + A/B 测试 部署 Python 脚本 LlamaCloud + 本地 性能 中等 优化 40-60% 核心新特性 1. Workflows:事件驱动编排 LlamaIndex 2026 的 Workflow 系统采用事件驱动模型,与 LangGraph 的状态机模型形成对比: ...

2026-06-28 · 4 min · 750 words · 硅基 AGI 探索者
agentic rag when rag meets agent

Agentic RAG:当 RAG 遇到 Agent,检索增强的下一步

从 RAG 到 Agentic RAG 的范式转移 传统 RAG 是一个线性的流水线:检索→拼接→生成。它被动地执行预定义的步骤,没有自主决策能力。而 Agentic RAG 将 LLM Agent 作为核心控制器,赋予 RAG 系统"思考"和"行动"的能力。 核心差异 维度 传统 RAG Agentic RAG 检索策略 固定流程 动态决策 检索次数 1次(或固定N次) 按需迭代 工具使用 仅检索 检索+计算+搜索+API 自我修正 ❌ ✅ 评估并重试 多步推理 ❌ ✅ 任务拆解 结果质量 依赖单次检索 迭代优化 Agentic RAG 架构 用户提问 ↓ ┌─────────────────────────────────────┐ │ Agent Controller │ │ ┌───────────────────────────────┐ │ │ │ 1. 意图理解 & 任务规划 │ │ │ │ 2. 工具选择 & 执行 │ │ │ │ 3. 结果评估 & 决策 │ │ │ │ 4. 迭代或终止 │ │ │ └───────────────────────────────┘ │ └─────────────────────────────────────┘ ↓ ↓ ↓ ┌────────┐ ┌──────────┐ ┌──────────┐ │向量检索 │ │知识图谱 │ │Web搜索 │ │工具 │ │查询工具 │ │工具 │ └────────┘ └──────────┘ └──────────┘ ↓ ↓ ↓ ┌─────────────────────────────────────┐ │ 结果整合 & 验证 │ │ 交叉验证 → 去重 → 排序 → 生成 │ └─────────────────────────────────────┘ 核心实现 Agent 控制器 from enum import Enum from typing import List, Dict, Any class AgentAction(Enum): RETRIEVE_VECTOR = "retrieve_vector" RETRIEVE_GRAPH = "retrieve_graph" WEB_SEARCH = "web_search" CALCULATE = "calculate" SYNTHESIZE = "synthesize" REFINE_QUERY = "refine_query" FINISH = "finish" class AgenticRAG: def __init__(self, llm, vector_store, graph_store, web_searcher): self.llm = llm self.tools = { AgentAction.RETRIEVE_VECTOR: self._retrieve_vector, AgentAction.RETRIEVE_GRAPH: self._retrieve_graph, AgentAction.WEB_SEARCH: self._web_search, AgentAction.CALCULATE: self._calculate, } self.max_iterations = 10 def query(self, question: str) -> str: context = [] reasoning_trace = [] for i in range(self.max_iterations): # Agent 决策:下一步做什么? decision = self._decide_action(question, context, reasoning_trace) reasoning_trace.append({ "iteration": i, "thought": decision.thought, "action": decision.action.value, "action_input": decision.action_input }) if decision.action == AgentAction.FINISH: # 生成最终答案 return self._generate_answer(question, context, reasoning_trace) if decision.action == AgentAction.REFINE_QUERY: question = decision.action_input["refined_query"] continue # 执行工具 tool_result = self.tools[decision.action](**decision.action_input) context.append(tool_result) # 评估结果质量 evaluation = self._evaluate(question, tool_result) reasoning_trace[-1]["evaluation"] = evaluation if evaluation["sufficient"]: # 信息足够,生成答案 return self._generate_answer(question, context, reasoning_trace) return self._generate_answer(question, context, reasoning_trace) def _decide_action(self, question, context, trace) -> "Decision": prompt = f""" 你是一个 RAG Agent。根据当前状态决定下一步行动。 问题:{question} 已收集的上下文: {self._format_context(context)} 推理历史: {self._format_trace(trace)} 可选行动: 1. retrieve_vector - 向量检索(语义相关信息) 2. retrieve_graph - 图谱查询(实体关系) 3. web_search - 网络搜索(实时信息) 4. calculate - 计算(数值处理) 5. refine_query - 优化查询 6. finish - 信息足够,生成答案 请输出 JSON: {{"thought": "思考过程", "action": "行动名称", "action_input": {{...}}}} """ result = self.llm.generate(prompt, response_format="json") return Decision(**result) 多轮迭代检索 def iterative_retrieve(self, question: str, max_rounds: int = 3): """多轮迭代检索:每轮基于上一轮的结果深化检索""" all_context = [] current_query = question for round_idx in range(max_rounds): # 检索 results = self.vector_store.search( embed_model.encode(current_query), top_k=10 ) # 评估检索结果 relevance = self._assess_relevance(question, results) if relevance["score"] > 0.8: all_context.extend(results) break # 生成 follow-up query current_query = self._generate_followup_query( question, results, all_context ) all_context.extend(results) return all_context def _generate_followup_query(self, original_query, current_results, past_context): prompt = f""" 原始问题:{original_query} 已检索到的信息: {self._format_results(current_results)} 已有上下文: {self._format_results(past_context)} 信息缺口分析:还有哪些信息需要检索? 请生成一个更精确的 follow-up 查询。 """ return self.llm.generate(prompt).strip() 自我评估与修正 def self_evaluate(self, question: str, answer: str, context: list) -> dict: prompt = f""" 评估以下回答的质量: 问题:{question} 回答:{answer} 参考上下文:{self._format_context(context)} 请从以下维度评估(0-1分): 1. 准确性:回答是否与上下文一致? 2. 完整性:是否回答了问题的所有方面? 3. 引用性:关键论断是否有引用支撑? 4. 幻觉率:回答中是否有上下文不支持的内容? 输出 JSON:{{"accuracy": 0.0, "completeness": 0.0, "citation": 0.0, "hallucination": 0.0, "needs_retry": false, "reason": "..."}} """ return self.llm.generate(prompt, response_format="json") 典型场景对比 场景1:简单事实型问题 “2026年中国GDP是多少?” ...

2026-06-28 · 3 min · 611 words · 硅基 AGI 探索者
embedding model 2026 chinese retrieval benchmark

Embedding 模型 2026 排行:中文检索场景实测

Embedding 模型是 RAG 系统的基石——检索质量的上限由 Embedding 模型决定。2026 年,中文 Embedding 模型迎来了新一轮洗牌。BGE、Qwen Embedding、Cohere 等新老玩家竞争激烈。本文将在 5 个中文检索场景中实测 12 款主流 Embedding 模型,给出最权威的排行。 一、评测设计 参评模型 模型 维度 最大长度 类型 许可证 BGE-M3 1024 8192 开源 MIT BGE-large-zh-v2 1024 512 开源 MIT Qwen3-Embedding-8B 4096 32768 开源 Apache 2.0 Qwen3-Embedding-0.6B 1024 32768 开源 Apache 2.0 GLM-5-Embedding 1024 8192 开源 Apache 2.0 text-embedding-3-large 3072 8191 闭源 OpenAI API Cohere Embed v4 1024 512 闭源 Cohere API Jina Embeddings v3 1024 8192 开源 CC-BY-NC Voyage-3 1024 32000 闭源 Voyage API GTE-Qwen2-7B 3584 32768 开源 Apache 2.0 Stella-1.5B 1536 131072 开源 MIT E5-Mistral-7B 4096 32768 开源 MIT 评测数据集 数据集 说明 样本数 MTEB-zh 中文通用检索 50,000 DuReader 百度真实问答 100,000 CMRC2018 中文阅读理解 20,000 法律检索 中国法律条文 15,000 医学问答 中文医学QA 12,000 评测指标 NDCG@10:归一化折损累积增益(主指标) Recall@5:Top-5 召回率 MRR:平均倒数排名 二、综合排行 排名 模型 综合 NDCG@10 MTEB-zh DuReader CMRC 法律 医学 1 Qwen3-Embedding-8B 85.3 88.2 86.5 83.7 82.1 85.8 2 Voyage-3 83.7 85.3 84.8 82.1 80.5 85.5 3 text-embedding-3-large 82.8 84.5 83.7 81.3 78.8 85.3 4 BGE-M3 81.5 83.2 82.5 80.1 78.3 83.2 5 GTE-Qwen2-7B 81.2 82.8 81.7 79.5 77.8 83.8 6 GLM-5-Embedding 80.3 82.5 81.2 78.8 79.5 79.2 7 Jina Embeddings v3 79.8 81.3 80.5 77.8 76.2 82.8 8 Stella-1.5B 78.5 80.7 79.3 76.5 75.8 79.8 9 E5-Mistral-7B 78.2 80.2 78.8 76.1 75.2 80.3 10 Qwen3-Embedding-0.6B 77.8 79.8 78.5 75.8 74.8 79.8 11 BGE-large-zh-v2 75.3 77.5 76.2 73.5 72.1 76.8 12 Cohere Embed v4 74.8 76.2 75.5 72.8 70.5 78.5 关键发现: ...

2026-06-28 · 3 min · 635 words · 硅基 AGI 探索者
graphrag production deployment guide

GraphRAG 生产部署指南:知识图谱增强的 RAG 系统

GraphRAG vs 传统 RAG 的本质区别 传统 RAG 的核心问题是"只见树木不见森林"——它能找到局部相关的文本块,但无法理解全局关系。GraphRAG 通过构建知识图谱,让系统具备全局视角和推理能力。 维度 传统 RAG GraphRAG 检索单元 文本块 实体+关系+文本块 全局理解 ❌ ✅ 社区摘要 多跳推理 ❌ ✅ 图遍历 可解释性 低 高(路径溯源) 构建成本 低 高 查询延迟 1-2s 3-10s 架构设计 ┌─────────────────────────────────────────────────────┐ │ GraphRAG 架构 │ ├─────────────────────────────────────────────────────┤ │ │ │ 离线构建 Pipeline │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 文档解析 │→│ 实体抽取 │→│ 关系抽取 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌───────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 图谱构建 │←│ 社区检测 │←│ Embedding │ │ │ └───────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌─────────────┐ │ │ │ 索引持久化 │ │ │ └─────────────┘ │ │ │ │ 在线查询 Engine │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ Query │→│ 路由决策 │→│ 双路检索 │ │ │ │ 理解 │ │ │ │ 向量+图谱 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ ↓ │ │ ┌──────────┐ ┌───────────┐ ┌──────────────┐ │ │ │ 生成+引用 │←│ 信息整合 │←│ 重排序 │ │ │ └──────────┘ └───────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 离线构建 Pipeline 1. 实体与关系抽取 from pydantic import BaseModel from typing import List class Entity(BaseModel): name: str type: str # Person, Organization, Concept, Event, etc. description: str source_chunk_id: str class Relation(BaseModel): source_entity: str target_entity: str relation_type: str description: str confidence: float source_chunk_id: str ENTITY_EXTRACTION_PROMPT = """ 你是一个信息抽取专家。从以下文本中抽取实体和关系。 实体类型:Person, Organization, Concept, Technology, Event, Location 关系类型:works_at, created, related_to, part_of, located_in, depends_on, competes_with 文本: {text} 请以 JSON 格式输出: {{ "entities": [ {{"name": "...", "type": "...", "description": "..."}} ], "relations": [ {{"source": "...", "target": "...", "type": "...", "description": "...", "confidence": 0.0-1.0}} ] }} """ class EntityExtractor: def __init__(self, llm): self.llm = llm def extract(self, text: str, chunk_id: str): prompt = ENTITY_EXTRACTION_PROMPT.format(text=text) result = self.llm.generate(prompt, response_format="json") entities = [ Entity(**e, source_chunk_id=chunk_id) for e in result["entities"] ] relations = [ Relation(**r, source_chunk_id=chunk_id) for r in result["relations"] ] return entities, relations 2. 知识图谱构建 import networkx as nx from community_detection import LeidenAlgorithm class KnowledgeGraph: def __init__(self): self.graph = nx.DiGraph() self.entity_index = {} # name -> node_id def add_entities(self, entities: List[Entity]): for entity in entities: if entity.name not in self.entity_index: node_id = len(self.entity_index) self.entity_index[entity.name] = node_id self.graph.add_node( node_id, name=entity.name, type=entity.type, description=entity.description, source_chunks=[entity.source_chunk_id] ) else: # 合并描述 node_id = self.entity_index[entity.name] self.graph.nodes[node_id]["source_chunks"].append( entity.source_chunk_id ) def add_relations(self, relations: List[Relation]): for rel in relations: if rel.source_entity in self.entity_index and rel.target_entity in self.entity_index: src = self.entity_index[rel.source_entity] tgt = self.entity_index[rel.target_entity] if self.graph.has_edge(src, tgt): # 合并关系 existing = self.graph[src][tgt] existing["relations"].append({ "type": rel.relation_type, "description": rel.description, "confidence": rel.confidence }) else: self.graph.add_edge( src, tgt, relations=[{ "type": rel.relation_type, "description": rel.description, "confidence": rel.confidence }] ) def detect_communities(self): """使用 Leiden 算法进行社区检测""" undirected = self.graph.to_undirected() communities = LeidenAlgorithm().fit(undirected) # 为每个社区生成摘要 for comm_id, nodes in communities.items(): subgraph = self.graph.subgraph(nodes) summary = self._summarize_community(subgraph) for node in nodes: self.graph.nodes[node]["community_id"] = comm_id self.graph.graph.setdefault("community_summaries", {})[comm_id] = summary return communities def _summarize_community(self, subgraph): entities_info = [] for node_id in subgraph.nodes(): node = self.graph.nodes[node_id] entities_info.append(f"{node['name']} ({node['type']}): {node['description']}") relations_info = [] for u, v, data in subgraph.edges(data=True): for rel in data["relations"]: relations_info.append( f"{self.graph.nodes[u]['name']} --{rel['type']}--> {self.graph.nodes[v]['name']}" ) prompt = f""" 请总结以下知识图谱社区的关键信息: 实体: {chr(10).join(entities_info)} 关系: {chr(10).join(relations_info)} 请生成一段简洁的摘要,涵盖主要实体和它们之间的关系。 """ return self.llm.generate(prompt) 3. 索引持久化 class GraphRAGIndex: def __init__(self): self.graph = KnowledgeGraph() self.vector_store = MilvusIndex(dim=1024) self.community_store = CommunityStore() def build(self, documents: List[Document]): # 1. 文本分块与向量化 chunks = document_aware_chunk(documents) for chunk in chunks: embedding = embed_model.encode(chunk.text) self.vector_store.add(id=chunk.id, embedding=embedding, metadata={"text": chunk.text}) # 2. 实体关系抽取 all_entities = [] all_relations = [] for chunk in chunks: entities, relations = extractor.extract(chunk.text, chunk.id) all_entities.extend(entities) all_relations.extend(relations) # 3. 构建知识图谱 self.graph.add_entities(all_entities) self.graph.add_relations(all_relations) # 4. 社区检测与摘要 communities = self.graph.detect_communities() # 5. 持久化 self._persist() def _persist(self): # 图谱存 Neo4j 或 NetworkX pickle nx.write_gpickle(self.graph.graph, "graph.gpickle") # 向量索引已在 Milvus 中持久化 # 社区摘要存数据库 self.community_store.save(self.graph.graph.graph.get("community_summaries", {})) 在线查询引擎 class GraphRAGQueryEngine: def __init__(self, index: GraphRAGIndex, llm): self.index = index self.llm = llm def query(self, question: str) -> str: # 1. 判断查询类型 query_type = self._classify_query(question) if query_type == "global": # 全局型问题 → 社区检索 context = self._global_search(question) elif query_type == "specific": # 具体型问题 → 向量+图遍历 context = self._local_search(question) else: # 混合型 → 双路检索 context = self._hybrid_search(question) # 2. 生成答案 answer = self.llm.generate( prompt=ANSWER_PROMPT.format(question=question, context=context), citations=True ) return answer def _local_search(self, question: str): # 向量检索找到相关文本块 query_emb = embed_model.encode(question) vector_hits = self.index.vector_store.search(query_emb, top_k=10) # 从命中块中提取实体 entities = set() for hit in vector_hits: entities.update(self._extract_entities_from_chunk(hit)) # 图遍历扩展上下文 graph_context = [] for entity_name in entities: if entity_name in self.index.graph.entity_index: node_id = self.index.graph.entity_index[entity_name] # 1-hop 和 2-hop 邻居 neighbors = nx.single_source_shortest_path_length( self.index.graph.graph, node_id, cutoff=2 ) for neighbor_id, hops in neighbors.items(): if hops > 0: node = self.index.graph.graph.nodes[neighbor_id] graph_context.append({ "entity": node["name"], "type": node["type"], "hops": hops, "description": node["description"] }) return { "vector_context": vector_hits, "graph_context": graph_context } def _global_search(self, question: str): # 从社区摘要中检索 community_summaries = self.index.community_store.get_all() # 用 LLM 判断哪些社区相关 relevant = self.llm.generate( prompt=f""" 以下问题与哪些社区摘要相关? 问题:{question} 社区摘要: {json.dumps(community_summaries, ensure_ascii=False)} 返回最相关的 3 个社区 ID。 """ ) return {"community_context": relevant} 生产运维 监控指标 @dataclass class GraphRAGMetrics: # 构建阶段 entity_extraction_rate: float # 每分钟抽取实体数 relation_extraction_rate: float # 每分钟抽取关系数 community_detection_time: float # 社区检测耗时 # 查询阶段 query_latency_p50: float query_latency_p99: float vector_recall: float # 向量检索召回率 graph_coverage: float # 图遍历覆盖率 community_hit_rate: float # 社区命中率 # 质量指标 answer_accuracy: float # 答案准确率 citation_rate: float # 引用覆盖率 hallucination_rate: float # 幻觉率 增量更新策略 class IncrementalUpdater: """GraphRAG 增量更新:只处理新增/修改的文档""" def update(self, new_documents: List[Document], deleted_ids: List[str]): # 1. 删除过期数据 for doc_id in deleted_ids: self._remove_document(doc_id) # 2. 处理新文档 for doc in new_documents: entities, relations = extractor.extract(doc) self.graph.add_entities(entities) self.graph.add_relations(relations) # 3. 局部社区检测(只重新检测受影响的社区) affected_communities = self._find_affected_communities(new_documents, deleted_ids) self._redetect_communities(affected_communities) # 4. 更新向量索引 self.vector_store.upsert(new_documents) 成本与效果 以 10 万篇技术文档为例: ...

2026-06-28 · 5 min · 912 words · 硅基 AGI 探索者
RAG 常见故障排查

RAG 常见故障排查:幻觉、漏检、延迟的根因分析

RAG 故障诊断框架 RAG 系统出问题时,症状往往模糊——“回答不对”、“答非所问”、“太慢了”。2026 年的实践表明,几乎所有 RAG 故障都可以归因到三个核心环节:检索(Retrieval)、生成(Generation)、系统(System)。 故障报告 → 症状分类 → 根因定位 → 修复方案 → 验证 ↓ ┌─────────┼─────────┐ ↓ ↓ ↓ 检索层 生成层 系统层 漏检 幻觉 延迟 误检 偏题 超时 排序错 不完整 成本高 故障1:幻觉——“系统在编造事实” 症状 答案包含上下文中不存在的信息 引用了错误的来源 捏造数据或数字 诊断流程 class HallucinationDiagnostic: def diagnose(self, question: str, answer: str, contexts: list): # 1. 拆分答案为原子论断 claims = self._decompose_claims(answer) # 2. 逐条验证 results = [] for claim in claims: evidence = self._find_evidence(claim, contexts) results.append({ "claim": claim, "has_evidence": evidence["score"] > 0.5, "evidence_text": evidence["text"], "score": evidence["score"] }) hallucinated = [r for r in results if not r["has_evidence"]] return { "total_claims": len(claims), "hallucinated_claims": len(hallucinated), "hallucination_rate": len(hallucinated) / len(claims), "details": results, "likely_causes": self._identify_causes(hallucinated, contexts) } def _identify_causes(self, hallucinated, contexts): causes = [] # 原因1:上下文不足 if len(contexts) < 3: causes.append({ "cause": "context_insufficient", "description": "检索到的上下文数量太少", "fix": "增加 top_k 参数或扩大检索范围" }) # 原因2:上下文不相关 if contexts and all(not self._is_relevant(c) for c in contexts): causes.append({ "cause": "context_irrelevant", "description": "检索到的上下文与问题不相关", "fix": "检查 Embedding 模型质量或分块策略" }) # 原因3:LLM 忽略上下文 if contexts and any(self._is_relevant(c) for c in contexts): causes.append({ "cause": "llm_ignoring_context", "description": "上下文包含相关信息但 LLM 未使用", "fix": "优化 Prompt,强调'仅基于上下文回答'" }) return causes 常见根因与修复 根因 症状 修复方案 检索结果不相关 答案与文档无关 优化 Embedding 模型、加入重排序 上下文太短 缺少关键信息 增加 top_k、扩展上下文窗口 LLM 忽略上下文 编造而非引用 加强 Prompt 约束、降低 temperature 分块切断关键信息 信息碎片化 调整分块策略、增加重叠 模型本身幻觉倾向 即使上下文完整也编造 换用更可靠的模型 Prompt 修复示例 # 修复前(容易幻觉) BAD_PROMPT = "根据以下信息回答问题:{context}\n问题:{question}" # 修复后(抑制幻觉) GOOD_PROMPT = """请严格基于以下参考信息回答问题。 规则: 1. 只使用参考信息中的内容 2. 如果参考信息不足以回答,请说"根据现有信息无法回答" 3. 每个事实陈述后用 [1], [2] 标注来源 4. 不要编造任何信息 参考信息: {context} 问题:{question} 回答:""" 故障2:漏检——“该找到的没找到” 症状 知识库中明明有相关信息,但系统说"不知道" 回答不完整,遗漏关键信息 多文档对比时只引用了一部分 诊断流程 class RetrievalDiagnostic: def diagnose(self, question: str, retrieved: list, ground_truth_docs: list): report = {} # 1. 召回率分析 retrieved_ids = {r.id for r in retrieved} gt_ids = {d.id for d in ground_truth_docs} report["recall"] = len(retrieved_ids & gt_ids) / len(gt_ids) report["missed_docs"] = list(gt_ids - retrieved_ids) # 2. 分析漏检原因 for missed_id in report["missed_docs"]: missed_doc = self._get_doc(missed_id) root_cause = self._analyze_miss(question, missed_doc) report.setdefault("miss_reasons", []).append(root_cause) return report def _analyze_miss(self, question: str, missed_doc: Document): # 原因A: Embedding 相似度过低 q_emb = self.embedder.encode(question) d_emb = self.embedder.encode(missed_doc.content) similarity = cosine_similarity(q_emb, d_emb) if similarity < 0.5: return { "doc_id": missed_doc.id, "cause": "embedding_similarity_low", "similarity": similarity, "fix": "考虑使用 HyDE 或 Query 重写" } # 原因B: 分块导致信息碎片化 if len(missed_doc.content) < 50: return { "doc_id": missed_doc.id, "cause": "chunk_too_short", "fix": "调整分块策略,增大 chunk_size" } # 原因C: 元数据过滤排除了该文档 return { "doc_id": missed_doc.id, "cause": "metadata_filter_excluded", "similarity": similarity, "fix": "检查元数据过滤条件" } 常见漏检模式 模式1: 语义鸿沟 Query: "怎么提高模型准确率" 文档: "模型精度优化方法" ← 同义词但 Embedding 可能不够近 修复: 加入 Query 重写或同义词扩展 模式2: 多跳信息分散 Query: "A和B的区别" 文档: 分别有A和B的描述,但没有对比性文档 修复: 使用多查询策略或 Agentic RAG 模式3: 长尾知识 Query: 某罕见概念 文档: 存在但 Embedding 训练时未见 修复: 加入关键词检索做补充 模式4: 版本过期 Query: 最新信息 文档: 旧版本未更新 修复: 定期增量更新 + 时间戳过滤 故障3:延迟过高——“等了10秒才出结果” 延迟分解 class LatencyProfiler: def profile(self, query: str): timings = {} # 1. Query Embedding t0 = time.time() q_emb = self.embedder.encode(query) timings["embedding"] = time.time() - t0 # 2. 向量检索 t0 = time.time() results = self.vector_store.search(q_emb, top_k=50) timings["vector_search"] = time.time() - t0 # 3. 重排序 t0 = time.time() reranked = self.reranker.rerank(query, results, top_k=5) timings["rerank"] = time.time() - t0 # 4. Prompt 构建 t0 = time.time() prompt = self._build_prompt(query, reranked) timings["prompt_build"] = time.time() - t0 # 5. LLM 生成 t0 = time.time() answer = self.llm.generate(prompt) timings["llm_generate"] = time.time() - t0 timings["total"] = sum(timings.values()) return timings 典型延迟分布 环节 优化前 优化后 优化方法 Embedding 200ms 50ms 本地部署 + 批量 向量检索 500ms 80ms HNSW 参数调优 + 缓存 重排序 800ms 200ms 批量推理 + 减小候选集 LLM 生成 3000ms 1500ms 流式输出 + 更短 Prompt 总计 4500ms 1830ms 优化代码 class OptimizedRAG: def __init__(self): self.semantic_cache = SemanticCache( threshold=0.95, ttl=3600 ) self.query_classifier = QueryClassifier() def query(self, question: str): # 0. 语义缓存检查(~1ms) cached = self.semantic_cache.get(question) if cached: return cached, "cache_hit" # 1. 查询分类:简单 vs 复杂 complexity = self.query_classifier.predict(question) if complexity < 0.3: # 快速通道:跳过重排序 results = self._fast_query(question) else: # 标准通道:完整流程 results = self._full_query(question) # 写入缓存 self.semantic_cache.set(question, results) return results def _fast_query(self, question): """快速通道:向量检索 → LLM(跳过重排序)""" q_emb = self.embedder.encode(question) results = self.vector_store.search(q_emb, top_k=5) return self.llm.generate(question, context=results, stream=True) 故障4:答案偏题——“问的是A,答的是B” 诊断 def diagnose_off_topic(question, answer, contexts): # 检查问题覆盖 question_aspects = extract_question_aspects(question) answer_coverage = check_coverage(answer, question_aspects) # 检查检索相关性 retrieval_relevance = assess_relevance(question, contexts) return { "question_aspects": question_aspects, "covered_aspects": answer_coverage["covered"], "missed_aspects": answer_coverage["missed"], "retrieval_relevance": retrieval_relevance, "root_cause": identify_cause(answer_coverage, retrieval_relevance) } 常见根因 根因 检查方法 修复 Query 理解错误 检查检索 Query 是否与用户意图一致 加入 Query 重写 检索偏向热门内容 检查是否总是检索到相同文档 调整多样性参数 LLM 上下文窗口溢出 检查 Prompt 长度 压缩上下文 多意图问题未拆分 检查问题是否包含多个子问题 Agent 拆解 故障排查清单 □ 检索阶段 □ 检索结果是否相关? → 查看原始检索结果 □ top_k 是否足够? → 检查召回率 □ Embedding 模型是否合适? → 测试语义相似度 □ 分块是否合理? → 检查块边界 □ 是否需要 Query 重写? → 检查 Query 与文档的语义鸿沟 □ 生成阶段 □ Prompt 是否清晰约束? → 检查 Prompt 模板 □ 上下文是否足够? → 检查上下文长度 □ temperature 是否过高? → 降到 0-0.3 □ 模型能力是否足够? → 换更强模型测试 □ 系统阶段 □ 延迟在哪个环节? → Profile 各阶段耗时 □ 缓存是否生效? → 检查缓存命中率 □ 是否有资源瓶颈? → 检查 GPU/CPU/内存 总结 RAG 故障排查的核心是分层诊断:先定位是检索问题还是生成问题,再深入排查具体根因。最高效的排查方法是建立一个端到端的可观测系统,记录每个环节的输入输出和耗时,让故障无处遁形。 ...

2026-06-28 · 4 min · 766 words · 硅基 AGI 探索者
鲁ICP备2026018361号