RAG 知识库来源和拆分逻辑应如何由产品目标定义？｜高频面试题解析

60 秒回答模板

从产品角度看，RAG 知识库来源和拆分逻辑不是先问 chunk 多大，而是先问产品要回答什么问题、服务谁、引用什么才可信。第一步定义目标场景和用户任务，比如政策问答、商家运营、客服知识或内部 SOP；第二步确定权威知识来源，包括官方文档、业务规则、FAQ、工单、案例库或结构化数据，并标注负责人、更新频率、权限和可信等级；第三步按用户问题粒度和答案边界确定拆分逻辑，例如一个业务规则、一个操作步骤、一个 FAQ、一个案例或一个政策条款，而不是机械按字数切。拆分后还要保留标题、层级、来源、时间、权限和关联关系。上线后用召回命中、引用正确、答案采纳、badcase 和人工反馈来调整来源和拆分策略。

考点 产品目标和用户任务决定 RAG 知识

难度 真实面经题

回答目标 定义产品侧 RAG 知识治理

深入解析

产品目标决定知识范围

RAG 知识库首先服务具体产品目标。不同场景需要不同来源：客服问答需要标准话术和问题库，政策解释需要官方规则，运营助手需要业务 SOP 和案例，数据问答可能需要指标口径。没有目标，知识库会越堆越乱。

来源要看权威性和责任人

产品经理需要定义哪些来源可信、谁负责维护、多久更新、是否有生效期和是否可对用户展示。权威来源应优先于论坛、聊天记录和未经审核材料。每类来源都要有负责人，否则知识过期后没人治理。

权限和新鲜度是产品规则

知识来源不只是内容集合，还包含可见范围、用户身份、地区、业务线和版本。RAG 结果如果越权或使用过期规则，会直接伤害信任。因此权限标签、生效时间、失效时间和更新 SLA 都应成为知识库设计的一部分。

拆分逻辑按用户任务粒度

产品侧拆分应围绕用户问题和答案边界，比如一个规则条款、一个办理步骤、一个 FAQ 问答、一个案例结论或一个指标定义。机械按固定字数切分可能把前提、例外和结论拆散，导致召回后无法回答完整问题。

保留上下文和关联关系

拆分后仍要保留文档标题、章节层级、来源链接、更新时间、适用范围、前后条款和相关规则。这样召回单个片段时，系统仍能知道它属于哪个业务规则，是否有例外条件，以及能否作为答案引用。

用 badcase 反推治理策略

上线后要看用户问题是否召回正确来源、答案是否引用对、哪些问题空召回、哪些来源冲突、哪些知识过期。badcase 可以反推是来源缺失、权限不对、拆分过细、拆分过粗、标题不清还是评估集不足。

易错点

把题目写成工程侧 PDF chunking 和 embedding 参数调优。
不先定义产品目标和用户任务，直接罗列知识来源。
收录大量未经审核内容，缺少权威等级和负责人。
忽略权限、地区、业务线、生效期和过期问题。
机械按字数切分，破坏业务规则的完整语义。
没有用 badcase 和评测集持续调整来源与拆分逻辑。

面试官追问

产品经理如何判断一个知识来源是否足够权威？

看来源是否由业务负责人维护、是否有明确生效范围和更新时间、是否能对外引用、是否覆盖目标用户问题，以及是否有冲突处理规则。高风险内容要优先官方或专家来源。

RAG 知识库来源冲突时，应该如何定义优先级？

先定义来源优先级，例如官方规则高于 FAQ，最新版本高于旧版本，业务 owner 确认高于历史工单。冲突样本要进入人工处理和知识治理，而不是让模型自行选择。

为什么不能只按固定字数做知识拆分？

固定字数可能切断前提、例外、步骤和结论，导致召回片段无法独立回答问题。产品侧应按用户问题粒度和业务语义边界拆分，再由工程控制长度和索引策略。

权限标签缺失会给 RAG 产品带来什么风险？

会导致用户看到无权知识、跨业务线信息泄露、内部 SOP 外泄或错误适用规则。RAG 权限错误比普通搜索更隐蔽，因为答案可能混合多个来源。

如何用 badcase 判断是来源问题还是拆分问题？

如果正确来源没有被召回，可能是来源缺失或拆分/索引问题；如果召回片段不完整，偏拆分问题；如果召回了过期或冲突内容，偏来源治理和版本问题。

知识库负责人和更新 SLA 应该如何设计？

每类知识都要有 owner、更新频率、审核流程、过期策略和质量指标。高频或高风险知识需要更短 SLA，低频归档知识可以低频维护但要标注时效。