RAG 系统检索失败根本原因：数据分块策略而非模型能力

RAG 检索准确率：38%。修复后：87%。模型从未动过。

这是我交付的一次重构。系统是一个为欺诈分析师服务的 RAG 助手——问它"我们如何处理卡测试后跟随成功认证的情况？"，它应该根据团队自己的 SOP 和案例历史来回答。用户投诉：答案有误，所以模型肯定很差，因此采购部门应该买一个更大的模型。

模型没问题。它在完美地回答——基于垃圾上下文。跟我走完这条法医路线，因为每一步你都可以在本周自己的系统上验证。

证据A：分块破坏了意义，早于任何嵌入

摄入管道每隔 N 个字符就分割 SOP 文档，常常在句子中间断开。这意味着索引中一半的向量编码的是这样的碎片：

chunk_147 = "...ing to a freight forwarder. In these cases, do NOT"
chunk_148 = "cancel the order immediately. First verify the customer via"

政策——不要取消，先验证——不存在于任何单一分块中。嵌入无法对其输入中不存在的含义进行编码。检索被要求查找管道已经粉碎的语义。

修复一：按结构分块（章节、段落），永远不要按字符数，并保留足够的重叠以确保没有规则跨越边界。

证据B：仅密集检索，双模式查询

欺诈分析师的查询分为两个群体：模式问题（"高价值订单、新账户、紧急配送"）和标识符问题（"拒绝代码 4863 的 SOP 是什么？"、"规则 VEL-013 的理由"）。系统仅密集检索——嵌入将稀有令牌如 4863 视为噪音，所以标识符查询检索到的是感觉相似的分块，而不是字面匹配。无论模型质量如何，一半的查询群体结构性注定失败。

修复二：混合检索——用 BM25 处理标识符，用嵌入处理模式，用倒数排名融合来合并。

证据C：没人能看到这些，因为质量只是传言

没有黄金数据集。没有检索指标。系统的准确率就是最大声的逸闻说的那样。所以修复三实际上首先来临：在动管道之前构建评估，否则你在盲目调优。

# 使整个重构可测量的评估工具。
# 黄金集：真实分析师问题 + 实际回答这些问题的分块 ID。
golden = [
    {"q": "SOP for decline code 4863 repeated then success", "relevant": {"sop_12_3"}},
    {"q": "customer disputes delivered order with proof",     "relevant": {"sop_07_1", "case_1177"}},
    {"q": "rule VEL-013 rationale and exceptions",            "relevant": {"rule_vel_013"}},
    {"q": "new account high value order mismatched device",   "relevant": {"case_1203", "sop_04_2"}},
    # ... ~150 more, sampled from real analyst search logs
]

def recall_at_k(retrieve_fn, golden, k=5) -> float:
    hits = 0
    for item in golden:
        retrieved_ids = {doc_id for doc_id, _ in retrieve_fn(item["q"], k)}
        if retrieved_ids & item["relevant"]:
            hits += 1
    return hits / len(golden)

for name, fn in [("dense-only, bad chunks", retrieve_v1),
                 ("dense-only, clean chunks", retrieve_v2),
                 ("hybrid, clean chunks", retrieve_v3)]:
    print(f"{name:28s} recall@5 = {recall_at_k(fn, golden):.0%}")

dense-only, bad chunks       recall@5 = 38%
dense-only, clean chunks     recall@5 = 61%
hybrid, clean chunks         recall@5 = 87%

这个表就是全部故事。单纯分块就买了 23 个百分点。混合检索又买了 26 个。模型——那个每个人都想替换的东西——在里面根本没有出现，因为生成是检索的下游，模型只能和它的上下文一样正确。

注意黄金集的来源：真实分析师搜索日志，而不是编造的测试查询。编造的查询偏向模式风格（那是工程师想象搜索的方式），这正是标识符失败模式保持隐形的方式。你的评估集继承了写它的人的偏差——从生产中采样或测量虚构。

为什么欺诈团队应该比大多数人更关心

因为错误答案的利害关系是不对称且即时的。检索错误 SOP 的助手不会产生一个稍差的段落——它会产生一个分析师释放与已知骡子地址模式相匹配的订单，或持有合法的礼物购买并烧毁一个好客户。在这个领域，检索质量就是决策质量，隔一层。

原则：在你责怪模型之前，审计你给它的东西。RAG 质量是一个披着 AI 外衣的数据管道问题。

当你的 AI 给出错误答案时——你的团队是首先责怪模型，还是先检查检索？

我是 Vinicius Fagundes——圣保罗的首席数据工程师和 MBA 讲师。我通过 vf-insights.com 为电商构建欺诈和风险分析管道。