本节摘要:把模型当员工用,先要清楚它的岗位技能。本节按"语言、知识、推理、结构化"四类盘点真实能力,给出每类的靠谱度与用法建议,并用一张发票抽取案例演示最值得信赖的用法——结构化输出。
「Few-Shot」这个词在模型说明书里出现的频率,比"会思考"高得多——这个细节其实泄露了天机:模型的强项是从示例中模仿,而不是从零开始推理。给两个例子它能照着做对,让它凭空推理五步就未必了。盘点能力时抓住这条主线,很多现象就解释得通。
语言能力(靠谱,主力业务区)。生成、改写、摘要、翻译、语气调整——这是预训练学得最透的部分。靠谱的原因在于任务的正确性可以宽容:摘要漏了一个次要细节不算错,语气差一点可以再改。工程上唯一要注意的是长度控制,超长输入的摘要会"前重后轻",这在第 3 章讲窗口管理时会回过来处理。
知识调用(半靠谱,必须验真)。模型记住了海量公开知识,问"Python 列表怎么去重"它能秒答。但两个坑必须写进制度:知识停留在训练截止日,问它"昨天发布的版本"必然瞎编;冷门细节的置信度低,它却用同样的流利语气回答。所以知识类用法一律配检索(第 6 章),不裸用。
推理能力(受限,要喂料)。给足条件时,它能做日程排布、账目核对、找出合同条款间的矛盾——这些本质是"在上下文里做逻辑操作"。限制在于步数和广度:步骤一多就容易丢条件,选项一多就容易漏比。第 4 章的 CoT、ToT 就是在给推理"搭脚手架"。
结构化输出(最值得信赖,工程价值最高)。让它按指定格式输出 JSON、按分类法打标签、按模板抽取字段——这是把语言能力用在"格式服从"上,而格式服从恰恰是它最稳的表现。智能体系统里工具调用的参数生成,靠的正是这个能力。
背景:财务想自动化报销审核,第一步是从员工上传的发票照片 OCR 文本里抽取关键字段:开票方、金额、税号、日期、明细行。
操作:不训练任何模型,只用提示词 + 少量示例。提示词的核心是给出 schema 和两个标注示例,然后要求"只输出 JSON,不要解释":
SCHEMA_EXAMPLE = """按以下 JSON 结构输出,字段缺失时用 null: {"vendor": str, "total": number, "tax_id": str, "date": "YYYY-MM-DD", "items": [{"name": str, "amount": number}]} 示例输入:XX科技有限公司 增值税专用发票 金额合计 11300.00 元 税号 91330106MA2XXXXX 开票日期 2024年05月12日 明细:咨询服务 10000.00;税额 1300.00 示例输出: {"vendor": "XX科技有限公司", "total": 11300.00, "tax_id": "91330106MA2XXXXX", "date": "2024-05-12", "items": [{"name": "咨询服务", "amount": 10000.00}]}""" def extract_invoice(ocr_text: str) -> dict: raw = llm.complete(system="你是发票信息抽取器,只输出 JSON。", user=SCHEMA_EXAMPLE + "\n\n发票文本:\n" + ocr_text) data = json.loads(raw) # 模型输出转结构 assert isinstance(data["total"], (int, float)) return data
结果:在内部抽测的三百张样本上,字段级准确率在九成五以上;金额与税号两个关键字段配了校验规则(金额合计等于明细之和、税号位数合法)之后,进入财务系统的脏数据几乎归零。
解读:这个案例成立的三个条件值得记住——输出格式客观(对错分明)、输入材料完整(OCR 没漏字)、错误可被规则拦截。三个条件同时满足时,模型能力"足够好"且可验证,这就是可以放心交给模型的部分。
变式:如果字段里出现"发票状态"(是否作废)这种需要查外部系统的信息,抽取就变成了两步任务——先抽取再查询,那就进入了智能体领域,本节的结构化输出退化为其中一步的组件。
| 能力 | 靠谱度 | 用法建议 | 失效信号 |
|---|---|---|---|
| 生成与改写 | 高 | 直接用,配长度与格式要求 | 超长输入后半段质量下滑 |
| 抽取与结构化 | 高 | 配 schema + 规则校验 + 少量示例 | 输入本身残缺或格式混乱 |
| 分类打标 | 高 | 固定标签集,给边界示例 | 标签集频繁变动 |
| 知识问答 | 中 | 一律配检索,答案带出处 | 问到截止日之后的事 |
| 短链推理 | 中 | 给全条件,限制步数,要中间步骤 | 条件超过十条或步数超过五步 |
| 数学计算 | 中低 | 让它写表达式,交给计算器执行 | 大数乘除、浮点精度 |
| 实时信息 | 无 | 必须走工具查询 | 任何"最新""今天"类问题 |
💡 关键直觉:模型像一个记性极好、表达力极强、但不主动查证也不动手的资深文案。把"表达"派给它,把"查证"和"动手"用工程设计接上,它就是好员工;直接把"决策权 + 行动权"全给它而不加检查,它就是风险源。
同样是抽取任务,换个需求就翻车:"从合同里判断这份协议对我方是否有利。"模型会自信地输出一段结论,但它没告诉你:判断依据的行业标准你没给,"有利"的定义没对齐,条款之间的引用关系它可能看漏。这类主观判断 + 长材料的组合,正确做法是拆解——先抽取条款结构化,再逐条比对红线清单,最后汇总——而这正是第 4 章规划要解决的问题。识别"这个问题对模型来说太难了",和识别"这个问题很简单"同样重要。
下一节把镜头转向另一面:四个"不会",每一个都会在后面的章节里变成一个工程模块。