一步步设计
先检查分类树是否适合任务
虚构目录是开发→API/数据→首次请求/抽取。每个节点有稳定 ID、定义和例外；同层的分类需要清晰区分。若一篇教程确实属于多个主题，应采用多标签或主类加关联标签，而不是强迫一棵树承载所有关系。
在当前节点选直接子类
把原文与当前路径放进 state，Choice 只在直接子类和不确定结果间选择。保留整个选项分布。中文标题可能是日文 API 教程，语言不能替代主题；路径上一层的预测也应标记为预测，不能改写原文事实。
理解贪心错误为什么会锁死
一次只保留最高概率子类叫贪心。根节点开发0.52、数据0.48，是虚构示例；选开发后就不再看数据，后续无法找到数据→抽取。它节省探索预算，但首层微弱优势会放大为不可恢复的路径选择。
必要时保留少量备选路径
官方配方展示 beam search：保留 K 条候选路径并继续比较。本例从 K=2 的预算草案开始，测试是否值得额外问题。路径比较可使用明确的长度规范化规则，但路径分不能叫全局正确概率；不同深度和分类树变更要重新验证。
细类不够明确就停在可靠层级
可以输出可靠的大类和待复核状态，不必总到叶子。记录每次节点判断、模型与分类树版本，统计错误最常发生的节点。树更新后先回放固定测试，检查旧 ID 的迁移；未知或越界内容不能硬塞到相似叶子。
完整走查 · 本站虚构样本
| 观察到什么 | 如何判断 | 代码怎么处理 |
|---|---|---|
| 根节点0.52/0.48；后续抽取证据更强 | 首层优势不稳 | 可保留两条路径再比较 |
| 大类明确，子类接近 | 只确认到父类 | 输出父类并复核细类 |
| 原文涵盖两个主题 | 树的单标签假设不适用 | 主类与关联标签分开 |
可复制的设计草案
以下为本站原创示例。JSON 展示请求或输入形状；Python 仅计算虚构分数，不调用 API。真实接入仍需核对官方接口及任务策略。
# Invented taxonomy input; no model calls.
{
"taxonomy_version": "tutorial-v1",
"node_id": "development",
"children": {"api": "API integration", "data": "Data processing"},
"fallback": "development:needs_review",
"exploration_budget": {"max_paths": 2, "max_depth": 3}
}容易踩的坑
- 把局部最大值当全路径最优。
- 将路径评分宣称为校准概率。
- 更新分类树却不记录版本。
TRY / THINK / COMPARE
先想一想，再看解析
大类很明确，但两个叶子几乎打平，必须强选一个吗？
展开解析
不必。可保留父类和细分待确认；需要叶子时再补上下文或复核，并量化这种回退的比例。
交付前检查
- 每个节点有稳定 ID 与定义。
- 保留节点分布与路径历史。
- 探索预算、父类回退和未知输入已设计。
- 分类树变更经过固定样本回放。
常见问题
beam search 一定更好吗？
未必。它增加探索，收益和费用需要同数据对照。
能直接相乘当最终 confidence 吗？
不能直接这样命名；路径启发式与 API 的 confidence 不同。
资料与延伸阅读
参考官方架构模式与 Datawhale 实战主题，本站独立编写讲解、案例与练习。示例为教学设计，未调用 API，不代表性能测试。