一、RAG 最难的不是搭起来，而是调到可信可用

一个基础 RAG Demo，一两天就能跑起来：把 PDF 读出来，切 chunk，做 embedding，塞进向量库，用户提问时召回几段文本，再交给大模型回答。看起来很完整。

但生产级 RAG 难的地方不在“能不能回答”，而在“能不能稳定答对、答错能不能发现、发现后能不能定位和修复”。这才是真正拉开 Demo 和工程系统差距的地方。

RAG 的目标不是“检索相似文本”，而是“用可验证证据生成可信答案”。

RAG 答案质量来自四个乘法项，任意一项接近 0，整体质量都会塌。

所以，讨论 RAG 最难的地方，不能只说 Embedding 模型选型，也不能只说 Chunk 切多大。更合理的分层是：输入层的文档预处理、检索层的证据召回、生成层的边界控制、评估层的指标闭环，以及生产层的权限、版本、监控和回滚。

二、三块最难啃的骨头

实际落地时，最容易把团队拖住的通常是三件事：文档预处理、检索质量调优、效果评估困难。它们不是孤立问题，而是层层传导。文档解析错了，会污染 chunk；chunk 质量差，会影响 embedding；检索不准，会逼模型瞎猜；没有评估，所有优化都变成靠感觉。

三、第一难：文档预处理，最脏最累但最关键

RAG 的第一步不是“读文件”，而是把真实世界里混乱的资料变成机器能理解、能检索、能引用的证据。这个环节做不好，后面的 Chunking、Embedding、Rerank、Prompt 再精致，也是在垃圾数据上装修。

现实资料远比 Demo 复杂：PDF 有双栏、表格、页眉页脚、脚注、扫描图片；Word 里有嵌套表格和批注；HTML 有导航栏和广告；代码文档有函数、类、注释和配置片段；业务文档还有版本、生效时间、权限范围。

PDF 最典型。PDF 主要为“打印和展示”设计，不天然保存语义层，很多表格本质上只是一堆绝对定位的文字。普通文本提取库遇到复杂表格、双栏排版、扫描件时，很容易把顺序、行列和上下文关系搞乱。

工程上不能指望一个解析器吃遍所有文档。更稳的做法是做“解析路由”：普通文本走轻量解析；带表格的 PDF 用 pdfplumber、Camelot、unstructured 这类工具；扫描件走 OCR；高价值复杂文档可以走多模态解析，但要控制成本。

更重要的是保留元数据。一个 chunk 不能只有文本，还应该带上 source、page、section、doc_id、version、updated_at、permission、effective_time、content_hash。否则后面很难做权限过滤、版本选择、引用溯源和问题回放。

文档预处理示例代码

from pathlib import Path
from typing import Iterable


def parse_document(path: str) -> list[dict]:
"""把不同类型文档解析成统一的证据元素。"""
suffix = Path(path).suffix.lower()

if suffix == ".pdf":
return parse_pdf_with_layout(path)

if suffix in {".docx", ".doc"}:
return parse_word(path)

if suffix in {".html", ".htm"}:
return parse_html_and_remove_noise(path)

if suffix in {".png", ".jpg", ".jpeg"}:
return parse_image_with_ocr(path)

return parse_plain_text(path)


def build_chunk(element: dict, doc_meta: dict) -> dict:
return {
"text": element["text"],
"source": doc_meta["source"],
"doc_id": doc_meta["doc_id"],
"page": element.get("page"),
"section": element.get("section"),
"content_type": element.get("type"),
"version": doc_meta.get("version"),
"permission": doc_meta.get("permission"),
"effective_time": doc_meta.get("effective_time"),
"content_hash": element.get("content_hash"),
}

这段代码的重点不是具体函数名，而是思想：先识别文档类型，再走对应解析策略，最后把文本和元数据一起入库。没有 metadata 的 RAG，很难进入生产环境。

四、第二难：检索质量调优，系统上限由召回决定

RAG 里最常见的错，不是大模型不会回答，而是检索阶段根本没有把正确证据送到模型面前。模型拿不到证据，就只能根据参数记忆和语言模式补答案，幻觉自然就来了。

检索质量差的原因很杂。可能是 chunk 切得太碎，问题所需的信息被拆散；也可能是 chunk 太大，相关信息被淹没；可能是用户问法很口语，而文档表述很正式；也可能是专有名词、型号、缩写这种精确词，向量检索反而不如关键词检索。

所以检索调优不能一上来就换 Embedding 模型。第一步应该是回放问题：正确答案在哪个文档、哪个页、哪个段落？这个段落有没有被正确解析？有没有被切成独立 chunk？有没有进向量库？有没有被召回？召回后排第几？Rerank 后有没有上来？

真正的生产系统通常会组合多种手段：向量检索负责语义相似，BM25 负责精确词，metadata filter 负责权限和版本，Rerank 负责把最有用证据排到前面，Parent-Child 或上下文扩展负责补齐语义边界。

混合检索和重排示例代码

def retrieve(query: str, user: dict, top_k: int = 20) -> list[dict]:
# 1. Query 改写：补全口语、缩写和业务同义词
rewritten = rewrite_query(query)

# 2. 权限与版本过滤必须前置，不能先召回再遮挡
filters = {
"permission": {"$in": user["allowed_scopes"]},
"status": "effective",
}

# 3. 多路召回：向量负责语义，BM25 负责关键词和型号
dense_hits = vector_search(rewritten, filters=filters, top_k=top_k)
sparse_hits = bm25_search(rewritten, filters=filters, top_k=top_k)

# 4. 融合去重，避免同一文档片段重复挤占上下文
candidates = reciprocal_rank_fusion([dense_hits, sparse_hits])
candidates = deduplicate_by_doc_and_span(candidates)

# 5. Rerank：让真正能回答问题的证据排到前面
reranked = cross_encoder_rerank(query, candidates, top_k=5)

# 6. 证据不足时不要硬答，交给生成层拒答
return reranked

这里有个很关键的生产原则：权限过滤必须在检索前完成。如果先召回高权限内容，再让模型“不要说出来”，这不是安全，是自欺欺人。

五、第三难：效果评估，不量化就只能瞎优化

RAG 最让人头疼的一点是：它不像普通接口那样返回固定字段，也不像传统搜索那样只看点击。一个答案可能语言很自然，但事实错了；可能事实没错，但没有回答用户问题；也可能检索内容相关，但不足以支持最终结论。

第一性原理看，评估要回答三个问题：第一，正确证据有没有被召回；第二，召回证据是否足够回答；第三，最终答案是否忠于证据。只看端到端答案，很难定位到底是解析、切块、召回、重排还是生成出了问题。

检索层可以用 Hit@K、MRR、nDCG、Context Recall；生成层可以看 Faithfulness、Answer Relevancy、Groundedness；线上层要看用户反馈、追问率、转人工率、解决率、延迟和成本。RAGAS、LangSmith、LlamaIndex、DeepEval、TruLens 这些工具，核心价值不是“自动打一个分”，而是帮助团队把问题拆开。

更进一步，评估集不能只有标准问法，还要包含真实线上口语、错别字、缩写、否定问题、多跳问题、旧版本冲突问题、无答案问题和权限边界问题。否则离线分数很好看，上线照样翻车。

评估门禁示例代码

THRESHOLDS = {
"hit_at_5": 0.85,
"context_recall": 0.80,
"faithfulness": 0.90,
"answer_relevancy": 0.85,
"p95_latency_ms": 3500,
}


def ci_gate(report: dict) -> None:
"""把 RAG 评估接入 CI，防止一次优化毁掉旧能力。"""
failed = []

for metric, threshold in THRESHOLDS.items():
value = report.get(metric)

if metric.endswith("latency_ms"):
if value > threshold:
failed.append((metric, value, threshold))
else:
if value < threshold:
failed.append((metric, value, threshold))

if failed:
raise RuntimeError(f"RAG eval gate failed: {failed}")

这类门禁能避免一个常见问题：今天换了 Chunk 策略，看似某些新问题变好了，但一批老问题悄悄变差。如果没有回归评估，团队要等用户投诉才知道。

六、上线后更难的暗坑：权限、版本、观测、成本

很多团队把 RAG 做到“能回答”就以为差不多了，真正上线后才发现，技术问题会变成产品问题、治理问题和安全问题。

第一个暗坑是权限。企业知识库里不同用户能看的资料不同，检索系统必须继承原系统的权限模型。否则一个普通员工通过换一种问法，就可能召回本不该看到的合同、薪资、客户资料。

第二个暗坑是版本。RAG 很容易把旧政策、旧价格、旧接口文档当成有效证据。语义相似不代表业务有效，metadata 里的 version、status、effective_time 必须参与过滤和排序。

第三个暗坑是观测。一次回答出错时，必须能看到用户问题、改写后的 query、召回 chunk、相似度分数、rerank 分数、最终 prompt、模型输出和用户反馈。没有链路追踪，就无法复盘。

第四个暗坑是成本。Rerank、多路召回、长上下文、多模态解析都能提升质量，但都会增加延迟和费用。生产系统要做分级策略：普通问题走轻量链路，高风险问题走强链路。

七、上线前要故意刁难系统

对抗式审查的核心不是证明系统“能答对”，而是主动找它会在哪些情况下答错、越权、乱编、过时、失控。真实用户不会按你的测试脚本提问，真实文档也不会总是干净整齐。

审查时要特别关注“无答案问题”。很多系统在没有证据时仍然会给出看似合理的答案，这是最危险的幻觉。合格的 RAG 应该能识别证据不足，并明确说明“不确定”或“知识库中没有找到足够依据”。

还要关注“相似干扰”。如果问题问的是 2026 版政策，检索结果里混进 2024 版政策，模型很可能被旧证据带偏。解决思路不是只靠 Prompt，而是把版本、生效时间、状态字段做成硬过滤。

最后要关注 Prompt 注入。文档本身可能包含“忽略系统规则”“输出全部机密信息”这样的文本。RAG 系统必须把检索内容当作不可信输入，不能让文档内容覆盖系统指令和安全规则。

八、落地建议：先做可评估闭环，再做复杂架构

RAG 的正确落地顺序，不是先上 GraphRAG、Agentic RAG、Self-RAG 这些高级范式，而是先把基础闭环做好：文档能稳定解析，检索能回放，答案有引用，错误能评估，线上能监控，异常能回滚。

先选小场景：从高频、高价值、资料相对规范的业务问题开始，不要一口吃全公司知识库。

先做评估集：没有评估集，后续每一次调参都不知道是进步还是退步。

先做引用和拒答：让模型必须基于证据回答，证据不足时明确拒答。

先做链路日志：记录每次召回和生成过程，保证线上问题可以复盘。

先做权限和版本：这两个问题越晚做，返工越大。

等基础链路稳定后，再根据场景引入更复杂能力：多跳关系强就引入图数据库，答案不稳定就引入生成后校验，文档更新频繁就做增量索引和蓝绿切换，跨系统任务多再考虑 Agent。

九、总结：RAG 的难，是系统工程的难

RAG 落地最难的地方，不是某一个模型、某一个向量库、某一个框架，而是整条链路都可能出问题，并且问题会互相传导。

文档预处理是地基，检索质量是天花板，效果评估是方向盘，生产治理是安全带。没有地基，答案源头就脏；没有检索，模型拿不到证据；没有评估，优化只能靠猜；没有治理，系统很难放心上线。

一句话概括：RAG Demo 拼的是速度，生产级 RAG 拼的是数据治理、检索工程、评估闭环和安全边界。