企业知识库为什么必须做 RAG，而不是直接问大模型

很多企业在做知识库时都会问同一个问题：直接把文档丢给大模型不行吗？

答案是：短期可以，长期不行。本文解释为什么 RAG（检索增强生成）不是可选项，而是必选项。

三个绕不过去的硬约束

1. 上下文窗口装不下

一份中型企业的制度、产品手册、历史工单加起来常常是几十万到几百万字。即使上下文窗口足够大，把全部内容塞进 prompt 的成本与延迟也不可接受。

2. 知识需要实时更新

模型权重是静态的。今天改了报销标准，明天就想让员工问到新答案——只有检索层是热更新的，这一点微调做不到，提示词也做不到。

3. 答案必须可溯源

企业场景里"答错了但说不出依据"是最严重的失败。RAG 天生带引用：检索到哪几段，答案就来自哪几段，可以逐条点开原文核对。

RAG 的最小可用架构

文档 → 解析 → 切片 → 向量化 → 向量库
                                  ↓
用户提问 → 向量检索 → 重排序 → 拼装上下文 → LLM 生成 → 带引用的答案

关键在于切片与重排序，而不是换更大的模型。我们的实测结论：

一个常被忽略的细节：切片不是等长切

按固定字数切是最省事、也最伤效果的方案。更好的做法是按语义边界切——标题层级、段落完整性、表格不跨片。

def split_by_semantic(doc, max_tokens=512):
    """按标题层级优先切分，超长段落再按句号降级"""
    blocks = doc.split_by_heading()
    chunks = []
    for b in blocks:
        if b.token_count <= max_tokens:
            chunks.append(b)
        else:
            chunks.extend(b.split_by_sentence(max_tokens))
    return chunks

小结

• 上下文窗口不是检索的替代品
• 热更新能力只能由检索层提供
• 可溯源是企业级应用的底线

RAG 的价值不在"让模型更聪明"，而在让答案可控。