214 lines
6.9 KiB
Markdown
214 lines
6.9 KiB
Markdown
|
# 多知识库与数据拆解方法论（用于 Intent-Driven Script 系统）
|
|||
|
|
|
|||
|
|
## 1. 当前落地建议（先执行）
|
|||
|
|
|
|||
|
|
### 1.1 建议创建的知识库数量与定位
|
|||
|
|
建议先建 **4 个核心知识库 + 1 个兜底库（可选）**：
|
|||
|
|
|
|||
|
|
1. **KB_PRODUCT（product）课程产品库**
|
|||
|
|
- 放什么：课程模块、年级适配、学科能力点、学习路径、阶段价值
|
|||
|
|
- 不放什么：退款政策、隐私条款、运营口径说明
|
|||
|
|
|
|||
|
|
2. **KB_PARENT_COMM（script/general）家长沟通素材库**
|
|||
|
|
- 放什么：家长痛点表达、共情语料、自然过渡语、解释型话术素材
|
|||
|
|
- 不放什么：硬规则、流程跳转条件
|
|||
|
|
|
|||
|
|
3. **KB_FAQ（faq）高频问答库**
|
|||
|
|
- 放什么：价格、班型、课时、上课形式、效果周期等标准问答
|
|||
|
|
- 不放什么：长篇教育理念、复杂诊断内容
|
|||
|
|
|
|||
|
|
4. **KB_POLICY（policy）合规与边界库**
|
|||
|
|
- 放什么：承诺边界、敏感词、隐私说明、不可承诺清单
|
|||
|
|
- 不放什么：销售话术素材
|
|||
|
|
|
|||
|
|
5. **KB_GENERAL（general，可选）兜底知识库**
|
|||
|
|
- 放什么：跨场景通识内容、无法明确归属但需保留的信息
|
|||
|
|
- 不放什么：高频关键知识（应尽量归入前 4 库）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 1.2 标签（metadata）统一规范
|
|||
|
|
为保证多库检索稳定，所有文档建议统一至少包含以下 metadata：
|
|||
|
|
|
|||
|
|
- `grade`: `7|8|9|all`
|
|||
|
|
- `subject`: `chinese|math|english|physics|chemistry|all`
|
|||
|
|
- `scene`: `pain_point|transition|module_intro|faq|policy|closing`
|
|||
|
|
- `flow_step`: `step1|step2|step3|step4|step5|none`
|
|||
|
|
- `intent_type`: `ask_grade|ask_weak_point|module_recommend|next_action|faq_answer|compliance`
|
|||
|
|
- `audience`: `parent|student|all`
|
|||
|
|
- `priority`: `1-10`
|
|||
|
|
- `version`: 语义版本，如 `v1.0.0`
|
|||
|
|
- `status`: `draft|active|deprecated`
|
|||
|
|
- `source`: 数据来源（运营、教研、历史会话等）
|
|||
|
|
|
|||
|
|
建议附加字段：
|
|||
|
|
- `keywords`: 关键词数组
|
|||
|
|
- `effective_from` / `effective_to`: 生效周期
|
|||
|
|
- `owner`: 责任人或团队
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 1.3 检索路由（必须配置）
|
|||
|
|
采用“**意图命中 -> 指定库检索 -> metadata 过滤**”，避免全库盲检索。
|
|||
|
|
|
|||
|
|
示例：
|
|||
|
|
- 课程咨询/薄弱点诊断 -> `KB_PRODUCT + KB_PARENT_COMM`，过滤 `grade + subject + flow_step`
|
|||
|
|
- 价格/班型问答 -> `KB_FAQ`
|
|||
|
|
- 效果承诺/隐私/敏感问题 -> `KB_POLICY`
|
|||
|
|
- 无法命中 -> `KB_GENERAL` 兜底
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 数据拆解方法论（给另一个 AI 上下文使用）
|
|||
|
|
|
|||
|
|
## 2.1 方法目标
|
|||
|
|
把“原始业务文本/用户话术”稳定拆成以下四类输出：
|
|||
|
|
1. 录入哪个知识库（KB）
|
|||
|
|
2. 是否需要新增意图规则（Intent Rule）
|
|||
|
|
3. 是否进入现有话术流程步骤（Step1-5）
|
|||
|
|
4. 是否必须新建话术流程（New Flow）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2.2 四层判定框架（L1-L4）
|
|||
|
|
|
|||
|
|
### L1：内容性质判定（事实 vs 动作）
|
|||
|
|
- 若是“事实、说明、经验、解释” -> 优先 KB
|
|||
|
|
- 若是“出现这句话系统要动作” -> Intent Rule
|
|||
|
|
|
|||
|
|
### L2：交互形态判定（单轮 vs 多轮）
|
|||
|
|
- 单轮问答可完成 -> FAQ/Fixed/RAG
|
|||
|
|
- 需持续收集槽位并推进 -> Script Flow
|
|||
|
|
|
|||
|
|
### L3：流程复用判定（旧流程 vs 新流程）
|
|||
|
|
满足以下任一项，建议新建 Flow：
|
|||
|
|
- 业务目标变化（诊断变成转化/挽回/投诉）
|
|||
|
|
- 槽位集合变化（年级+薄弱点变成预算+时间）
|
|||
|
|
- 语气/合规策略显著不同
|
|||
|
|
|
|||
|
|
### L4：可执行性判定（是否能被系统消费）
|
|||
|
|
必须结构化到可执行字段：
|
|||
|
|
- 文档：title/content/metadata
|
|||
|
|
- 意图：keywords/patterns/response_type/priority
|
|||
|
|
- 流程步骤：intent/constraints/fallback/expected_variables
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2.3 标准拆解流程（7 步）
|
|||
|
|
|
|||
|
|
1. **提取实体与槽位**
|
|||
|
|
- 年级、学科、能力点、痛点、目标、约束
|
|||
|
|
2. **识别触发表达**
|
|||
|
|
- 用户会怎么说（口语化表达）
|
|||
|
|
3. **判断归属层级**
|
|||
|
|
- KB / Intent / Existing Flow / New Flow
|
|||
|
|
4. **拆分原子片段**
|
|||
|
|
- 每段只承载 1 个核心含义，便于检索
|
|||
|
|
5. **生成 metadata**
|
|||
|
|
- grade/subject/scene/flow_step/intent_type/priority
|
|||
|
|
6. **生成可落库对象**
|
|||
|
|
- API 对象：KB 文档、Intent 规则、Flow Step 配置
|
|||
|
|
7. **冲突检查**
|
|||
|
|
- 重复意图、优先级冲突、跨库污染、口径冲突
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2.4 输出模板（给另一个 AI 的固定格式）
|
|||
|
|
|
|||
|
|
让另一个 AI 严格按下列结构输出：
|
|||
|
|
|
|||
|
|
```markdown
|
|||
|
|
## A. 归类结论
|
|||
|
|
- 主归类：KB / Intent / Existing Flow / New Flow
|
|||
|
|
- 次归类：...
|
|||
|
|
- 是否需要新建流程：是/否
|
|||
|
|
|
|||
|
|
## B. 理由
|
|||
|
|
- 业务理由：...
|
|||
|
|
- 技术理由：...
|
|||
|
|
|
|||
|
|
## C. 落库建议
|
|||
|
|
### C1. Knowledge Base
|
|||
|
|
- kb_type: ...
|
|||
|
|
- title: ...
|
|||
|
|
- content_chunks: [...]
|
|||
|
|
- metadata: {...}
|
|||
|
|
|
|||
|
|
### C2. Intent Rules（如需要）
|
|||
|
|
- name: ...
|
|||
|
|
- keywords: [...]
|
|||
|
|
- patterns: [...]
|
|||
|
|
- response_type: fixed|rag|flow|transfer
|
|||
|
|
- priority: ...
|
|||
|
|
|
|||
|
|
### C3. Script Flow（如需要）
|
|||
|
|
- flow_id/name: ...
|
|||
|
|
- step_no: ...
|
|||
|
|
- script_mode: fixed|flexible|template
|
|||
|
|
- intent: ...
|
|||
|
|
- constraints: [...]
|
|||
|
|
- fallback: ...
|
|||
|
|
- expected_variables: [...]
|
|||
|
|
|
|||
|
|
## D. 风险与冲突
|
|||
|
|
- potential_conflicts: [...]
|
|||
|
|
- mitigation: [...]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2.5 质量门禁（Quality Gate）
|
|||
|
|
每条拆解结果上线前需通过：
|
|||
|
|
|
|||
|
|
1. **可路由**：意图命中后有明确 response_type
|
|||
|
|
2. **可检索**：metadata 完整（至少 6 个核心字段）
|
|||
|
|
3. **可执行**：Flow 步骤有 fallback
|
|||
|
|
4. **不冲突**：优先级与已有规则不打架
|
|||
|
|
5. **可维护**：owner、version、status 明确
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2.6 你当前 5 步流程的映射建议
|
|||
|
|
|
|||
|
|
- Step1（确认年级）
|
|||
|
|
- 主要依赖：`KB_PARENT_COMM`（礼貌提问素材）
|
|||
|
|
- Step2（年级特点+过渡）
|
|||
|
|
- 主要依赖：`KB_PRODUCT + KB_PARENT_COMM`
|
|||
|
|
- Step3（确认薄弱点）
|
|||
|
|
- 主要依赖：`KB_PARENT_COMM`（示例化引导）
|
|||
|
|
- Step4（模块介绍+综合价值）
|
|||
|
|
- 主要依赖：`KB_PRODUCT`
|
|||
|
|
- Step5（下一步建议）
|
|||
|
|
- 主要依赖：`KB_PARENT_COMM + KB_FAQ`
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 给另一个 AI 的指令模板（可直接复制）
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
你是“中台数据拆解器”。
|
|||
|
|
目标：将输入内容拆成可录入的 Knowledge Base / Intent Rules / Script Flow 配置。
|
|||
|
|
|
|||
|
|
请按以下步骤执行：
|
|||
|
|
1) 提取实体：年级、学科、能力点、痛点、目标、约束。
|
|||
|
|
2) 判断主归类（四选一）：KB / Intent / Existing Flow / New Flow。
|
|||
|
|
3) 若归类为 KB，输出：kb_type、title、chunk 切分、metadata。
|
|||
|
|
4) 若归类为 Intent，输出：keywords、patterns、response_type、priority。
|
|||
|
|
5) 若归类为 Existing Flow，输出：对应 step_no、script_mode、intent、constraints、fallback。
|
|||
|
|
6) 若需要 New Flow，说明触发条件、目标、槽位、成功标准。
|
|||
|
|
7) 输出风险与冲突检查。
|
|||
|
|
|
|||
|
|
输出必须使用固定结构：A归类结论、B理由、C落库建议、D风险与冲突。
|
|||
|
|
禁止输出泛泛建议，必须给出可直接调用 API 的字段。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. 迭代策略
|
|||
|
|
|
|||
|
|
- 第 1 周：先按 4 库上线，跑真实会话
|
|||
|
|
- 第 2 周：统计命中率、误召回率、fallback 率
|
|||
|
|
- 第 3 周：仅在“高干扰场景”再拆细分库（如按学科拆）
|
|||
|
|
- 每周：清理 `deprecated` 文档，升级 `version`
|
|||
|
|
|
|||
|
|
> 原则：先用 metadata 和路由提升质量，再考虑扩大知识库数量。
|