运营知识库如果只做成一个会聊天的机器人，很快会遇到两个问题：它回答得像，但证据不稳；它什么都想答，反而不清楚边界。对亚马逊运营来说，真正有价值的是受控知识检索加受控工具执行：只回答运营域问题，只引用可追溯资料，只调用白名单工具。
什么进 RAG，什么不进
规则、SOP、模板说明、字段字典、指标口径、异常处理手册和历史复盘适合进入知识库；每天变化的广告日报、库存快照、补货台账和 Listing 明细不应该整批塞进向量库。这些高频事实数据应该留在数据库或表格里，通过工具按需查询。
RAG 负责知道规则，工具负责读取事实。
先做文档治理，再谈模型效果
- 规则知识：Listing 政策、广告投放原则、关键词筛选规则、类目限制。
- 流程知识：补货、发货、异常处理、上新、申诉和复盘 SOP。
- 模板知识：Excel 模板、flat file 模板、检查表和文案模板。
- 数据语义：字段字典、指标口径、BI 说明、SQL 逻辑和报表差异。
- 案例知识：成功案例、失败案例、工单复盘和处理后的结果对照。
- 工具知识：脚本说明、API contract、错误码和运行边界。
元数据比 chunk size 更重要
运营知识不是一堆同质段落。规则文档要按标题和条款切，SOP 要按步骤切，案例要按背景、问题、动作、结果和复盘切，Excel 模板要先识别 sheet 和逻辑表，再生成摘要块。每个 chunk 至少要带 marketplace、business_domain、content_type、version、status、owner、effective_date 和 access_level。
doc_id: DOC-US-ADS-00042
version_id: v2026.07
status: approved
marketplace: US
business_domain: ads
content_type: rule
effective_date: 2026-07-01
access_level: internal
owner_team: amazon_opsCopilot 必须能判断是否需要工具
纯问答类问题只走检索和引用；Listing 生成、补货表生成、广告清洗这类任务则应该先检索规则作为约束，再调用工具生成结构化结果。更高风险的写操作，比如回写 Listing、调预算、创建入仓单，默认关闭，并且必须经过人审。
- `search_ops_knowledge`：按元数据过滤检索规则、SOP、模板和案例。
- `generate_listing_draft`：生成 Listing 候选稿、风险标记和证据引用。
- `build_replenishment_plan`：读取结构化库存与预测数据，生成补货建议表。
- `clean_ads_keywords`：调用关键词清洗流水线，输出候选词、否定词和复核原因。
- `export_review_file`：把结果写成可人工审核的 Excel 或 CSV。
回答格式本身也是治理的一部分
同一个问题如果每次只返回一段自然语言，很难判断系统有没有变好。我会固定四段回答契约：先给结论，再列引用依据，随后说明适用范围，最后标出仍需查询的动态事实或需要调用的工具。找不到已批准资料时明确拒答；资料版本冲突时列出冲突，而不是选一段更像答案的文本。
RAG 回答契约
结论：用一到三句回答。 依据：列出文档标题、版本与对应条款。 适用范围：说明 marketplace、业务域与生效日期。 下一步：若问题依赖实时库存、广告或 Listing 数据，说明需要调用的白名单工具；没有足够依据时明确拒答。
MVP 只做三件事
第一版只做运营规则问答、Listing 候选稿和补货表生成。它们分别验证三种能力：能不能带证据回答，能不能用规则约束生成内容，能不能调用结构化数据工具产出结果。范围收窄后，才能认真评估命中率、拒答边界和工具输出质量。
这类系统最重要的是可迁移
无论第一版用 Dify、RAGFlow、LlamaIndex 还是自研服务，文档注册表、元数据 schema、citation schema 和工具网关 contract 都要独立出来。这样后续换应用层或编排框架时，知识治理底座不用推倒重来。对作品集来说，这比展示一个漂亮问答框更能说明系统设计能力。