角色：知识工程师
负责把文档整理成可检索、可引用的条目，标注来源、时间与适用范围。这个角色要懂业务分类，而不是只会配置工具；条目切得是否合理，直接决定检索能否命中正确段落，也决定后续维护的难度与成本。
角色：检索与工程
负责索引、重排、去重与预算控制，保证每类内容不超限。工作量集中在调优与监控，需要能看到每次调用实际送进窗口的内容，否则出了问题只能猜是检索还是模型的原因，排障效率很低，也容易互相推责。
底稿要结构化
文档要有标题层级、字段与版本，扫描件要先做识别与校对。底稿质量差时，检索会把错字与断行一起带进上下文，模型据此生成的答案看似通顺却不可用，返工成本很高，团队还会误判模型能力不足。
权限与来源
不同岗位能看的知识范围不同，上下文组装时要按权限过滤，而不是先取回再隐藏。来源标注要与原文一致，便于复核；涉及客户数据的内容还需确认授权与留存期限，这部分由客户方合规确认，我方不代作判断。
最小配置
起步可以是一名知识工程师加一名工程接口人，业务方指定一人做判定。三人小组足以跑通一个场景；等场景数量增加，再补检索调优与运营，避免一开始铺太大摊子，最后没人维护，也没人负责收尾。
适用与不适用
适合谁
- 有文档中心或知识库、且有人牵头负责的企业
- 需要引用出处与版本的业务问答场景，错答代价高
- 能派出业务专家参与判定与抽检的团队
不适合谁
- 知识还只存在于个人电脑、也无责任人的团队
- 无法确认数据授权与留存期限的项目
典型场景
某保险公司的条款问答由三人小组维护：理赔专家把条款切成条目并标注生效时间，工程接口人负责索引、重排与预算，业务指定一人每周抽检答复。遇到条款更新，专家先改条目，工程再重跑评测，最后才替换线上上下文。
可执行步骤
- 指定知识工程师，按条款或问答对切分条目，并标注来源、时间与适用范围，形成规范
- 指定工程接口人，负责索引、重排、预算控制与调用日志，接口写进计划并留排期
- 业务方指定判定人，定期抽检答复的出处是否正确，记录判定结论，按月汇总
- 梳理权限范围，按岗位过滤可见条目，保存过滤记录以备审计与追责，避免越权可见。
常见坑
- 条目切得过碎，一句话一条，缺少上下文前提，模型拼不出完整条件，答复前后矛盾，用户反复追问，用户反复追问。
- 权限在取回之后才做过滤，敏感内容已进入上下文，一旦被引用就难以撤回，风险很高，审计也过不了。
- 工程看不到实际送进窗口的内容，调优只能凭猜测，问题定位靠运气，团队逐渐失去信心，项目停滞。
- 把判定交给技术团队，出处对不对无人核对，答复看着专业却与制度相悖，返工更贵，也伤信任，也难补救。
自检与验收清单
- 是否指定了知识工程师与明确的切分规则，并留文档
- 条目是否带来源、时间与适用范围三类标签，均可逐条核对。
- 是否在组装阶段按权限过滤，并留完整记录，并能复现。
- 是否能看到每次调用的实际上下文内容与长度
常见问题
需要专职知识工程师吗？
初期可以由业务骨干兼任，但要有固定工时投入。切分与标注是细活，兼职且没有排期时最容易拖延。等场景增加到三五个，再考虑专职或分组负责，否则条目质量会随人变动。
文档是扫描件怎么办？
先做识别与人工校对，再进入条目化流程。识别错误会直接进入上下文，模型无法自行纠正，还可能把错字当成术语。校对工作量不小，但比上线后反复解释与返工更省，也更容易通过验收。
权限做到什么程度？
按岗位与业务范围做最小可见，敏感条目单独标记。关键是过滤发生在组装阶段，而不是显示阶段；同时保留过滤日志，便于审计与追责，这部分需客户方安全与合规共同确认。