企业官网建设流程全解析

1. 这不是“加个知识库”那么简单：RAG 在 AI Agent 架构里到底扮演什么角色？

你肯定见过这样的场景：一个号称“智能”的客服机器人，面对用户问“我们上个月华东区的退货率是多少”，它要么沉默，要么胡编乱造——明明后台数据库里就有这张销售报表，它却像没看见一样。这不是模型不够大，而是它根本不知道该去哪找答案。这就是典型的“知识获取管道”缺失。RAG（Retrieval-Augmented Generation）不是给大模型塞一本词典，而是给它配了一位经验老到的图书管理员+速记员+摘要专家三位一体的助手。它负责在你提问的瞬间，从海量、分散、格式各异的内部资料里，精准捞出最相关的几段原文，再把它们干净利落地喂给大模型，让它基于真实依据作答。所以，RAG 在 AI Agent 体系里，是那个决定“Agent 知道什么”的底层基础设施，而不是一个可有可无的插件。它直接决定了 Agent 的可信度、专业性和业务深度。如果你正在从零搭建一个能真正落地的 AI Agent，比如一个能读懂公司财报、调取 ERP 数据、解析合同条款的业务助手，那么 RAG 就是你必须亲手打磨的第一道工序。它不解决“怎么生成语言”的问题，它解决的是“生成的语言有没有根”的问题。我做过三个企业级 Agent 项目，凡是跳过 RAG 直接用纯 LLM 的，上线后第一个月就被业务部门打回重做；而把 RAG 管道当成核心模块来设计、测试、压测的，哪怕模型小一点，用户反馈反而更稳、更准、更敢用。这背后没有玄学，只有三件事：检索的精度、召回的时效、注入的干净度。接下来，我们就一层层拆开这个“知识获取管道”，看看它里面到底装了什么、怎么装、装不好会卡在哪。

2. RAG 管道不是流水线，而是一套精密协作系统：从数据进来到答案生成的全链路拆解

很多人一上来就猛敲代码，pip install langchain，然后照着教程把 PDF 丢进去建个向量库，以为这就叫 RAG。结果跑起来发现：查“2024年Q3营收”，返回的却是2023年年报里的一页无关表格；或者查“客户A的合同违约条款”，返回了十份合同里所有带“违约”二字的段落，但没标出哪一份才是客户A的。问题不在代码，而在对 RAG 管道本质的理解偏差——它根本不是一条单向流水线，而是一个由四个核心环节紧密咬合、互相制约的闭环协作系统。这四个环节分别是：数据接入与预处理（Ingestion）、索引构建与存储（Indexing）、查询理解与检索（Retrieval）、上下文融合与生成（Generation）。漏掉任何一个，或者只优化其中一个，整个管道就会失衡。我拿自己去年做的一个制造业设备知识库项目举个真实例子：客户要求 Agent 能回答“XX型号泵的常见故障代码及处理步骤”。我们最初只优化了最后一步 Generation，用了最强的 72B 模型，结果回答天花乱坠，但全是通用维修手册里的废话，没一句是客户自己写的《XX泵现场排故SOP》里的实操内容。后来我们回溯发现，问题出在 Ingestion 环节——原始 PDF 是扫描件，OCR 识别把“E01”错识成“C01”，导致所有含“E01”的故障条目根本没进索引；同时 Indexing 时用了默认的 chunk size=512，把“故障代码：E01 → 原因：压力传感器失效 → 处理：更换传感器（见第3.2节）”这一整条逻辑硬生生切成了三段，检索时只召回了“压力传感器失效”，没了上下文，模型当然瞎猜。所以，RAG 管道的成败，80% 取决于前两个环节的扎实程度，剩下 20% 才轮到模型发挥。下面我们就按这个真实协作逻辑，逐个深挖。

2.1 数据接入与预处理（Ingestion）：不是“扔进去”，而是“读懂再拆解”

Ingestion 是整个 RAG 管道的源头活水，但它常被当成最枯燥的体力活。错。这是决定知识质量上限的第一关。它的核心任务不是把文件“存进去”，而是把非结构化/半结构化数据，“翻译”成机器可理解、可检索、可关联的语义单元。这里的关键动作有三个：格式解析、语义分块、元数据注入。

• 格式解析：别再迷信“PDF 解析万能”。不同来源的 PDF 差异巨大。扫描件 PDF 需 OCR（推荐pymupdf+easyocr组合，比pdfplumber对复杂版式鲁棒得多）；带图层的 PDF（如 Adobe InDesign 导出）用pdfplumber更准；而 Word 或 Excel，直接用python-docx和openpyxl读取原生结构，能保留标题层级、表格边框、公式等关键语义。我吃过一次大亏：客户给的设备手册是 Word，我们用pdfplumber先转 PDF 再解析，结果所有表格都塌成一团乱码，后期检索完全失效。后来改用python-docx直接读，表格自动变成<table>结构，连行头列头都保留，检索时就能按“表名+行关键词”精准定位。

• 语义分块（Chunking）：这是最容易被拍脑袋决定的环节。网上教程动辄说“chunk size=512”，但这是毒药。分块不是切香肠，而是按语义边界切蛋糕。原则就一条：每个 chunk 必须是一个完整、独立、可自解释的信息单元。比如技术文档里的“故障代码表”，如果按字数硬切，可能把“E01：压力传感器失效”和“处理方案：更换传感器”切到两个 chunk 里，检索时只召回前半句，模型就只能瞎猜。正确做法是：先用 NLP 工具（如spacy）识别段落标题、列表项、表格边界；对表格，按行或按逻辑组（如“代码-原因-处理”三列一组）切；对手册，按“章节→子章节→要点”三级结构切，每个 chunk 标题为“[章节名][子章节名][要点序号]”。我们最终在设备手册项目里，定义了 7 种分块策略，对应不同文档类型，全部写成配置文件，由文档类型自动路由。

• 元数据注入：这是让 RAG “懂上下文”的秘密武器。光有文本不够，还得告诉系统“这段话是谁说的、在哪说的、什么时候说的、对谁说的”。元数据不是可选项，是必选项。基础字段至少包括：source_file（原始文件名）、page_number（页码）、section_title（所在章节）、doc_type（手册/合同/SOP）、last_modified（最后更新时间）。更高级的，可以加confidence_score（人工标注的该段信息可靠性）、access_level（涉密等级）。这些元数据不参与向量化，但会在检索后作为过滤条件（filter）或重排序（rerank）的依据。比如，当用户问“最新版操作规范”，系统就能优先召回last_modified最近的 chunk；问“仅限工程师查看的内容”，就能用access_level过滤。我们曾用元数据过滤，把检索结果从平均 12 条锐减到 3 条，且 100% 相关，大大减轻了 LLM 的负担。

提示：Ingestion 环节最大的坑，是把“能跑通”当成“跑得好”。建议每次新增一种文档类型，都做三件事：抽样 10 份典型文件，人工检查解析结果是否保真；随机选 5 个关键词，手动验证分块后能否完整召回相关语义；用真实业务问题测试端到端效果。这三步做完，才能进下一环。

2.2 索引构建与存储（Indexing）：向量不是万能钥匙，它只是门锁的一部分

Indexing 环节常被简化为“把 chunk 向量化，存进向量数据库”。这就像说“把书放进图书馆，就等于建好了知识库”。错。向量索引只是整个索引体系的冰山一角，它解决的是“语义相似性匹配”，但业务世界里，更多时候需要的是“精确匹配”、“范围匹配”、“布尔逻辑匹配”。一个健壮的 RAG 索引，必须是混合索引（Hybrid Index）：向量索引 + 关键词索引 + 元数据索引 + 图谱索引（可选），四者协同工作。

• 向量索引（Vector Index）：这是 RAG 的招牌。选型关键看三点：精度、速度、成本。开源首选FAISS（Facebook 开源，内存占用低，适合中小规模）或Chroma（API 简洁，内置重排序，新手友好）；商用或超大规模，Pinecone（托管服务稳定，API 成熟）或Weaviate（原生支持 GraphQL 查询，元数据过滤强大）。参数上，embedding model是灵魂。别盲目追大：text-embedding-3-large虽好，但贵且慢；bge-m3（中文强）或nomic-embed-text-v1.5（开源免费，效果接近 GPT-4 embedding）是性价比之王。我们实测，在中文设备手册场景，bge-m3的 hit rate（检索命中率）比text-embedding-ada-002高 18%，且响应快 40%。向量维度也别硬套 1536，bge-m3输出 1024 维，足够用。

• 关键词索引（Keyword Index）：向量索引怕“精确术语”。比如用户搜“E01”，向量可能召回一堆讲“故障”的 chunk，但未必包含“E01”这个 exact code。这时就需要传统倒排索引（如Elasticsearch或Meilisearch）。我们把它和向量库并联部署，用户查询时，先走关键词索引捞出所有含“E01”的 chunk ID，再把这些 ID 作为候选集，送入向量库做二次精排。这样既保证了精确性，又保留了语义泛化能力。

• 元数据索引（Metadata Index）：前面注入的元数据，必须有独立索引支撑。Elasticsearch是最佳选择，它天生为结构化查询而生。比如，用户问“请列出所有2024年发布的安全公告”，系统就能直接用doc_type: "security_notice" AND last_modified: [2024-01-01 TO 2024-12-31]精准过滤，不用遍历所有向量。

• 图谱索引（Graph Index）（进阶）：当知识间存在强关系时（如“泵A的备件是阀B，阀B的供应商是公司C”），纯向量检索会失效。此时需引入图数据库（如Neo4j），把实体（泵、阀、公司）和关系（供应、属于、兼容）建模成图。RAG 查询时，先用向量找到“泵A”，再沿“备件”关系跳转到“阀B”，再跳到“公司C”，形成知识链。我们一个汽车售后项目就用了这招，把“故障代码→部件→维修工单→历史案例”串成图，用户问“E01代码最近三次维修用了什么配件”，答案秒出，而纯向量库得靠运气。

注意：混合索引不是堆砌工具，而是分层调度。我们设计了一个轻量级路由层：用户 query 进来，先做 NER（命名实体识别），识别出数字（E01）、日期（2024）、专有名词（泵A）；再根据识别结果，动态决定启用哪些索引。比如含数字，必启关键词索引；含日期范围，必启元数据索引；否则主走向量索引。这套路由逻辑，让整体检索准确率提升了 32%。

2.3 查询理解与检索（Retrieval）：不是“搜一下”，而是“读懂你再找”

Retrieval 环节常被当成黑盒：query 输入，一堆 chunk 输出。但现实是，90% 的 bad retrieval 都源于 query 本身没被正确理解。用户的自然语言提问，充满歧义、省略、口语化，比如“那个上次说要换的零件”，“上次”指哪次？“那个”指哪个？“要换”是计划还是已执行？RAG 系统必须在这个环节做三件事：Query 重写（Query Rewriting）、多路并行检索（Multi-Vector Retrieval）、结果重排序（Reranking）。

• Query 重写：这是提升 recall（召回率）的利器。核心思想是：把用户的一句话，扩展成多个等价、互补的检索表达式。常用方法有：

  • 同义词扩展：用SynonymNet或WordNet加载行业词典，把“泵”扩展为“离心泵、齿轮泵、柱塞泵”；
  • 意图补全：用一个小的 fine-tuned LLM（如Phi-3-mini），把“E01怎么修”重写为“E01故障代码的处理步骤、解决方案、维修指南”；
  • 上下文注入：如果这是对话中的第二轮问题，把上一轮的 context（如“用户刚问了XX型号泵”）拼接到当前 query 里，变成“XX型号泵的E01故障代码处理步骤”。我们用一个 1.5B 参数的 LoRA 模型做重写，耗时 <200ms，但让 top-5 hit rate 从 68% 提升到 89%。

• 多路并行检索：别只依赖一种检索方式。我们固定采用“三路并行”：

  1. 向量检索：用重写后的 query 向量化，在向量库中找 top-k；
  2. 关键词检索：用原始 query 的关键词（去掉停用词），在关键词库中找 top-k；
  3. 元数据检索：用 query 中的结构化信息（如日期、ID、类型），在元数据库中过滤。 三路结果合并去重，再统一交给 reranker。这比单一路检索，能覆盖更多样化的用户表达。

• 结果重排序（Reranking）：向量库返回的 top-k，只是按余弦相似度排的，但“相似”不等于“相关”。Reranker 是一个更小、更精的模型（如bge-reranker-base），它接收 query + chunk pair，输出一个更精准的相关性分数。它能理解“E01”和“压力传感器失效”比和“泵的安装步骤”更相关，即使后者向量距离稍近。我们实测，加了 reranker 后，top-3 的准确率从 71% 跃升至 94%，且 reranker 模型小（<500MB），推理快（<100ms），性价比极高。

实操心得：Retrieval 环节最值得投入的，不是换更大的模型，而是做好 Query 重写和 reranking。前者解决“用户怎么说”，后者解决“什么才真相关”。我们曾用一个 300 行的 Python 脚本实现基础重写+rerank，效果碾压了直接用 72B 模型做 end-to-end 生成。记住：RAG 的智慧，70% 在检索侧，30% 在生成侧。

2.4 上下文融合与生成（Generation）：不是“把 chunk 塞给 LLM”，而是“教它怎么用”

Generation 是 RAG 管道的最后一环，也是最容易被过度设计的一环。很多人花大力气调 prompt，写几十行 system message，试图让 LLM “完美整合”所有检索结果。结果往往是：LLM 把五份不同来源的 chunk 东拼西凑，生成一段看似合理、实则矛盾的废话。问题出在“融合”二字——不是简单拼接，而是结构化注入。核心在于：控制上下文长度、明确指令角色、强制引用溯源。

• 上下文长度控制：别一股脑把 top-5 chunk 全塞进去。LLM 的 attention 机制对长上下文并不友好，尤其当 chunk 间有冲突信息时（如两份 SOP 对同一故障有不同处理步骤），模型会自行“脑补”一个折中方案，而这恰恰是最危险的。我们的铁律是：最多注入 3 个 chunk，且必须经过 reranker 排序，只取 top-3。对每个 chunk，还做截断：只保留与 query 最相关的 1-2 句，删掉所有冗余描述。实测表明，3 chunk * 100 字 = 300 字的上下文，比 5 chunk * 200 字 = 1000 字的上下文，生成答案的准确率高 22%，且幻觉率下降 40%。

• 明确指令角色：System prompt 不是越长越好，而是越精准越好。我们固定使用一个 5 行 prompt：

  你是一名资深[领域]工程师，只根据提供的参考资料回答问题。 若参考资料中无明确答案，必须回答“未找到相关信息”，禁止猜测。 回答必须简洁，直接给出结论，不要解释原理。 所有结论必须标注来源，格式为[来源文件名, 页码]。 若参考资料存在冲突，指出冲突点，并说明依据。

  这个 prompt 把 LLM 从“自由创作家”强行拉回“严谨执行者”，效果立竿见影。之前用户问“E01代码是否需要停机处理”，模型会说“一般建议停机，但也可带电操作”，现在它会说“必须停机处理[XX泵维护手册, P23]”。

• 强制引用溯源：这是建立用户信任的基石。我们不仅要求模型在答案中标注来源，还要求前端把来源做成可点击的链接，用户一点就能看到原始 chunk。技术上，我们在 prompt 里明确写出每个 chunk 的唯一 ID（如chunk_id: doc_001_p23），并要求模型在答案中引用这个 ID。后端再根据 ID 渲染成链接。这个小功能，让客户满意度调查中“答案可信度”一项，从 62% 跃升至 91%。

提示：Generation 环节的终极目标，不是让答案“更华丽”，而是让答案“更可靠”。牺牲一点文采，换取 100% 的可追溯性，是 RAG 产品的分水岭。我见过太多项目，因为怕答案“太干”，加了一堆修饰词，结果用户一追问“这个结论在哪写的？”，系统哑火——信任一旦崩塌，就再也建不起来。

3. 从理论到落地：一个可复现的 RAG 管道最小可行版本（MVP）

光讲原理不够，你得马上能动手。下面是一个我在三个项目里反复验证、删繁就简、确保 1 小时内能跑通的 RAG MVP 方案。它不追求炫技，只保证核心链路健壮、可调试、可扩展。所有工具都是开源、免费、社区活跃的，避免任何商业闭源依赖。

3.1 环境与工具栈：极简但够用

• Python 版本：3.10+（避免新语法兼容问题）
• 核心库：
  • langchain-community==0.3.10（提供基础 RAG 组件，注意用 community 版，core 版已弃用）
  • chromadb==0.4.24（轻量级向量数据库，单机部署，无需额外服务）
  • sentence-transformers==2.3.1（本地运行 embedding model，BAAI/bge-m3）
  • llama-cpp-python==0.2.79（本地运行 LLM，推荐TheBloke/Llama-3.2-3B-Instruct-GGUF，3B 模型，CPU 可跑，响应快）
  • unstructured==0.10.30（强力文档解析，支持 PDF/DOCX/HTML/PPTX，比 PyPDF2 强太多）
• 为什么选这些？
  ChromaDB零配置，pip install chromadb后chroma_client = chromadb.Client()一行启动；
  bge-m3是目前中文开源 embedding 的天花板，且支持多粒度（dense/sparse/colbert），我们只用 dense；
  llama-cpp-python让你在笔记本上就能跑 LLM，不用申请 API key，调试时想改 prompt 就改，秒生效；
  unstructured对扫描 PDF 的 OCR 支持最好，内置pdfminer和tesseract双引擎，自动 fallback。

3.2 完整代码：可直接复制粘贴运行

# rag_mvp.py import os from pathlib import Path from typing import List, Dict, Any from unstructured.partition.auto import partition from sentence_transformers import SentenceTransformer from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import LlamaCpp from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 文档解析与分块 def load_and_chunk_docs(doc_path: str) -> List[str]: """加载单个文档，解析，按语义分块""" # 使用 unstructured 解析 elements = partition(filename=doc_path) # 合并连续文本块，去除页眉页脚等噪音 text_blocks = [] for el in elements: if hasattr(el, 'text') and el.text.strip() and len(el.text.strip()) > 20: text_blocks.append(el.text.strip()) # 简单语义分块：按空行分割，每块至少 100 字 full_text = "\n\n".join(text_blocks) chunks = [chunk.strip() for chunk in full_text.split("\n\n") if len(chunk.strip()) > 100] return chunks # 2. 构建向量库 def build_vectorstore(chunks: List[str], persist_dir: str = "./chroma_db"): """用 bge-m3 构建 Chroma 向量库""" # 初始化 embedding model model_name = "BAAI/bge-m3" embeddings = HuggingFaceEmbeddings( model_name=model_name, model_kwargs={'device': 'cpu'}, # CPU 足够，GPU 非必需 encode_kwargs={'normalize_embeddings': True} ) # 创建 Chroma DB vectorstore = Chroma.from_texts( texts=chunks, embedding=embeddings, persist_directory=persist_dir ) vectorstore.persist() return vectorstore # 3. RAG 链构建 def create_rag_chain(vectorstore: Chroma, llm_path: str): """构建完整的 RAG 链""" # LLM 加载（本地 GGUF） llm = LlamaCpp( model_path=llm_path, temperature=0.1, # 降低随机性，保证答案稳定 max_tokens=512, n_ctx=2048, verbose=False ) # Prompt 模板（极简有效版） template = """你是一名专业助手，严格根据以下参考资料回答问题。 参考资料： {context} 问题：{question} 回答（必须简洁，直接给出结论，若无依据则回答'未找到相关信息'）：""" prompt = ChatPromptTemplate.from_template(template) # RAG 链 retriever = vectorstore.as_retriever(search_kwargs={"k": 3}) rag_chain = ( {"context": retriever, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser() ) return rag_chain # 4. 主流程 if __name__ == "__main__": # 配置路径 DOC_PATH = "./manual.pdf" # 替换为你自己的 PDF LLM_PATH = "./models/Llama-3.2-3B-Instruct.Q4_K_M.gguf" # 下载地址见文末 # 步骤1：解析文档 print("Step 1: Parsing document...") chunks = load_and_chunk_docs(DOC_PATH) print(f"Loaded {len(chunks)} chunks") # 步骤2：构建向量库 print("Step 2: Building vectorstore...") vectorstore = build_vectorstore(chunks) # 步骤3：创建 RAG 链 print("Step 3: Creating RAG chain...") rag_chain = create_rag_chain(vectorstore, LLM_PATH) # 步骤4：测试查询 print("Step 4: Testing query...") test_question = "E01 故障代码的处理步骤是什么？" result = rag_chain.invoke(test_question) print(f"Question: {test_question}") print(f"Answer: {result}")

3.3 运行前必做三件事

1. 下载模型文件：

   • LLM：去 Hugging Face 搜索TheBloke/Llama-3.2-3B-Instruct-GGUF，下载Llama-3.2-3B-Instruct.Q4_K_M.gguf（约 2GB，Q4 量化，平衡速度与精度）；
   • Embedding：bge-m3会自动下载，首次运行较慢，耐心等待。

2. 准备测试文档：

   • 别用网上的“测试 PDF”，用你真实业务中的一份文档（哪怕只有 2 页）。我们第一次测试，就用了一份真实的《XX设备快速入门指南》，里面真有“E01”故障代码，效果立刻可见。

3. 调整分块逻辑：

   • 代码里load_and_chunk_docs是极简版，实际项目中，你需要根据文档类型替换为更精细的分块逻辑（如前面讲的表格识别、章节识别）。但 MVP 阶段，先跑通，再优化。

实操心得：这个 MVP 的价值，不在于它多先进，而在于它让你在 60 分钟内，亲眼看到“知识获取管道”如何工作。当你输入一个问题，屏幕上跳出一个带着真实出处的答案，那种“它真的懂了”的感觉，是任何教程都无法替代的。我建议所有初学者，第一周的任务就是把这个 MVP 跑通 10 次，每次换一份不同的文档，观察 chunk 数量、检索结果、答案质量的变化。这才是理解 RAG 的起点。

4. RAG 管道的暗礁与灯塔：那些没人明说，但踩过就忘不了的实战陷阱

RAG 看似简单，但真正落地时，90% 的时间都花在填坑上。这些坑往往藏在文档的缝隙里、社区的只言片语中、甚至是你自己想当然的假设里。下面是我三年来，在五个项目里踩过的、最痛也最值的七个坑，每一个都附带了“当时怎么错的”和“现在怎么防的”真实记录。

4.1 坑一：Embedding 模型的“中文幻觉”——你以为它懂中文，其实它在猜

当时怎么错的：
项目初期，我们选了当时很火的all-MiniLM-L6-v2，英文 benchmark 很高。测试时用“苹果手机”搜“iPhone”，召回率不错。但一到真实业务场景，用“泵的轴承温度”搜“轴承过热”，结果召回的全是“电机温度”“外壳温度”——模型把“泵”和“轴承”当成两个孤立词，没学懂“泵的轴承”这个复合实体。用户问“XX泵的轴承温度报警阈值”，它返回了“电机绕组温度报警值”，差之毫厘，谬以千里。

现在怎么防的：

• 永远用中文专用模型：bge-m3、text2vec-large-chinese、nomic-embed-text-v1.5。它们在中文语料上专门训练，对“的”字结构、“XX型号”、“第X章”等中文特有模式敏感。
• 必须做领域微调：哪怕只用 100 对“问题-答案”样本，用 LoRA 微调bge-m3的最后两层，效果提升肉眼可见。我们一个电力项目，微调后对“断路器”“隔离开关”等专业术语的召回率，从 58% 提升到 89%。
• 验证方法：别只看 cosine similarity。写个脚本，随机抽 50 个业务关键词（如“E01”“轴承”“SOP-2024”），手动检查 top-3 返回的 chunk 是否真相关。不达标，换模型。

4.2 坑二：Chunk Size 的“甜蜜陷阱”——越大越好？不，是越准越好

当时怎么错的：
为了“提高信息完整性”，我们把 chunk size 设为 1024，认为这样能保留更多上下文。结果，一份 50 页的手册，被切成不到 50 个 chunk。用户问“如何校准传感器”，系统返回一个 800 字的 chunk，里面包含了“校准步骤”“注意事项”“故障排除”“备件清单”四大块。LLM 读完，开始自由发挥，把“注意事项”里的“勿用酒精擦拭”和“故障排除”里的“信号丢失”组合，生成了“用酒精擦拭会导致信号丢失”这种荒谬结论。

现在怎么防的：

• Chunk Size 是结果，不是参数：先分析文档结构，再定 size。技术手册，按“故障代码表”一行一个 chunk；SOP，按“步骤1/2/3”每个步骤一个 chunk；合同，按“条款1.1/1.2”每个条款一个 chunk。
• 强制语义边界：用正则或 NLP 工具识别标题（^##.*$）、列表项（^\d+\..*$）、表格行（^\|.*\|$），在这些边界处切分，宁可 chunk 少，也不跨边界。
• 验证标准：每个 chunk 必须能独立回答一个原子问题。比如，一个 chunk 的标题是“E01：压力传感器失效”，那它就应该包含“现象”“原因”“处理”三要素，且不依赖其他 chunk。

4.3 坑三：检索的“幸存者偏差”——你看到的 top-k，只是它愿意给你看的

当时怎么错的：
我们一直以为，向量库返回的 top-3，就是最相关的三个。直到有一次，用户问“E01 是否影响保修”，我们查了半天没找到答案，最后人工翻文档，发现答案在第 47 页一个不起眼的脚注里：“E01 故障属人为操作失误，不享受保修”。这个脚注只有 20 个字，向量化后和“E01”的相似度很低，被排到了 top-50 之外。系统只看了 top-3，就放弃了。

现在怎么防的：

• 永远开启 MMR（Maximal Marginal Relevance）：Chroma 和 FAISS 都支持。它能在“相关性”和“多样性”之间找平衡，避免所有 top-k 都来自同一份文档。我们开启 MMR 后，脚注类信息的召回率提升了 300%。
• 关键词检索兜底：对用户 query 中的精确术语（数字、ID、缩写），强制走关键词索引，哪怕只返回 1 个结果，也要确保它在。
• 设置“最低相关性阈值”：如果 top-1 的相似度分数 < 0.4（bge-m3 的 score 范围是 [-1,1]），就判定“未找到”，不喂给 LLM，避免它胡编。

4.4 坑四：LLM 的“自信幻觉”——它不知道自己不知道

当时怎么错的：
我们的 prompt 里写了“若无依据则回答‘未找到相关信息’”，但 LLM 依然会自信满满地编答案。用户问“E01 的维修周期”，它说“建议每 3 个月检修一次”，而文档里根本没提周期，只有“出现 E01 时立即停机”。模型把“立即停机”脑补成了“定期检修”。

现在怎么防的：

• Prompt 必须带“拒绝指令”：在 system prompt 里，把“未找到相关信息”写成唯一合法的 fallback 答案，并强调“禁止任何形式的推测、推断、补充”。
• 后处理校验：写一个简单的规则引擎，扫描 LLM 输出。如果答案里出现“建议”“通常”“可能”“一般”等模糊词，且未标注来源，就自动拦截，返回“未找到相关信息”。
• 用小模型做“事实核查”：在 LLM 输出后，用一个 0.5B 的 fine-tuned 模型，判断答案是否在检索结果中能找到直接依据。没有，就拒答。这个小模型 inference 只要 10ms，但把幻觉率从 25% 降到 3%。

4.5 坑五：元数据的“幽灵污染”——你以为的过滤，其实是误导

当时怎么错的：
为了加快检索，我们给所有 chunk 加了doc_type: "manual"元数据，并在检索时加了 filter。结果，一份新上传的《2024 年安全公告》也被误标为doc_type: "manual"，用户搜“最新安全公告”，系统因 filter 为doc_type: "manual"而完全忽略它，返回空。

现在怎么防的：

• 元数据必须人工审核或强校验：doc_type这种关键字段，不能靠自动识别。我们加了一道人工审核流程，或用规则校验（如文件名含 “