AI 创业团队常把“准确率”当作一个按钮：换更大的模型、写更长的提示词，数字就会提高。可在真实产品中，正确性从来不是单一分数。分类要看标签，抽取要看字段，搜索要看证据，代理还要看有没有正确调用工具并完成动作。
优化的第一步不是调模型，而是把“对”写清楚，并找出哪种错误最贵。
## 把抽象准确率变成任务通过率
“回答得专业”无法稳定评分。把任务改写成可验收结果，例如订单号必须来自输入、价格必须由接口返回、引用必须打开并支持结论、JSON 必须符合模式。
每种任务单独计算通过率。不要把客服语气、事实正确和工具成功混成一个平均分。一个答案语气很好却给错退款金额，业务结果仍然失败。
再定义每类错误成本。漏掉普通标签也许只是多一次人工分流，误执行付款或修改数据则不可接受。优化资源优先投向高成本错误，而不是最容易刷高的指标。
## 先做一个朴素基线
选择当前最简单可用方案：固定模型、短提示、无复杂代理链。用一百到三百条真实样本运行，记录逐条结果、失败原因、延迟、费用和人工修改时间。
基线必须可重复。保存模型版本、系统提示、工具定义和测试数据快照。若每次实验都顺手调整多个部分，团队无法判断哪项改动有效。
创业团队不需要一开始建设庞大评测平台。一份结构化数据、一段批量运行脚本和明确评分器，就足以发现最主要的问题。
## 建立错误分类账
将失败分为至少五类：没有相关知识、检索到错误资料、理解任务错误、格式或工具参数错误、知道证据却推理错误。不同类别需要不同解决方案。
没有知识时增加检索；检索错误时优化切分与排序；格式错误时增加模式校验；任务理解错误时改输入契约；真正的推理错误才可能需要更强模型。
每周统计错误数量、占比和业务损失。一个类别下降后，新的主要矛盾会浮现。持续改最高频且代价高的两类，比同时尝试十种技巧更有效。
## 动态事实交给检索和工具
价格、库存、排期和账户状态会变化，不应依赖模型记忆。让系统从数据库、搜索索引或业务 API 获取当前值，再要求模型基于返回结果组织答案。
检索增强不只看有没有找回文档，还要分开评估召回与最终答案。准备带已知证据位置的问题，计算正确片段是否进入候选、排序是否靠前、答案引用是否真正支持结论。
限制模型只能使用提供的证据，并允许在证据不足时明确说不知道。强迫每次都给答案，会把检索缺口变成自信幻觉。
## 结构化输出后立即校验
需要进入程序的结果使用 JSON Schema、枚举和类型约束。输出后先做语法与字段校验，再验证业务规则，例如开始日期不得晚于结束日期、金额不得凭空增加、引用 ID 必须存在。
校验失败时把具体错误返回模型修正一次，而不是从头自由重试多轮。超过重试上限进入人工队列，防止成本和延迟失控。
对可以由代码完成的计算、去重和排序，不让模型生成。模型负责理解与映射，程序负责确定性操作，准确率通常会自然提高。
## 用小模型做窄任务
并非每一步都需要旗舰模型。语言识别、简单分类、字段清洗和路由可以由小模型或规则处理，复杂推理与模糊输入再升级。
模型路由器也要有测试集。若它把困难任务误送给小模型，整体正确率会下降；若所有任务都升级，节省又不存在。记录升级比例、误路由和重试次数。
选择模型时比较每个合格结果成本。便宜模型连续失败两次再调用大模型，可能比直接调用中型模型更贵、更慢。
## 允许系统拒答和转人工
准确率高的系统不一定回答得最多。信息不足、证据冲突、请求超出能力或动作不可逆时，正确行为可能是询问更多信息或交给人。
不要仅凭模型自己说“我有 90% 把握”决定是否自动执行。置信度要从可观察信号组合：检索分数、多个候选一致性、字段校验、工具返回和历史同类通过率。
为转人工设置原因码，并让人工结果回流测试集。若人工队列中大部分任务其实可以自动处理，再针对该类别改善；若某类错误代价极高，保持人工复核可能就是最优产品设计。
## 用对照实验改提示词
提示词优化前先提出假设。例如“补充两个反例能减少多意图误分”，而不是笼统地让提示更详细。只改变一个主要变量，在同一回归集上比较。
示例要覆盖边界，不要只展示最典型答案。说明什么情况应该拒绝、缺字段时如何处理、多个目标冲突时哪个优先。
提示过长会带来成本并可能埋没关键规则。稳定要求放在靠前位置，动态资料清楚分隔，重复说明删除。若规则越来越多，考虑把确定性部分移到代码。
## 评分器自身也需要测试
准确率数字依赖评分器。完全匹配适合标签和数值，不适合允许多种正确表述的摘要；模型评分适合语义判断，却可能偏爱冗长答案或自己的写作风格。
取一批由领域人员标注的样本，测评分器与人工的一致性。争议样本保留理由，不要强行制造唯一答案。评分规则修改后重新计算历史结果，避免前后数字不可比。
最重要的指标采用双重验证。例如引用既检查 URL 存在，也检查引用片段是否支持句子；工具任务既检查调用参数，也检查最终业务状态。
## 把线上反馈变成回归样本
用户点踩只是信号，不是答案。收集用户修改、人工接管、重试和取消，再由团队判断真正原因。将可复现且有代表性的失败去除敏感信息后加入回归集。
按时间留出一组未来样本，观察产品是否只记住旧问题。业务季节、用户群和数据源变化会引起分布漂移，旧测试集全绿也可能掩盖新失败。
每次发布运行核心回归集，每周运行完整集，每月抽样人工复核线上成功结果。只有失败样本会产生幸存者偏差，因为“看似成功但事实错误”的请求最危险。
## 准确率与产品流程一起优化
有时最好的改进不是模型。把一个含糊表单拆成两个问题、为用户提供可选标签、在提交前展示预览，都会减少输入歧义和不可逆错误。
让用户能轻松纠正单个字段，而不是重新生成整段内容。显示来源和系统使用的关键条件，用户就能更快发现偏差。
对高风险动作采用“草稿、确认、执行”三段式。模型先提出结构化草稿，程序验证，人确认后工具执行。流程设计可以把一次错误限制在可恢复阶段。
## 30天优化闭环
第一周定义两个核心任务、硬门槛和错误成本，建立朴素基线。第二周整理错误分类账，只处理最大的两个类别，例如检索缺失和格式失败。
第三周加入结构化校验、拒答和一次有限重试，测量每个合格结果的成本。第四周用少量真实流量对照，抽样人工复核，并把新失败加入回归集。
一个月后报告的不应只是“准确率提高了几分”，还应包括关键错误减少多少、人工时间如何变化、转人工比例、延迟和成本是否可接受。
## 小团队的优势是反馈短
创业公司资源有限，却更容易让产品、运营和工程共同查看同一批失败。把每次用户纠正变成结构化证据，把每次改动变成可重复实验，迭代速度会比盲目追逐新模型更有价值。
准确率不是模型独有的属性，而是数据、检索、提示、工具、校验和交互共同形成的系统结果。先把错误变得可见，再逐类减少，才是能持续积累的优化方法。
## 参考资料