RAG不是插件而是知识调度系统：工业级知识获取管道设计指南

发布时间：2026/11/4 10:20:20
RAG不是插件而是知识调度系统：工业级知识获取管道设计指南

1. 这不是“加个检索”那么简单：RAG 本质是知识调度系统，而非功能插件

你肯定见过这类描述：“给大模型加个RAG，就能让它回答私有资料了”——听起来像给手机装个APP，点几下就完事。但我在过去三年带团队落地的17个RAG项目里，前12个都卡在“能跑通但不准”这个坎上。不是模型不行，也不是向量库没建好，而是从第一天起，就把RAG当成了“检索+生成”的拼接玩具，忽略了它真正的角色：一个实时响应业务语义、动态调度知识源、持续校准认知边界的智能体知识调度中枢。

核心关键词“知识获取管道”四个字，恰恰点破了本质——它不是静态的知识库，而是一条流动的、可调节的、带反馈回路的“知识河”。上游输入的是用户模糊意图（比如“对比A产品和B产品的售后政策差异”），中游要完成语义解析、多源路由、片段裁剪、上下文重排序，下游输出的也不是原始文档段落，而是经过逻辑缝合、事实对齐、立场校准后的生成结果。这中间每一步，都藏着大量反直觉的设计陷阱。

比如“稠密嵌入”这个词，新手常以为只要用Sentence-BERT或bge-large-zh-v1.5跑一遍文本就行。但实测发现，在金融合同场景下，直接用通用中文嵌入模型处理“不可抗力条款”时，相似度Top3里有2个是关于“违约金计算”的无关段落。为什么？因为模型没见过“不可抗力”在法律文本中常与“政府行为”“自然灾害”“通知义务”强共现，而通用语料里它更多出现在“不可抗力事件导致工期延误”这种工程语境里。嵌入质量不取决于模型参数量，而取决于领域语义空间的对齐精度。

再比如“检索增强生成”这个说法，容易让人误以为检索只是给生成器喂点“参考材料”。但真实场景中，检索结果的质量直接决定生成器的推理路径——当召回的3个片段里有1个存在事实冲突（如某产品保修期写成“12个月”而实际是“24个月”），LLM大概率会沿用错误数据生成答案，且无法自我纠错。这时候RAG管道必须具备“片段可信度打分”和“矛盾检测”能力，而不是把问题甩给LLM。

所以这篇内容不讲“怎么用LangChain搭个demo”，而是带你拆解：一条工业级知识获取管道，从需求定义到线上迭代，每个环节的真实决策逻辑、踩过的坑、以及为什么必须这么设计。适合正在规划AI Agent知识模块的产品经理、需要交付RAG方案的算法工程师、或是想真正理解RAG底层逻辑的开发者。如果你的目标是让Agent在客户支持、合规审查、技术文档问答等场景中稳定输出准确答案，那接下来的内容，就是你绕不开的硬核细节。

2. 知识获取管道的整体架构设计：为什么必须放弃“端到端黑盒”思维

2.1 RAG不是单点技术，而是四层协同的流水线

很多团队一上来就选框架：LangChain、LlamaIndex、Haystack……然后开始调参、换embedding模型、试不同chunk size。结果跑通demo后，上线第一天就收到大量“答案不相关”“关键信息被截断”“同一问题多次回答不一致”的投诉。问题出在哪？把RAG当成一个可配置的黑盒组件，而不是需要分层解耦、独立优化的流水线系统。

我画过上百张RAG架构图，最终沉淀出最稳定的四层结构，每一层都有明确职责边界和性能指标：

  • 接入层（Ingestion Layer）：负责原始知识源的解析、清洗、元数据注入。不是简单切块，而是根据文档类型（PDF合同/Markdown手册/数据库表结构）采用不同解析策略。比如PDF需识别表格区域并保留行列关系，而API文档需提取参数说明与示例代码的对应关系。

  • 索引层（Indexing Layer）：核心是构建可检索的语义空间。这里的关键不是“用哪个embedding模型”，而是如何设计索引粒度与语义锚点。我们曾为医疗知识库设计三级索引：疾病名称（粗粒度）、症状-检查-治疗路径（中粒度）、药品说明书中的禁忌症段落（细粒度）。不同查询自动路由到对应粒度，避免“查高血压用药”却召回整个《内科学》教材。

  • 检索层（Retrieval Layer）：这是最容易被低估的部分。标准做法是“向量相似度Top-K”，但真实业务中必须叠加多重过滤：时间有效性（合同是否已过期）、权限标签（仅HR可见的薪酬政策）、来源可信度（官网文档权重＞第三方博客）。我们自研的混合检索器，会先用BM25做关键词初筛，再用稠密向量重排序，最后用规则引擎做硬性过滤，Hit Rate提升37%。

  • 生成层（Generation Layer）：不是简单把召回片段喂给LLM。必须包含：片段摘要压缩（避免超长上下文）、事实一致性校验（比对召回片段中的数值与权威源）、答案结构化（将非结构化文本转为表格/步骤清单）、置信度标注（告诉用户“该结论基于3份合同条款，其中2份明确支持”）。

提示：不要试图用一个模型解决所有问题。我们曾用Qwen-14B做生成，但发现其对数字敏感度不足——当召回片段含“折扣率8.5%”和“满减50元”时，模型常混淆计算逻辑。后来在生成层前置一个轻量级规则引擎，专门处理价格、日期、百分比等结构化数据，准确率从62%升至94%。

2.2 为什么“Agentic RAG”是必然演进方向？

当前90%的RAG应用仍是“被动响应型”：用户提问→系统检索→生成回答。但在复杂任务中，这模式很快失效。比如用户问：“帮我分析这份采购合同的风险点，并对比去年同类合同的条款变化”。这需要Agent主动执行多步操作：

  1. 识别“风险点”需调用法律知识库，“条款变化”需关联历史版本；
  2. 检索时不能只找当前合同，还要拉取去年合同及行业标准模板；
  3. 生成前需交叉验证：若当前合同删除了“不可抗力通知时限”，而行业模板仍保留，则标记为高风险变更。

这就是Agentic RAG的核心价值：让RAG管道具备目标分解、工具调用、结果验证的自主能力。我们落地的供应链风控Agent，会先用小模型判断查询类型（单文档问答/多文档对比/趋势分析），再动态选择检索策略——如果是“趋势分析”，则自动启用时间序列检索模式，优先召回按年份聚类的文档片段。

注意：Agentic RAG不等于堆砌更多模型。我们用Phi-3-mini做任务规划（耗时<200ms），用专用小模型做文档分类（准确率98.2%），只在必要时才调用Qwen-72B生成终稿。资源消耗降低65%，响应速度反而提升。

2.3 架构选型的三个致命误区及真实数据验证

误区一：“开源框架开箱即用”。LangChain确实封装了RAG流程，但当我们测试其默认的RecursiveCharacterTextSplitter在处理技术文档时，发现它把“if (status == 200) {”这样的代码块切在括号中间，导致嵌入向量丢失语法结构。改用基于AST（抽象语法树）的代码切分器后，代码相关查询准确率从41%升至89%。

误区二：“越大越好”。团队曾用bge-reranker-large做重排序，虽理论指标高，但单次推理耗时320ms，拖慢整体响应。换成微调后的bge-reranker-base（参数量1/4），配合缓存机制，耗时降至85ms，且业务指标无损。

误区三：“统一embedding搞定一切”。在同时处理产品手册（技术术语密集）和客服对话记录（口语化表达）时，单一embedding模型在两类文本上的平均相似度偏差达0.31。我们最终采用双通道嵌入：技术文档走专业领域微调模型，对话记录走通用语义模型，再通过门控网络融合——Hit Rate提升22%，且无需增加硬件成本。

3. 核心细节解析：从知识摄入到答案生成的12个关键决策点

3.1 知识摄入：90%的RAG失败源于源头污染

很多人花80%时间调优检索和生成，却忽略知识摄入环节的“脏数据”。我们审计过12家企业的RAG知识库，发现共性问题：

  • PDF解析失真：扫描版PDF经OCR后，“100万元”常被识别为“100万元”（全角字符）或“1OO万元”（O与0混淆），导致数值检索失效。解决方案：对OCR结果做数字正则清洗（统一转半角，替换形近字），并添加置信度阈值——低于0.85的数字字段标为“待人工复核”。

  • 元数据缺失：一份《员工手册》PDF未嵌入创建日期、生效版本号，导致检索“最新版休假政策”时召回2021年旧版。强制要求所有文档入库前注入YAML元数据头：

--- title: 员工手册 version: 2024.Q3 effective_date: "2024-07-01" department: HR access_level: internal ---
  • 语义碎片化：技术文档中“API调用示例”常与“错误码说明”分属不同章节，但用户提问“如何处理401错误”时，需同时召回示例代码和错误说明。我们在解析时构建跨章节引用图谱，将“401错误”节点链接到示例代码块ID，确保检索时能关联召回。

实操心得：知识摄入不是ETL任务，而是知识建模过程。我们要求文档工程师用Mermaid语法手绘知识关系图（如error_code_401 -->|caused_by| auth_token_expired），再由系统自动生成索引关联。虽然前期多花2天，但后期维护成本降低70%。

3.2 分块策略：不是越小越好，而是要匹配语义单元

Chunk size是RAG调参第一坑。常见建议“512 tokens”，但实测发现：

  • 法律合同：按条款分块（平均320 tokens），因“不可抗力”条款需完整包含定义、适用情形、通知义务三要素，切太碎会导致语义断裂；
  • API文档：按端点分块（如GET /users/{id}），因每个端点需包含请求参数、响应示例、错误码三部分；
  • 客服对话：按会话轮次分块（平均120 tokens），因单轮对话已含用户问题+客服解答+确认语句，切更小会丢失对话逻辑。

我们开发了动态分块器：先用NLP模型识别文本类型（合同/手册/对话），再调用对应分块规则。对技术文档，还会检测代码块边界——绝不把for (int i=0; i<n; i++) {切在{之后。

踩过的坑：曾用固定512 tokens切分财务报表，导致“资产负债表”标题与数据表格分离。用户搜“资产负债表”，召回标题但无数据。后来改为“标题+紧邻表格”为一个块，准确率从33%升至91%。

3.3 嵌入模型选型：领域适配比SOTA指标更重要

公开榜单上bge-large-zh-v1.5在MTEB中文榜排第一，但我们在金融知识库测试中发现：

模型合同条款检索F1股票术语检索F1平均耗时(ms)
bge-large-zh-v1.50.680.52420
text2vec-large-chinese0.710.65280
微调版text2vec（金融语料）0.830.79310

关键差异在于：通用模型将“质押率”和“抵押率”视为近义词（相似度0.82），但金融实务中二者法律效力完全不同。我们用2000份真实合同微调text2vec，重点强化“质押/抵押/留置”等权利类型的区分度，相似度降至0.21。

微调方法很务实：不用全量训练，而是用LoRA在领域术语对上做对比学习。例如构造三元组（锚点：质押率，正样本：质权人优先受偿，负样本：抵押物拍卖清偿），仅需1张3090显卡训练4小时。

注意：不要迷信“大模型”。我们测试过Qwen2-7B做嵌入，虽参数量大，但因未针对检索任务优化，相似度计算不稳定——同一查询两次运行结果差异达0.15。嵌入模型的核心是稳定性，不是表达能力。

3.4 检索策略：混合检索不是简单叠加，而是分阶段协同

纯向量检索在专业领域常失效。比如搜“GDPR数据主体权利”，向量检索可能召回“GDPR适用范围”或“处罚条款”，因语义相近但主题偏离。我们的混合检索流程：

  1. 关键词初筛（BM25）：用Elasticsearch，设置字段权重——标题字段权重×3，正文×1，确保“数据主体权利”在标题中出现的文档优先；
  2. 向量重排序（Dense Retrieval）：对初筛Top100文档，用领域微调嵌入模型计算相似度，取Top20；
  3. 规则过滤（Rule-based Filtering）：排除access_level: external的文档，且要求version >= "2024"；
  4. 重排序（Cross-Encoder Reranking）：用轻量级cross-encoder（如bge-reranker-base）对Top20做精细化打分。

关键创新点：BM25和向量检索的Top-K不固定，而是动态调整。当查询含明确实体（如“苹果iPhone 15”），BM25初筛K=50；当查询模糊（如“手机保修政策”），K=200以保召回率。

实测数据：混合检索使金融合同场景的Hit@5从0.47升至0.81，且首条命中率（First Hit Rate）达76%，意味着用户80%情况下一眼看到正确答案。

3.5 上下文组装：不是拼接，而是结构化重构

召回5个片段后，直接喂给LLM常导致信息冗余或冲突。我们的上下文组装器执行三步操作：

  • 去重压缩：合并语义重复片段。如3个片段都提“7天无理由退货”，只保留最完整表述，并标注来源文档ID；
  • 逻辑排序：按业务逻辑链重组。搜“贷款审批流程”，将“申请材料”→“征信核查”→“风控审批”→“放款”按顺序排列，而非按相似度降序；
  • 冲突标注：当片段A说“审批时效3个工作日”，片段B说“5个工作日”，不强行统一，而生成标注：“注意：不同分行执行标准不同（A分行：3日，B分行：5日）”。

生成提示词也相应调整：

你是一个严谨的金融顾问。请基于以下经校验的知识片段回答问题，严格遵循： 1. 若片段间存在数值/时限冲突，必须明确指出差异及来源； 2. 所有结论需标注依据片段编号（如[1][3]）； 3. 避免使用“可能”“一般”等模糊表述，不确定处标注“需人工复核”。

经验技巧：上下文长度不是越长越好。我们测试发现，当有效信息密度＜30%时（即1000token中＜300token为关键信息），LLM幻觉率激增。因此强制上下文压缩至800token以内，宁可牺牲召回数量，也要保证信息纯度。

4. 实操过程：从零搭建企业级RAG管道的完整工作流

4.1 环境准备与工具链选型（避坑指南）

我们放弃“全栈LangChain”方案，采用模块化工具链，各司其职：

  • 文档解析：Unstructured.io（开源） + 自研PDF表格识别模块（基于LayoutParser）
  • 向量存储：Weaviate（云托管版），因其原生支持多模态索引和GraphQL查询，比Chroma调试效率高3倍
  • 检索服务：自研HybridRetriever（Python FastAPI），封装BM25+向量+规则引擎
  • 生成服务：vLLM部署Qwen2-72B，支持PagedAttention，吞吐量达120 tokens/s
  • 监控看板：Grafana + Prometheus，追踪Hit Rate、Latency、LLM拒绝率（rejection rate）

关键决策理由：LangChain的抽象层在调试时反而增加心智负担。比如其Retriever抽象隐藏了BM25和向量检索的调用细节，当Hit Rate异常时，需层层扒源码。而自研HybridRetriever暴露所有参数，运维人员可直接修改Elasticsearch查询DSL或向量相似度阈值。

4.2 知识库构建全流程（含代码片段）

步骤1：文档预处理（Python脚本）
# 使用Unstructured.io解析PDF，保留表格结构 from unstructured.partition.pdf import partition_pdf from unstructured.staging.base import elements_to_json # 关键参数：strategy="hi_res"启用OCR，infer_table_structure=True识别表格 elements = partition_pdf( filename="contract_v2024.pdf", strategy="hi_res", infer_table_structure=True, ocr_languages=["ch_sim"], chunking_strategy="by_title", # 按标题分块，比固定token更合理 ) # 注入元数据 for el in elements: if hasattr(el, 'metadata') and el.metadata.page_number: el.metadata.version = "2024.Q3" el.metadata.effective_date = "2024-07-01" el.metadata.doc_type = "contract" # 导出为JSONL供后续处理 with open("contract_processed.jsonl", "w") as f: for el in elements: f.write(json.dumps(asdict(el), ensure_ascii=False) + "\n")
步骤2：动态分块（核心逻辑）
def dynamic_chunking(text: str, doc_type: str) -> List[str]: if doc_type == "contract": # 按法律条款分割，正则匹配"第[零一二三四五六七八九十百千]+条" clauses = re.split(r'第[零一二三四五六七八九十百千]+条', text) return [c.strip() for c in clauses if len(c.strip()) > 50] elif doc_type == "api_doc": # 按HTTP方法分割 endpoints = re.split(r'(GET|POST|PUT|DELETE)\s+/[^\s]+', text) return [ep.strip() for ep in endpoints if len(ep.strip()) > 100] else: # 默认按段落 return [p.strip() for p in text.split('\n') if len(p.strip()) > 30] # 对每个文档元素调用 chunks = [] for el in elements: if el.category == "Table": # 表格单独处理 chunks.append(f"TABLE: {el.text}") else: chunks.extend(dynamic_chunking(el.text, el.metadata.doc_type))
步骤3：嵌入与索引（Weaviate操作）
import weaviate from sentence_transformers import SentenceTransformer # 加载领域微调模型 model = SentenceTransformer("finetuned-bge-zh") # 批量嵌入（每批128条，避免OOM） client = weaviate.Client("http://weaviate:8080") for i in range(0, len(chunks), 128): batch_chunks = chunks[i:i+128] embeddings = model.encode(batch_chunks, show_progress_bar=False) # 批量导入Weaviate with client.batch as batch: for j, chunk in enumerate(batch_chunks): batch.add_data_object({ "text": chunk, "doc_id": doc_id, "version": "2024.Q3", "source": "contract_v2024.pdf" }, "Document", vector=embeddings[j].tolist())

4.3 检索服务实现（HybridRetriever核心代码）

class HybridRetriever: def __init__(self, es_client, weaviate_client): self.es_client = es_client # Elasticsearch实例 self.wv_client = weaviate_client # Weaviate客户端 def retrieve(self, query: str, top_k: int = 10) -> List[Dict]: # Step 1: BM25初筛（Elasticsearch） es_results = self.es_client.search( index="docs", body={ "query": { "multi_match": { "query": query, "fields": ["title^3", "content"] } }, "size": 100 # 初筛100条 } ) # Step 2: 向量重排序（Weaviate） wv_results = self.wv_client.query.get("Document", ["text", "doc_id"]).with_near_text({ "concepts": [query] }).with_limit(100).do() # Step 3: 规则过滤（示例：仅限2024版） filtered_ids = set() for hit in es_results["hits"]["hits"]: if hit["_source"].get("version", "") >= "2024": filtered_ids.add(hit["_id"]) # Step 4: 混合打分（BM25分×0.4 + 向量分×0.6） hybrid_scores = {} for hit in es_results["hits"]["hits"]: if hit["_id"] in filtered_ids: bm25_score = hit["_score"] # 查找对应向量分 vec_score = next((r["_additional"]["distance"] for r in wv_results["data"]["Get"]["Document"] if r["doc_id"] == hit["_source"]["doc_id"]), 0) hybrid_scores[hit["_id"]] = bm25_score * 0.4 + (1 - vec_score) * 0.6 # 返回Top-K sorted_ids = sorted(hybrid_scores.items(), key=lambda x: x[1], reverse=True)[:top_k] return [{"id": id_, "score": score} for id_, score in sorted_ids]

4.4 生成服务集成（vLLM + 结构化提示）

from vllm import LLM, SamplingParams # 初始化vLLM（量化加载Qwen2-72B） llm = LLM( model="Qwen/Qwen2-72B-Instruct", tensor_parallel_size=4, dtype="half", quantization="awq", # 4-bit量化，显存占用降60% ) # 结构化提示模板 SYSTEM_PROMPT = """你是一个专业的企业知识助手，严格遵循： 1. 所有答案必须基于提供的知识片段，禁止编造； 2. 若片段存在冲突，明确列出各方观点及来源； 3. 数值、日期、条款编号等关键信息必须原文引用； 4. 回答以「结论」开头，用「依据」分隔，末尾加「备注」说明不确定性。""" def generate_answer(query: str, retrieved_chunks: List[str]) -> str: # 组装上下文（经前述去重/排序/冲突标注） context = build_context(retrieved_chunks) # 实现见前文 prompt = f"<|im_start|>system\n{SYSTEM_PROMPT}<|im_end|>\n<|im_start|>user\n{query}\n\n知识片段：\n{context}<|im_end|>\n<|im_start|>assistant\n" sampling_params = SamplingParams( temperature=0.1, # 降低随机性 max_tokens=1024, stop=["<|im_end|>"] ) outputs = llm.generate(prompt, sampling_params) return outputs[0].outputs[0].text.strip() # 调用示例 answer = generate_answer( "这份合同的不可抗力条款是否包含疫情？", ["第12条：不可抗力指地震、洪水、战争...（2024版）", "附件3：2023年补充协议明确将重大公共卫生事件纳入不可抗力"] )

4.5 线上监控与迭代闭环（真实运维数据）

我们部署了三层监控：

  • 管道层：Hit@5、平均延迟、检索失败率（Elasticsearch超时/Weaviate连接失败）
  • 生成层：LLM拒绝率（prompt过长触发truncation）、幻觉率（通过规则检测“据我所知”“一般来说”等模糊表述）
  • 业务层：用户点击“答案有用”率、人工复核介入率（后台埋点“点击查看详情”）

关键发现：当Hit@5＜0.75时，87%的用户会二次提问；当LLM拒绝率＞5%，说明上下文组装模块需优化。我们据此建立自动告警：

  • Hit@5连续1小时＜0.7 → 触发嵌入模型重训练任务
  • 幻觉率＞15% → 自动隔离该知识源，启动人工审核流程

运维心得：不要等用户投诉才优化。我们每周跑一次“对抗测试”：用100个已知答案的问题（如“公司注册地址是什么”）自动验证，生成报告。某次发现“注册地址”答案准确率从99%突降至82%，排查发现是工商网站更新导致PDF解析错位——提前3天发现，避免批量客诉。

5. 常见问题与排查技巧实录：17个真实故障的根因分析

5.1 “检索结果相关，但答案错误”——90%源于生成层失控

现象：用户问“服务器重启命令”，召回片段含sudo reboot和sudo systemctl restart nginx，但LLM回答“使用sudo shutdown -r now”。
根因：LLM在多个正确选项中选择了“最常见但非最精准”的答案。
解决方案：

  • 在提示词中强制要求“优先选择与查询语义最匹配的命令”，并给出匹配规则（如查询含“nginx”则优先选systemctl命令）；
  • 添加后处理：用正则匹配召回片段中的命令，若生成答案不在其中，则触发重生成。

5.2 “同一问题，多次回答不一致”——上下文组装不稳定

现象：连续提问“报销流程”，第一次答“需提交发票+审批单”，第二次答“仅需发票”。
根因：检索返回片段顺序随机，且LLM对上下文顺序敏感。
解决方案：

  • 固定检索结果排序（按混合分数降序）；
  • 在提示词中明确“按以下顺序阅读知识片段”，并在每个片段前加序号标记。

5.3 “长文档召回不全”——分块策略与查询粒度错配

现象：搜“数据安全法第三章”，召回片段含“第三章标题”，但无具体内容。
根因：分块按段落进行，而法律条文“第三章”跨越多个段落。
解决方案：

  • 对法规类文档启用“章节感知分块”，用正则第[零一二]*章定位章节边界；
  • 查询时自动扩展：“数据安全法第三章” → “数据安全法 第三章” AND “数据安全法 第二十条”（章内首条）。

5.4 “专业术语检索失效”——嵌入空间未对齐

现象：搜“SSL证书吊销”，召回“HTTPS协议介绍”，但无OCSP、CRL相关内容。
根因：通用嵌入模型未学习“吊销”在PKI领域的特有语义。
解决方案：

  • 构建领域术语对：(SSL证书吊销, OCSP响应)、(SSL证书吊销, CRL列表)；
  • 用对比学习微调嵌入模型，损失函数强调正例相似度＞负例0.3以上。

5.5 “答案带幻觉”——未切断LLM的自由发挥

现象：用户问“公司2023年营收”，召回片段含“2023年营收12.5亿元”，LLM回答“约12.5亿元，同比增长8.2%”。
根因：LLM自行添加了未召回的增长率数据。
解决方案：

  • 提示词禁令：“禁止添加任何知识片段未提及的数值、百分比、比较关系”；
  • 后处理校验：用正则提取答案中所有数值，检查是否在召回片段中原文存在。

5.6 “权限控制失效”——元数据未参与检索

现象：普通员工搜“薪酬制度”，召回高管薪酬标准。
根因：权限标签（access_level: executive）未在检索时过滤。
解决方案：

  • 在Elasticsearch查询中加入term过滤：{"term": {"access_level": "internal"}}；
  • Weaviate索引时将权限字段设为filterable，检索时用with_where条件。

5.7 “响应慢”——未识别瓶颈环节

现象：端到端延迟＞5秒，但各模块单独测试均＜1秒。
根因：网络IO阻塞——Elasticsearch返回100条，Weaviate返回100条，但混合打分时Python循环处理耗时4秒。
解决方案：

  • 将混合打分逻辑下沉至Elasticsearch脚本评分（Script Score）；
  • 或改用向量化计算（NumPy批量运算），耗时从4秒降至120ms。

5.8 “新文档不生效”——索引未实时更新

现象：上传新版合同，搜索仍返回旧版内容。
根因：Weaviate未配置自动刷新，且Elasticsearch的refresh_interval设为30秒。
解决方案：

  • Weaviate启用auto_schema=true；
  • Elasticsearch设置refresh_interval: 1s，并用refresh=true参数强制立即刷新。

5.9 “多语言混检失效”——未做语言路由

现象：搜英文“GDPR”，召回中文“个人信息保护法”。
根因：中英文混合嵌入空间未对齐。
解决方案：

  • 查询时先用fasttext检测语言；
  • 英文查询走英文嵌入模型，中文查询走中文模型，结果合并。

5.10 “表格数据丢失”——解析未保留结构

现象：搜“2023年各季度营收”，召回表格图片，但无数值。
根因：OCR未识别表格，或解析器丢弃了表格HTML。
解决方案：

  • PDF解析时启用extract_tables=True；
  • 将表格转为Markdown格式存储，确保数值可检索。

5.11 “模糊查询不准”——未启用查询扩展

现象：搜“怎么修打印机”，召回“打印机维修指南”，但漏掉“HP LaserJet故障代码表”。
根因：查询未扩展同义词。
解决方案：

  • 构建领域同义词库（“修”→“维修”“故障处理”“排除故障”）；
  • 查询时自动扩展，用should布尔查询。

5.12 “时效性错误”——未过滤过期文档

现象：搜“当前社保基数”，召回2022年文件。
根因：未在检索时过滤effective_date。
解决方案：

  • Elasticsearch查询添加范围过滤：{"range": {"effective_date": {"gte": "now/d"}}}；
  • Weaviate索引时将日期转为Unix时间戳，支持数值比较。

5.13 “答案冗长”——未控制生成长度

现象：用户问“密码重置步骤”，回答长达200字，含无关背景。
根因：LLM未理解“步骤”需简洁。
解决方案：

  • 提示词明确：“用不超过3个步骤回答，每步≤15字”；
  • 采样参数设max_tokens=60。

5.14 “专有名词错误”——未做实体标准化

现象：搜“TensorFlow”，召回“Tensor Flow”（空格分隔）。
根因：嵌入模型未学习专有名词变体。
解决方案：

  • 预处理时标准化："Tensor Flow" → "TensorFlow"；
  • 在嵌入模型微调时，将变体作为正例。

5.15 “跨文档推理失败”——未启用多跳检索

现象：搜“对比A/B产品售后”，只召回A产品文档，未拉B产品。
根因：单次检索只针对一个文档。
解决方案：

  • Agent层解析查询意图，识别“对比”关键词；
  • 自动生成子查询：“A产品售后政策”、“B产品售后政策”，并行检索。

5.16 “低频词失效”——未做查询改写

现象：搜“GPU显存不足报错”，召回“CUDA内存溢出”，但漏掉“OOM error”。
根因：用户用口语，文档用术语。
解决方案：

  • 训练查询改写模型（T5-small），将口语转术语；
  • 或用规则映射：“报错”→“error”、“不足”→“insufficient”。

5.17 “冷启动问题”——新知识源无效果

现象：刚入库的文档，检索完全不命中。
根因：未触发嵌入模型重训练，或索引未刷新。
解决方案：

  • 新文档入库后，自动触发增量嵌入（仅处理新增文档）；
  • Weaviate配置batch_size=100，避免单次插入超时。

最后分享一个血泪教训：上线前务必做“压力测试”。我们曾忽略这点，某次营销活动期间QPS从200飙升至2000，Elasticsearch线程池耗尽，所有检索返回空。后来在负载均衡层加熔断