LLM

先从一个任务理解#

假设你要把客户留言分成“咨询、故障、其他”。传统程序需要你写分类规则；语言模型可以根据说明和例子尝试分类。它的价值在于处理表达多样的文本，但仍需要用真实留言验证，而不能因为几个例子答对就直接上线。

LLM 是 Large Language Model（大语言模型）的缩写。token 是模型处理文本的基本单位，可能是一个字、词的一部分或符号，不能固定按“一个 token 等于一个汉字”估算。具体切分取决于模型使用的分词器。3

模型、上下文、工具的分工#

现代语言模型常以 Transformer 为基础；注意力机制让序列中的信息相互作用。原始论文解释的是架构，不是“模型永远会关注正确事实”的保证。1

• 训练改变模型参数，让模型学习数据中的模式。
• 上下文是本次推理能使用的输入，例如任务说明、文档和历史。把例子放入输入，并不等于当场训练模型。GPT-3 论文中的少样本实验明确区分了这两者。2
• 工具由外部系统提供数据或执行操作。能查库存的聊天产品，通常还包含库存接口和应用代码，不能把整套产品能力都归给语言模型。

本文主要讨论应用开发中常见的生成式语言模型，不把所有语言理解模型都简化成同一种生成架构。

一个可操作的任务拆分#

教学示例：客服留言分类。 输入是“订单一直没发货，能查一下吗？”。模型可以提出“物流咨询”的分类和原文依据，但订单是否存在、当前用户是否拥有该订单，应由业务系统核查。

一个合理的分工是：模型理解留言 → 代码检查分类值 → 查询有权限访问的订单 → 组合回复。如果只需要按订单号查询状态，查询本身交给普通代码即可，不必让模型重新“猜”一次。

如何判断值得用#

以下是本站的实践建议，不是论文给出的统一门槛：

1. 写清输入和输出。例如“每条留言输出一个允许的分类”，比“让客服更智能”容易验证。
2. 保留一组正常、含糊和超出范围的留言，先由人标注。
3. 比较模型和简单规则的错误类型、人工复核成本及响应时间。
4. 对模型拿不到的信息允许“不知道”或转人工，不要求它填满所有答案。

常见误判怎么排查#

说得很流畅，却引用了不存在的规则： 先检查有没有把正确资料提供给模型。需要外部知识时继续读 RAG。

换一种措辞就分类不同： 查看分类定义是否重叠，增加边界样例，再做 评测。

输出解析失败： 不要把格式问题和知识问题混为一谈。程序需要稳定字段时，查看 结构化输出。