企业知识库上了 RAG为什么还是答非所问先别急着调模型问题多半出在数据治理这两年很多公司都在给大模型搭企业知识库方案基本都选 RAG用户提问时系统先去内部资料里检索相关内容连同问题一起交给模型让它照着资料作答。大模型的训练数据里没有你公司的制度、订单和项目记录私有知识只能靠这个办法补进去。制度、合同、会议纪要、客服录音一家企业跑上几年这类文件动辄几十万份。RAG 的技术方案不难抄向量数据库、检索框架、一体化平台开源组件一大把。难的是效果。上线之后很多团队看到的是同一批现象问报销流程它答的是三年前废止的旧版本问上季度销售额它报一个对不上的数还有不该给人看的文件被普普通通搜了出来。都是典型的答非所问。先别急着调模型这类问题多半不在模型在数据。为什么装了 RAG 还会这样先把知识点捋一遍你就知道每个环节是怎么被数据卡住的。大模型有三个短板。训练数据有截止日期之后的事一概不知。会幻觉不知道答案时不说不知道而是自信地编一个。最关键的是看不到私有数据。那把全部资料塞进上下文窗口行不行不行太贵、太慢上下文越长模型对中间内容的注意力越弱中型企业的数据量也塞不下。所以要用 RAG先检索后回答。像开卷考试闭卷全凭记忆记不清就现编开卷先翻到那一页照着书写准确率高得多。有个细节模型不是照抄资料而是读完之后用自己的话作答。所以资料质量直接决定答案质量检索做得好不好比提示词写得漂不漂亮重要得多。RAG 的流程分两段。数据入库时做一次解析、切块、向量化、存储。用户提问时走一遍理解问题、检索、生成答案。不同类型的数据入库和检索的做法不一样。数据形态典型来源检索路线非结构化文本PDF、Wiki、工单、会议纪要切块后向量检索混合检索加重排关系型数据库订单表、财务流水Text-to-SQL配安全防护半结构化数据商品库、用户画像字段过滤加向量检索实体关系网络人员、项目、系统依赖GraphRAG 建图查图图片音频视频架构图、客服录音先转文字再按文本处理制度文档这类文本入库前要先切块。切块不能把一句话拦腰切断。文档有标题层级的按章节切最省事效果也好没有结构的按固定长度切每块三四百字相邻两块留一点重叠。还有个进阶技巧叫父子块用小块做检索命中之后返回它所在的大块检索准上下文也完整。向量检索解决的是意思相近、字面不同的问题。用户问钱花超了怎么报销文档里写的是费用报销申请流程关键词搜不到向量能对上。反过来编号、型号、专有名词要靠关键词才搜得准。所以生产环境一般用混合检索两路结果合并排序最后再过一道重排先粗筛一两百条精排出最相关的几条。销售额这类数值问题不能用向量。向量检索算不出合计要让模型把问题翻译成 SQL 去查数据库查完再用自然语言作答。商品库这类数据两头都要。价格、品类是精确条件走过滤商品描述是模糊语义走向量。两条腿缺一不可。谁负责什么项目、依赖哪些系统这类问题答案散在几份文档里单独拿哪一段都答不全。GraphRAG 的办法是让模型读文档、抽实体、连关系存进图数据库查询时沿着关系走。它还擅长全局汇总类的问题比如技术债主要集中在哪些模块靠给每个社区生成摘要来回答。架构图和录音不是文字先转成文字再入库。图片用视觉模型生成描述录音用语音识别转写转写时保留时间戳答案才能溯源到第几分钟。实际系统里五类数据都有问题经常跨界。比如找出退货率超一成的商品再总结用户评论在抱怨什么前半句用 SQL后半句用向量。数据源一多就给模型一组检索工具让它自己决定先查哪个不够再换一个查这叫 Agentic RAG。代价是多几轮调用慢一点也贵一点。问题模式固定的阶段老实走固定管道就够。上线前先出考卷人工写 30 到 50 个真实问题和标准答案每次改动跑一遍看召回率、精确率、忠实度、相关性四个指标。感觉变好了不算数跑分才算。上线后每次答错先检查检索结果再动提示词十有八九是找错了资料。考卷还能反复用改一处跑一遍进步退步都有数。知识点就这些。把上面那张表倒过来读每条检索路线都对数据提了一项要求要求没满足就是答非所问。开头那三个问题答案全在这一半文章里。先说文本。解析错误会被切块固化进向量库之后每次检索都命中同一个错误。同一套制度有的部门模板带标题层级有的靠加粗排版有的是扫描件切块质量天生不一样。更常见的问题是旧版不下线三年前废止的制度还躺在库里写得比新版还全检索偏偏召回它。更微妙的是口径变更制度改了说法新旧两版并存召回哪版全看运气。向量库不挑食喂进来什么都记住记性越好闯的祸越大。所以文档入库前要清洗格式旧文件要及时下线新旧版本要能区分。业务术语也要对齐。用户不知道那叫费用报销申请流程他们只会问钱怎么要回来。财务一个叫法业务一个叫法文档各写各的向量检索照样会漏。同一个词两种含义更麻烦两边的文档都被捞出来选哪个全凭模型运气。业务术语表这种治理团队推了多年没人理的东西现在直接决定检索准确率。数据库要盯字段注释。Text-to-SQL 靠表结构、字段含义、示例值干活。quarter 字段注释里没写是自然季度还是财年模型只能猜猜错了 SQL 语法全对数是错的。以前报表错了还有人核对现在结果直接递到高管面前。字段注释这种没人愿意写的文档现在决定查询对不对。权限同样不能少。只读账号、表访问白名单、SQL 审计这些 BI 时代就有模型来了照样要用只是从报表层挪到了检索层。检索时也要带着权限去查人看不到的文档结果里就不该出现。超时和行数上限也要设防着一条慢查询拖垮业务库。不做这一层实习生也能把薪酬文件搜出来。商品库这类数据要盯元数据。价格和日期没有语义别把整份 JSON 向量化先分清哪些字段做过滤、哪些做向量。category 里登山鞋、登山鞋类、户外登山鞋三种写法并存过滤就会漏。枚举值规范这些活过去在主数据项目里干干完常被追问有什么用现在答案就写在检索准确率里。GraphRAG 要盯实体统一。建图靠模型从文档里抽实体文档怎么写它就怎么抽。同一个人在三份文档里叫老张、张三、张工图上就是三个孤岛推理到这就断了。主数据治理过去排不上预算现在是建图的前提。建图也不便宜每篇文档都要过一遍模型。文档不多的阶段可以先不建图查询时让模型现场从检索结果里抽关系能用但主数据的欠账一分没少。录音和图片要盯原始文件。转文字是有损压缩答案要能溯源到录音的第几分钟前提是原始文件在哪、哪个版本都查得到。原始文件丢了证据链就断了。为一段录音建一条血缘听着小题大做等审计来问某个回答的依据是什么就知道它值多少钱。还有两件事兜底。一是评测集那套考卷同时也是治理的度量衡数据整得好不好不用开会吵跑一遍便知。二是拒答出口检索不到相关内容就明确说资料库中未找到转人工处理别逼着模型硬编。转人工不是认输是把没把握的题交给有把握的人。私有知识和公开语料不一样公开语料答错了有常识和冗余兜着私有知识答错就是答错度量衡和拒答口子都得自己造。这张表正着读是技术选型倒着读是治理清单文档规范、术语对齐、版本管理、字段注释、权限接入、元数据标准、实体统一、原始资产、评测与拒答。九件事没有一件是新发明全是数据治理的基本功RAG 只是让它们头一回直接决定系统效果。所以下次再遇到答非所问先别动模型。把这张清单对着自家数据过一遍读不下去的那一行就是要先修的地方。你们的知识库上了 RAG 之后撞到的第一件答非所问是什么后来是调模型修好的还是治数据修好的评论区聊聊。