【摘要】RAG 答得不稳，问题有时从资料入库前就埋下了。切片太粗，系统会召回一大块含混资料；切片太碎，条件、例外和适用范围又容易断开。产品经理不用盯技术参数，但要能追问资料按什么逻辑被切开，是否还能支撑完整回答。
一个企业做内部制度问答，系统已经接入了报销制度、差旅制度和培训管理办法。业务方测试时问：“去外地参加培训，住宿按什么标准报销？”
系统很快回答：按差旅住宿标准执行，并引用了差旅制度中的住宿标准表。看起来有资料、有引用、有解释，技术同学也觉得检索链路跑通了。
财务同事却指出，答案不完整。因为培训住宿还有一条额外规则：如果是公司统一组织的培训，住宿安排和报销口径要看培训管理办法里的例外说明。系统引用的那一段没错，但漏掉了真正决定答案的适用范围。
继续往前查，才发现问题并没有发生在最终生成阶段。制度入库时，差旅标准表被切成了一块，培训适用范围被切到了另一块，例外说明又被拆到后面。用户问的是一个完整业务场景，系统拿到的却只是几个断开的资料片段。
这就是很多 RAG 答得不稳时容易被忽略的一层：资料已经接进来了，也能被检索到，可资料在进入知识库时被切得太粗、太碎或关系断开，后面的召回、组织和生成都会跟着不稳。
01｜答不稳，先看资料怎么切
很多团队看到 RAG 答错，第一反应会去看模型、提示词、召回率、重排效果。这个方向没有错，但如果资料切片阶段已经把规则切断，后面调很多参数，也可能只是在碎片上继续加工。
用户问的是一个完整问题，系统检索到的是一个个资料块。资料块怎么切，决定了系统能不能找到合适证据，也决定了模型拿到证据后能不能组织出完整答案。人读制度时，可以前后翻几页，把定义、条件、例外、适用范围连起来看；RAG 系统通常先拿到若干片段，再尝试把这些片段组织成回答。
问题就在这里。切片如果没有贴着业务语义走，系统可能只拿到“看起来相关”的片段。比如只拿到标准，没有拿到例外；只拿到定义，没有拿到适用范围；只拿到结论，没有拿到前置条件。答案表面上有依据，业务上仍然会偏。
产品经理在这里要做一个取舍：看到答得不稳时，先别急着把问题都归到模型能力或检索参数上，要回头看一眼资料进入知识库时的切法。资料是按页切、按标题切、按段落切，还是按业务规则切？一条完整规则有没有被拆开？一个资料块里是不是混了太多主题？这些问题会直接影响后面的回答质量。
02｜切得太粗，召回会变钝
切片太粗时，最常见的问题是系统“找到了资料”，但找得不够准。一个资料块里可能同时塞进定义、流程、标准、例外、注意事项，甚至混着多个业务主题。检索命中了这一大块资料，系统看起来没有漏召回，可真正相关的内容被埋在一堆弱相关信息里。
比如一份差旅制度里，同一页同时写着交通标准、住宿标准、餐补标准和审批流程。用户只问住宿标准，系统召回了整页内容。模型拿到这一块后，可能会把交通审批、住宿金额、餐补规则混在一起解释。回答看起来很完整，实际重点已经散了。
切得太粗还会让相似问题互相干扰。用户问“外地培训住宿怎么算”，系统召回了一大块差旅制度；用户问“客户拜访住宿怎么算”，系统也召回同一块。两个场景都出现“住宿标准”，但适用条件不同。如果资料块过大，系统很难从这一大块里分清用户到底问的是哪一种业务场景。
产品经理不需要判断具体切片长度该是多少，但要能判断资料块是否承载了过多主题。一个简单标准是：如果一个资料块被召回后，里面只有一小段和用户问题有关，其余内容都在制造干扰，这个切片大概率太粗。召回有结果，只说明系统找到了文字；召回是否有用，还要看这块资料能不能精准支撑当前问题。
03｜切得太碎，答案会断线
切片太碎时，问题会换一种形式出现：系统找到的每个片段单独看都对，但放在一起支撑不了完整答案。制度、FAQ、产品手册里的很多规则，本来就需要前后几段一起理解。切得太碎之后，条件、例外、适用范围、操作步骤被拆开，系统只拿到其中一小块，就容易答得片面。
比如一条报销规则分成三段：第一段写适用对象，第二段写报销标准，第三段写例外情况。用户问“实习生外出培训能不能报销住宿”，系统只召回了第二段标准，就可能直接回答“可以按标准报销”。可真正决定答案的是第一段的适用对象和第三段的例外条件。
这类错误特别隐蔽，因为被引用的片段本身可能没有错。问题出在片段太孤立，无法支撑完整判断。业务方看到答案时，会觉得“这句话好像来自制度，但怎么少了关键条件”；技术同学看到检索结果时，会觉得“相关内容已经召回了”。双方都没完全错，真正的问题是资料块之间的语义关系断了。
产品经理可以这样追问：这条规则是否需要前后文才能成立？用户问的场景是否需要同时看到定义、条件、例外和适用范围？如果一个片段单独拿出来会改变原意，就不能只看它有没有被召回，还要看系统能不能同时拿到支撑完整回答的相邻资料。
04｜资料块不稳，组织也会乱
RAG 回答并不只取决于“有没有找到资料”。找到资料之后，系统还要把多个资料块组织成一段答案。切片不合理时，组织阶段也会变得很难：资料块之间关系不清、顺序不明、主次不稳，模型就容易把几个片段拼成一个看似顺畅但逻辑不完整的回答。
比如用户问“试用期员工出差报销怎么走流程”。系统可能召回三块资料：一块是出差报销流程，一块是试用期员工管理规定，一块是费用审批权限表。三块资料都相关，但它们之间谁决定适用范围、谁决定流程、谁决定审批权限，需要有清楚关系。切片如果没有保留标题层级、上下位关系和适用范围，模型就只能凭片段内容去拼。
这时答案容易出现两种问题。第一种是拼漏了：系统只回答流程，漏掉试用期员工的特殊限制。第二种是拼混了：系统把不同制度里的条件揉成一段折中表达，让答案看起来很稳，实际业务口径并不成立。
后面还会继续讲召回、重排、生成这些环节该怎么看，本篇先把上游问题收住：如果资料块本身切得不稳，后面的排序和生成都会被迫在不完整证据上工作。产品经理要能把问题往前推一层，不只看最终答案顺不顺，也要看答案背后的资料块是否能组成一条完整证据链。
05｜产品经理要追问切法
产品经理不需要替技术同学设计切片算法，但要能提出能推进排查的问题。看到 RAG 答得不稳，可以先拿几条典型错误样例，反查系统当时召回了哪些资料块，再看这些资料块是否真的足够支撑答案。
第一，要问资料是按什么逻辑切开的。按页切、按固定长度切、按标题切、按段落切，得到的效果会不同。对于制度、FAQ、产品手册这类资料，只按长度切开，往往会把业务规则拆断；只按页面切开，又可能把太多主题塞在一块。
第二，要看一条完整规则有没有被拆散。凡是涉及“适用对象、适用条件、例外情况、处理流程、责任部门”的内容，都要警惕切片把前后关系拆开。单个片段看起来相关，不能直接说明它足够支撑回答。
第三，要用真实问题回放切片效果。产品经理可以拿高频问题、边界问题和容易误答的问题，让团队回看召回结果：该召回的资料块有没有出现？不该出现的资料块为什么也被找到了？被召回的资料块合在一起，是否能支持一个完整答案？
这几个问题问完，本篇的判断就可以收住：RAG 答得不稳，不一定要从模型开始改，也不一定一上来就调重排。很多时候，资料在进入知识库时已经埋下了不稳的种子。先看资料怎么切，才能判断后面是该补资料、改切片、调召回，还是进入更完整的链路排查；下一篇，我们继续看：用户随口一问，RAG 为什么就找不到资料？
#RAG #RAG设计 #AI产品经理 #知识库 #资料切片 #检索召回 #资料治理 #产品经理 #AI产品经理培训 #企业知识库
热门跟贴