把 LLM 调用拆成 41 个子任务：AI 应用需要更精细的原语

AI 应用的下一阶段突破，可能不在更大的模型，而在更精细的任务原语。一篇发表于 Hacker News 的技术长文提出，应把当下「调用大模型生成文本」的范式拆解为分类、抽取、归一化、检索等具体操作，并建立一套由 41 个子任务、7 大族系组成的任务体系，让前沿大模型只兜底真正新颖的请求，其余结构化工作由专用程序完成。

为什么需要重新审视「一次 generate() 调用」

作者认为，生产环境中的 LLM 调用本质上是潜在的「程序」。分类、抽取、链接、排序、归一化和算术等子任务各有自己的输出形态与失败模式。把它们都塞进同一段提示词下，前沿模型就会被迫处理结构化任务中本可由更小、更可控的程序完成的「常规工作」，既浪费算力，也丢失可观测性。

以年报中抽取客户—供应商关系为例，看似是通用推理，实质是一套经典的抽取流水线：命名实体识别、实体归一化、候选生成、实体链接、关系抽取、模式校验。在这套链路上，前沿模型只应承担分布外（OOD）的新颖案例，其余环节交给专门的操作符。客服工单分诊也呈现相同结构——语言识别、意图、情感属于分类，优先级是有序分数，账户解析是实体链接，整张记录是一次 schema 校验，优先级必须排在意图与情感之后，否则就会丢失依赖关系。

一个可工作的任务分类法

文章提出把 LLM 调用拆成 7 个族系、41 个子任务，并给出每族最常见的实现方式：

• A 文本分类：小分类器，覆盖二分类、多分类、多标签、序数、层次分类、语言识别、情感、意图等 8 个子类。
• B 序列/片段标注：确定性规则或序列模型，覆盖 NER、槽位、词性分块、片段抽取、关键词。
• C 结构化抽取：结构化抽取器，涵盖键值、关系、事件、表格、属性、schema JSON。
• D 实体匹配/检索：查找索引，覆盖文档检索、抽取式问答、重排、实体链接、记录关联、去重、模糊匹配。
• E 相似度/配对：embedding 相似度，含语义相似、paraphrase、聚类、关键词。
• F 归一化/转换：确定性规则，处理日期货币、地址姓名、格式转换、分段、清洗、枚举映射、分词。
• G 数值/分析：公式引擎，覆盖算术、聚合、日期运算、确定性指标。

作者强调，这些只是「常见实现」，并非定律；不同团队、不同业务可保留自己的私有任务分类，分类粒度应服从业务需求。

决策是这套词汇的起点

文章指出，决策是任务词汇的起点而非终点。PII 检测要的是布尔之上的概率，部门路由要的是固定集合中的选择，严重度要的是有序分数——把模型当作文本生成器，就会丢掉应用本已掌握的结构。概率要变成动作，必须依赖一个阈值，而阈值的设定应来自「错判的成本」。

更进一步，检索可被视作在文档集合中做选择，片段抽取是在子串集合中做选择，实体解析是在配对上做「是否同一实体」的判断。但这些归约都依赖于一个有限的候选集——这一步骤的结构性工作，恰被归约本身抹掉了。没有候选集，对语料库的 softmax 跑不起来；逐对实体解析是平方复杂度；对每个子串做分类也是平方复杂度；只有序列标注保持线性。

TypeSafe Jev 与「编程即示例」

文章点名 TypeSafe 推出的 Jev，作为把上述思路落到产品形态的代表：它把分类、有序分数、是否概率这类「机器友好的接口」还给了上层应用，让运行时不必再把原本的一次生成当作不可拆分的整体。

作者把这种范式总结为「以示例为编程」（programming by example）：当累积了足够多的调用轨迹——输入、输出、纠正与失败案例——结构化字段会聚合成一个可搜索的词汇库；多次调用在已有流量上保持一致，却在下一个请求上发生分叉；这些示例反过来成为规范，而上述 41 个子任务族系，就是这份规范被允许使用的语言。