大模型宣传中的诚实性边界与评测实践

当一则大型赛事广告以幽默方式暗示竞品能力不足，并引发对方公开回应时，行业讨论往往集中在“是否好笑”“是否诚实”。对技术团队而言，更有价值的追问是：模型能力与诚实性如何被定义、测量和持续保障？营销语言可以制造记忆点，但工程系统必须面对事实一致性、边界拒答、来源追溯、版本回归和线上运营。本文不讨论具体厂商或产品，而是把“诚实”还原为可落地的技术问题，给出一套面向开发者与企业用户的评测与治理框架。

一、从营销话术回到工程问题

营销中的“更诚实”通常是一种相对表达：在有限示例、特定提示和人工挑选的对比中，某个模型显得更少编造、更愿意承认不知道，或者更少迎合用户。但开发者选型时面对的是开放场景：长尾问题、时效信息、多轮对话、工具调用、权限约束、成本延迟和稳定交付。广告式对比无法回答这些工程问题。

因此，技术团队需要完成一次语义转换：把“诚实”拆成可观测行为，把“能力”拆成可复现任务，把“对比”拆成可统计实验。具体来说，任何关于模型表现的主张，都应至少说明任务分布、评测方法、样本规模、判定标准、失败案例和适用边界。没有这些信息，“更诚实”只能算传播口径，不能作为架构决策依据。

二、“诚实性”的可操作定义

在大模型语境下，诚实性不应被简单理解为“回答听起来可靠”。它至少包含以下可操作维度。

1. 事实一致性

事实一致性要求模型回答与可信上下文、权威数据源或明确知识边界保持一致。工程上可通过检索增强生成引入外部证据，再检查回答中的关键结论是否被证据支持。评测时不能只看最终答案是否正确，还要看推理链中的关键事实是否被上下文覆盖，以及模型是否在证据不足时仍然给出确定性结论。

2. 不确定性表达

模型需要区分“知道”“不确定”“不知道”和“上下文未提供”。高质量系统应允许模型在证据不足时表达限制，而不是用流畅语言掩盖空白。评测可设置证据缺失、冲突证据和边界问题，观察模型是否过度自信，是否主动要求澄清，是否给出可验证的下一步。

3. 来源可追溯

对知识问答、企业检索和合规场景，来源可追溯比单次答案正确更重要。系统应记录回答引用了哪些片段、片段来自哪个版本的数据源、模型是否忠实于引用内容。若回答无法给出支持证据，应降低置信度或转入人工复核。

4. 边界拒答

拒答不是越多越好。过度拒答会损害可用性，错误回答则带来风险。需要同时测量拒答精确率与拒答召回率：该拒答的风险问题是否被拦住，不该拒答的普通问题是否被误伤。对权限不足、隐私数据、越权操作和超出知识范围的问题，应设置明确策略。

5. 时效与冲突处理

企业知识会更新，外部事实会变化。系统应识别时间敏感问题，优先使用最新版本数据；当多个来源冲突时，应展示冲突、说明取舍依据或转人工处理。评测集应包含旧版本数据、更新后数据和冲突数据，观察模型是否盲目复述过期信息。

三、为什么广告式对比不能作为选型依据

广告式对比常见的问题包括：样本选择偏向展示效果、提示词经过反复调优、裁判标准不透明、成本与延迟未披露、失败案例未覆盖、评测集可能被污染。对开发者而言，更可靠的做法是构建自己的场景化评测集。

场景化评测应覆盖真实业务任务，而不是只测通用问答。例如企业知识检索要测多跳问答、表格理解、权限过滤和引用准确性；智能编程工具要测代码补全、缺陷修复、测试生成和依赖约束；客服系统要测多轮澄清、情绪管理和升级转人工策略。不同场景的“诚实”标准并不相同，不能用一套平均分替代。

四、构建可复现的评测体系

一套可复现的评测体系至少包括任务集、标注规范、指标定义、盲测流程和统计分析。

任务集应分层建设：核心高频任务、长尾边界任务、风险拒答任务、时效更新任务、多轮对话任务和工具调用任务。每个任务保存问题、上下文、期望行为、判定标准和版本信息。标注规范要明确什么算事实错误、什么算合理不确定、什么算可接受拒答，减少评审主观性。

指标方面，可组合使用：事实准确率、幻觉率、引用支持率、拒答精确率、拒答召回率、不确定性校准误差、同义改写稳定性、越权回答率、平均延迟和单位请求成本。指标不是越多越好，应与业务风险对应。面向合规的场景应提高引用支持率和越权回答率的权重；面向效率的场景则要关注延迟与成本，但不得以牺牲关键安全指标为代价。

盲测流程建议对模型身份、版本和提示策略进行隐藏，由独立评审按统一规范打分；关键任务采用双人复核和冲突仲裁。统计上应报告样本量与置信区间，避免用少量示例得出绝对结论。线上阶段还要持续抽样，把真实失败案例回流到评测集，形成闭环。

五、把评测嵌入工程流水线

“诚实性”不能只在发布前做一次评测，而应嵌入需求、开发、发布和运营全过程。下面是一段示意性伪代码，用于说明回答评分与发布门禁的组织方式：

function score_answer(question, context, answer):
    fact_score = check_supported_by_context(answer, context)
    citation_score = check_citation_coverage(answer, context)
    uncertainty_score = check_uncertainty_expression(answer)
    refusal_score = check_refusal_appropriateness(question, answer, context)
    stability_score = check_paraphrase_stability(question, answer)
    return weighted_score(fact_score, citation_score,
                          uncertainty_score, refusal_score,
                          stability_score)
function release_gate(eval_result):
    if eval_result.hallucination_rate > threshold_hallucination:
        return "block"
    if eval_result.citation_support_rate < threshold_citation:
        return "block"
    if eval_result.refusal_precision < threshold_refusal:
        return "review"
    if eval_result.cost_or_latency_regression:
        return "review"
    return "pass"

这段伪代码的重点不是具体函数名，而是流程思想：先按场景定义评分维度，再把评分结果接入发布门禁。模型版本、提示模板、检索策略、切分参数或权限规则发生变更时，都应触发回归评测。门禁阈值应由业务风险、历史基线和人工复核能力共同决定，不能照搬外部榜单。

工程实现上，可采用检索增强生成、工具调用、结构化输出、答案校验、置信度阈值和人工复核等通用方案。检索增强用于提供证据，工具调用用于获取实时数据或执行受控操作，结构化输出便于自动校验，答案校验用于发现无依据结论，置信度阈值用于把低置信回答转入复核。所有这些能力都需要日志记录和可追溯审计。

六、云上落地与运营机制

在百度智能云等通用云环境中，评测流水线可以拆成几类通用能力：对象存储保存版本化评测集与运行产物；日志服务采集请求、检索片段、模型输出与人工复核结果；监控告警对幻觉率、拒答率、延迟和成本异常进行告警；容器平台承载批量评测与回归任务。这里的关键不是某个具体接口，而是把数据、任务、指标和审计链路标准化，使每次模型版本、提示模板或检索策略变更都能复现实验结果。

运营机制同样重要。建议设立红队测试、发布评审和宣传口径技术审核。红队测试主动构造诱导性、冲突性、越权和时效性问题；发布评审检查评测覆盖度与失败案例；宣传口径技术审核要求营销素材中的能力主张能够对应到可复现实验，并明确适用边界。对于无法量化或条件不充分的表述，应改用限制性语言，避免把实验结论包装成普遍能力。

七、结语

营销可以让行业短暂关注“谁更诚实”，但工程系统需要长期回答“如何证明、如何复现、如何监控、如何回滚”。对大模型应用而言，诚实性不是一句品牌口号，而是由事实一致性、不确定性表达、来源可追溯、边界拒答和时效处理共同构成的行为集合。只有把评测任务、指标、日志、门禁和人工复核连接成闭环，团队才能把宣传话术转化为可验证的技术能力，并在真实业务中持续控制风险、提升可用性。