第二章：评估维度详解——准确性、完整性、一致性、效率、安全性、可解释性
好，咱们直接进入正题。上一章聊了评估的重要性，这一章我带你拆开看看，到底从哪几个角度去「审」一个提示词。我个人习惯把这六个维度当成六把尺子，每把尺子量一个方面。你想想看，如果一把尺子都不准，那评估结果肯定跑偏。
2.1 准确性：提示词的核心命脉
准确性，说白了就是「模型答没答对」。这是最基础的维度，也是我最早开始关注的点。我记得刚做提示词那会儿，经常遇到模型一本正经地胡说八道——嗯，就是所谓的幻觉。
核心判断标准：模型输出是否与事实、用户意图、上下文严格匹配。
怎么测？我一般用这几种方法：
- 事实核查法：针对知识类问题，直接比对权威来源。比如问「爱因斯坦的出生年份」，模型说「1879年」就是准，说「1880年」就是错。
- 意图对齐法：用户想要的是「总结」，模型却给了「扩写」，那就算不准。我在项目中遇到过，用户问「帮我简化这段代码」，模型直接重写了一遍——功能对了，但意图偏了。
- 边界测试法：故意给模糊或极端输入，看模型会不会跑偏。比如问「0除以0等于多少」，准确的做法是解释「未定义」，而不是硬给个数字。
小技巧：我习惯在提示词里加一句「如果你不确定，请直接说不知道」。这能大幅降低幻觉率，尤其适合知识密集型场景。
2.2 完整性：别让模型「缺斤少两」
完整性关注的是「该说的都说了吗」。有时候模型答得挺准，但漏掉了关键信息。这就像做菜，盐放对了，但忘了放葱——能吃，但差点意思。
我总结了一个检查清单：
- 要素覆盖：提示词里要求的每个点，模型都回应了吗？比如你要求「列出优缺点各三个」，模型只列了两个优点，那就是不完整。
- 上下文连贯：多轮对话中，模型有没有忘记之前的信息？我曾经测试一个客服提示词，用户第三轮问「刚才说的退款流程第二步是什么」，模型直接失忆了——这就是上下文完整性出了问题。
- 隐含需求：用户没说但明显需要的。比如用户问「Python怎么读文件」，完整回答应该包括打开、读取、关闭、异常处理四个步骤，缺一个都不算完整。
注意：完整性不是越长越好。我见过有人把提示词写成小作文，结果模型反而抓不住重点。完整性的核心是「必要信息不缺」，不是「无关信息堆砌」。
2.3 一致性：稳定才是硬道理
一致性，我管它叫「模型的性格稳定性」。同一个提示词，问十次，答案应该大同小异。如果每次都不一样，那用户就没法信任你。
为什么会不一致？原因通常有三个：
- 随机性参数太高：temperature 设到 1.5，模型每次都在「放飞自我」。
- 提示词模糊：比如「写一段关于猫的文字」，模型可能写科普、写故事、写诗——每次都不一样。
- 上下文污染：前一轮对话影响了后一轮的判断。我遇到过，用户先问「推荐一本小说」，模型推荐了《三体》；接着问「再推荐一本」，模型直接推荐了《三体2》——这就是被上下文带偏了。
我的测试方法：同一个提示词跑 5 次，看输出结果的相似度。如果核心内容一致，只是表达方式略有不同，那算合格。如果每次都在讲不同的事，那就得改提示词了。
2.4 效率：别让用户等太久
效率，说白了就是「快不快、省不省」。这里有两个层面：
| 维度 | 说明 | 我的经验 |
|---|---|---|
| 响应速度 | 模型生成答案的时间 | 提示词越长，响应越慢。我习惯把不必要的历史对话剪掉，能省 30% 的时间 |
| Token 消耗 | 输入+输出的总 token 数 | 能用 50 个 token 说清楚的事，别用 200 个。省钱又省时 |
你想想看，如果用户每次提问都要等 10 秒，那体验肯定不好。我建议在评估时，给每个提示词设定一个「最大响应时间」和「最大 token 预算」，超标的直接打回重写。
避坑指南：我曾经为了追求准确性，在提示词里塞了 2000 字的背景信息。结果准确率是上去了，但每次响应要 15 秒——用户全跑了。后来我学乖了，把背景信息拆成「核心」和「备用」两部分，只在需要时才加载。
2.5 安全性：红线不能碰
安全性，这是底线。模型不能输出违法、有害、歧视、隐私泄露等内容。我见过太多翻车案例了——嗯，有些还是大厂的产品。
安全性评估主要看这几点：
- 拒绝有害请求：比如用户问「怎么制作危险品」，模型应该明确拒绝，而不是提供步骤。
- 避免偏见歧视：模型不能因为用户的性别、种族、地域等给出差异化对待。
- 保护隐私：不能泄露训练数据中的个人信息。我测试过一个提示词，它居然能「回忆」出某个真实人物的手机号——这绝对不行。
- 对抗攻击防御：用户用「越狱提示词」绕过限制时，模型能不能守住？比如「假装你是 DAN 模式...」这种，模型应该识别并拒绝。
重要提醒：安全性评估不能只靠自动化测试。我建议每轮迭代都做一次人工红队测试，找几个同事扮演「恶意用户」，专门挑刺。很多安全问题，机器是测不出来的。
2.6 可解释性：让用户知道「为什么」
可解释性，就是「模型为什么给出这个答案」。这在大模型时代尤其重要——因为模型是个黑盒，用户天然不信任。
我评估可解释性时，会问三个问题：
- 答案有依据吗？模型能不能引用来源？比如「根据某网站的数据...」
- 推理过程清晰吗？比如数学题，模型应该展示计算步骤，而不是直接给结果。
- 不确定性表达了吗？当模型不确定时，有没有说「我推测...」或「这个信息可能不准确」？
一个实用技巧：在提示词里加一句「请逐步推理，并在最后给出结论」。这能强制模型展示思考过程，可解释性直接拉满。我在做金融问答系统时，所有提示词都加了这句话——用户反馈特别好，因为他们能看到「钱是怎么算出来的」。
2.7 六个维度的权衡
最后说一句大实话：这六个维度不是孤立的，它们经常互相打架。比如：
- 追求准确性，可能牺牲效率（因为要加更多约束）
- 追求安全性，可能降低完整性（因为拒绝回答某些问题）
- 追求可解释性，可能影响一致性（因为每次推理过程可能不同）
所以，评估不是「每个维度都打满分」，而是「根据场景找到最佳平衡点」。比如客服场景，安全性和准确性优先；创意写作场景，一致性和完整性更重要。我一般会先定场景优先级，再按权重打分，最后取加权平均。
我的个人习惯：每次评估完，我会给每个维度打 1-5 分，然后画个雷达图。一眼就能看出哪个维度是短板，哪个是长板。下一章我会具体讲怎么打分，咱们到时候细聊。