修复评估偏差，在 Amazon Bedrock 上释放模型潜力

AWS ML Blog 2026-10-28T21:53:41.184159

本文由 Property Finder 的 Khaled Thabit、Meriem Boughrara 和 Mohamed Desouky 共同撰写。

数字房地产应用 Property Finder 的工程团队发现，他们的评估标签中有 96.8% 直接沿用了某个模型的预测结果，并未经过人工专家核验。也就是说，所谓的"真实答案"系统性地偏向现有模型，导致任何替代方案看起来都更差。这些标签本身也有错误，但真正阻碍客观模型对比的，是这种偏差。他们是在把视觉 AI 工作负载迁移到 Amazon Bedrock 上更具成本效益的方案时，才发现这个问题的。

Property Finder 每天要在中东和北非（MENA）地区处理数万张房产图片。他们的系统会对每张图片评估 11 项质量属性，涵盖水印检测、房间分类、装修状态、照片质量和施工迹象等。这意味着数千条新房产房源，每条平均 15 张图片，全部需要在上线前完成质量评估。

Property Finder 需要更具成本效益的方案。但用那些标签来衡量，任何替代方案都处于劣势。最难的部分不是找到更好的模型，而是发现评估方法本身就是障碍。

本文分享 Property Finder 如何识别评估偏差、构建无偏差的真实答案，并应用进化式提示优化（evolutionary prompt optimization）在 Amazon Bedrock 上选出合适的模型，最终实现更高准确率、成本降低 86%。我们会介绍这套方法及迭代示例，其中的经验可以应用到你的工作负载中。

下图展示了 Property Finder 与 AWS 生成式 AI 创新中心团队使用的提示优化循环，用于在 Amazon Bedrock 上迭代提升分类准确率。

图 1：提示优化循环架构本段原文与已译内容完全重合：译文已覆盖到「图 1：提示优化循环架构」，没有新的待译内容。请提供后续段落，我再继续翻译。

下图展示了迭代式提示词优化流程。一张房源图片先交给 Amazon Bedrock 处理，输出的预测属性采用 JSON 格式。优化时，这些预测会拿 256 张图片、经专家标注的开发集做 Micro F1 打分。接着做误差分析，检查出错的图片，找出视觉上的规律，用来指导下一版提示词。循环从 v0 一直跑到 v27。期间有 AI 助手帮忙打磨提示词，后期版本还引入了自动优化。

你的评估结果可能在“说谎”

很多团队都碰到过这种情况。想比较几个视觉模型，于是动手搭一个评估数据集。最常见的做法是：直接跑一遍当前在用的模型，把它的输出当成标准答案。反正这个模型已经上线跑了很久，没人抱怨过，那标签应该够用了吧。可这么一来，评估就绕成了一个圈——新模型好不好，只取决于它跟老模型的行为有多像，而不是它到底对不对。

Property Finder 的评估数据集正是这个问题。在他们标注的样本里，有 96.8% 直接来自现有视觉语言模型（VLM）的预测，并非独立的人工核验。也就是说，还没开始处理第一张图片，其他候选模型就已经处于结构性劣势了。

隐藏的错误进一步印证了问题的严重性。水印文字提取中，有些字符级错误被标成了正确，包括凭空捏造的品牌名和漏掉的字符。照片分类则把多房间类型的图片硬塞进单一标签。而在剩下那 3.2% 的人工标注样本里，标注员还引入了超出原始规范的类别——比如提示词里根本没有 Office 这个标签，却出现了 Office 的标注。

当你用来比对的答案，是由你正想替换掉的那个模型写出来的，模型比较就失去了意义。

建立可信的真值

要打破这个循环，得请真正懂业务的专家，独立做全新标注。不参考之前模型的输出，也不许看当前在用的模型预测过什么。

数据集范围

Property Finder 团队人工标注了 356 张阿联酋图片，以及另一组埃及图片。这些图片来自各代表性行业板块中未标注的生产房源。本文报告的是阿联酋图片上的结果。埃及图片用于跨区域验证，共 230 张，本文不报告这部分结果。

最先标注的 256 张阿联酋图片组成开发集，用于调优。最终模型对比所用的评估集包含全部 356 张，其中 100 张是在开发阶段运行结束后补充标注的。356 张的规模大致足以检测模型之间的中等差异。单个属性下的稀有类别样本更少，因此这些属性上的较小差异可能无法检测出来。

专家标注

一位战略与分析专家标注了所有图片。这位专家具备房地产房源质量标准方面的专业知识。AWS 生成式 AI 创新中心团队通过专门的澄清会议开展系统性质检。这些质检解决了模糊案例，并确保整个数据集的标注保持一致。

多标签转换

房地产图片经常透过门洞展示多个房间，或呈现重叠的质量特征。从单标签分类转为多标签分类，消除了一大 artificial 歧义来源。一张透过门洞看到卧室的走廊照片，确实同时属于两者。允许多个标签后，你衡量的是模型做对了什么，而不是因为合理的次要预测而惩罚它。

一种混合方法可以补充这套方法论：来自不同模型家族的模型提出候选标签和分歧，由人类专家裁决每个案例，因此不会直接把任何模型输出当作标签使用。这将减轻未来数据集扩展时的标注负担。

指标选择

Micro F1 作为主要指标，因为它对每个预测一视同仁，这与整体标签正确性的业务目标一致。同时报告 Macro F1，因为 Micro F1 会被高频类别主导，可能掩盖稀有属性上的薄弱表现。每个标签的精确率和召回率有助于定位具体的失败模式。每个样本的交并比（IoU）衡量每张图片的预测标签与专家标签的重叠程度。九个单标签属性（如旋转或水印检测）每张图片只有一个正确答案。AWS 团队还用精确匹配准确率给它们打分，即答案与专家标签一致的图片占比。

把提示词优化当作强化学习

有了无偏的评估，就可以开始改进了。测不准的东西，就改不好。

优化过程遵循一个类似强化学习的循环。把每个提示词版本看作一个智能体，Micro F1 分数是奖励信号，提示词文本是策略，错误分析则是指向下一步该改什么的梯度。每一轮迭代中，提示词版本因为答对更多标签而获得奖励，因为失败图片中暴露的具体错误而受到惩罚。

实际循环的样子

图 2：开发集上各提示词迭代版本（v0 到 v27）的 Micro F1

基线提示词（v0）列出了 11 个属性，每个配一句最简描述，要求以 JSON 格式回答。它在高频、视觉上明显的标签上表现尚可，但在定义模糊的属性上表现很差。大部分提升来自三类改动。

错误分析定方向

每一轮迭代都从检查当前提示词答错的图片开始，而不是把提示词推倒重写。评审人员把失败案例归入视觉模式：水印被渲染成半透明 logo、只能透过门看到的卫生间、在布景前拍摄的带家具房源。每种模式在下一版中变成一条明确指令或一个示例。

水印检测的问题最清楚。字符级错误——编造出来的品牌名、漏掉的字符——根源在于提示词只问“有没有水印”，却没有规定该怎么转录文字。修法是要求只转录可见字符，文字模糊不清时允许返回明确的“未知”值，并加入少量难处理的裁剪图作为示例。

房间分类的失败则源于单标签的框架。任务改成多标签后，提示词必须写明：所有可见房间都要列出，包括从开口处看到的房间。只改这一处，大部分看似错误的结果就消失了，模型本身没动。

用判定规则取代形容词

照片质量、装修状态、施工迹象这类属性，起初都用形容词描述——“清晰”“部分装修”“施工中”。这些说法留了太大的解释空间，不同图片会把模型带向不同方向。后续版本换成了有序的判定规则：先看这个，再看那个，两者都不符合就返回这个值。凡是取值集合固定的，提示词就明确枚举出来，并用 JSON schema 强制约束，由此消除了一整类格式错误或凭空编造的标签。

示例来自失败案例，而不是现成库

少样本示例都是从开发集里失败的图片中挑出来的——每种失败模式配一到两个，并且保持平衡，避免某一类独占。这样提示词可以保持简短，同时又能对准模型实际犯的错。当某种模式不再出现时，对应的示例就会被换掉。

后续迭代交给自动化

早期版本靠人工反复调整，走完了整个迭代流程。到了后期，优化改由自动化完成：AI 助手提出提示词的修改方案，每个候选方案都在开发集上打分，只有能提升 Micro F1 的修改才会保留。这样做加快了搜索速度，但也让防护措施变得必不可少。开发集只有 256 张图片，分数的小幅波动可能只是噪声，并非真正的改进。因此，只有当候选提示词在多次重复运行中都能稳定提升，且不降低任何单一属性的召回率时，才会被采纳。

结果

用专家标注的真实结果来衡量，优化后的提示词在成本更低的 Amazon Bedrock 模型上表现优于现有配置，每张图片的成本降低了 86%。但结果本身不如产生它的过程重要：如果把同一套优化流程用在原来那批有偏差的标注上，选出的模型只会更接近现有模型，而不是更准确。

有两项检查支持这一结论。第一，最终对比使用了全部 356 张图片的评估集，其中 100 张是在调优结束后才标注的，所以报告的提升并非在调优所用的数据上测得。第二，另外标注、从未用于优化的 230 张埃及图片集显示出同方向的改进，说明提示词的改动能跨地区泛化，而不是只拟合了阿联酋本地的图像。

改进在二十多次迭代后就趋于平缓。剩下的错误集中在稀有类别和确实模棱两可的图片上，这正是预期中的曲线形态。继续修改提示词带来的变化已落在噪声范围内，团队选择停手，不再追下去。

可以借鉴的经验

在比较模型之前，先审查标注的来源。如果你的真实标注大部分来自你正打算替换掉的那个模型，那你比较的其实是它与现有模型的相似度，而不是它是否准确。

用领域专家重新标注，并且不让标注者看到之前的预测结果。只要几百张精心标注的图片，再留出一部分做评估集，就足以检测出中等程度的差异——前提是你清楚自己的数据集有哪些稀有类别是分辨不出来的。

当内容本身就是多标签时，优先用多标签框架。如果对合理的次要预测也进行惩罚，会虚高错误率，掩盖真实的进步。

把 Micro F1 和 Macro F1 放在一起看，同时关注每个标签的精确率、召回率，以及每张图的 IoU（交并比）。总体数字告诉你在不在进步，分标签的数字告诉你在哪里进步。

用错误分析决定下一步改什么，而不是靠对提示词的直觉。针对实际观察到的失败去写指令，才能泛化；针对想象中的失败去写指令，只会让提示词更长、更含糊。

每一项优化收益，都要在提示词从未见过的数据上验证。自动化提示词搜索很容易在小规模开发集上过拟合。

结论

Property Finder 的瓶颈不在模型选择，而在评估集——它继承了现有模型的错误，根本分不清「更好的模型」和「只是不同的模型」。用独立专家标注重建基准真值、转向多标签分类、按属性逐项打分，比较才变得有意义。在这个无偏信号上做提示词优化，最终让一个成本更低的 Amazon Bedrock 模型取得了更高准确率，成本降低 86%。如果你每次比较模型，结论都是「没一个比得上现在用的」，先查查标准答案是谁写的。

把评分当作奖励信号，把错误分析当作改进的梯度。这个思路类似 GEPA（遗传-帕累托反思式提示进化）：变异提示词的各个组件，评估适应度，选出存活者，迭代下去。在这个项目中，AWS 团队的大部分版本都是根据错误分析来改进的——由 AI 助手审阅失败的图片并提出修改建议。v27 版本的图片分类任务还借助了 DSPy 库中的自动化提示优化框架 MIPROv2，作为对人工流程的补充。

起点

第一个提示词（v0）用的是通用分类指令，这里简化示意一下：“把这张图片归入以下类别之一：客厅、厨房、卧室、卫生间……”

Property Finder 的生产基线是专有模型 A，在 256 张图片的开发集上 Micro F1 为 0.55。它用的是 v22，这是针对其模型系列调优过的提示词。v21 之前的分数来自更早的单标签设置，不能直接拿来比较。

逐轮迭代

AWS 团队在几个候选模型上测试了早期版本，并补充了结构化输出格式和按属性区分的定义。最有启发的一处修正来自图像级别的错误分析。在早期的单标签版本里，模型总是把透过门口看到的房间归为次要房间类型。AWS 生成式 AI 创新中心团队补充了明确指令，要求按占据画面大部分的那个房间来分类。后来切换到多标签输出，把主房间保留为一个标签，同时允许将透过门口看到的房间作为额外标签。

区域定制带来了下一波提升。在某些地区，房源照片上会带装饰性的阿拉伯文字叠加，这些文字并不是水印。针对这类文字制定的规则消除了一整类误报。

v21 提示词把照片分类和房间类别都改为多标签输出，并成为所有模型共用的起始提示词。借助这个提示词，Meta 的 Llama 4 Maverick 17B Instruct 在开发集上拿到了 0.75 的 Micro F1。

从这之后，AWS 团队针对每个模型分别调优提示词。对这个模型来说，v24 重点处理房间面积高估、多标签处理和输出格式三个问题。随后 v25 是自动优化版本，把关键任务排到前面。在 v27 里，MIPROv2 重构了照片分类任务，模型在该任务上的 Micro F1 达到 0.76。

最终成果

最终提示词 v27_PF 是在 v27 基础上，加入了 Property Finder 针对效果图、带边框或画框的图片以及走廊场景补充的规则。和 v27 一样，它保留了阿拉伯语文字规则和输出格式指令。每次模型调用之后还会做一步归一化处理，解决剩余的格式差异。

在 356 张图片的评估集上，Llama 4 Maverick 17B Instruct 配合 v27_PF 取得了 0.80 的 Micro F1，而专有模型 A 配合 v22 只有 0.56。这个评估集包含了 256 张开发图片，两个模型的提示词又都是在这些图片上调优的，所以这些分数偏乐观。

从专有模型 A 切换到 Llama 4 Maverick 17B Instruct，各自使用自己调优过的提示词，开发集上的 Micro F1 从 0.55 提升到 0.81，相对提升 47%。仅就 Llama 4 Maverick 17B Instruct 而言，光靠提示词调优，就把分数从共享的 v21 提示词的 0.75 拉到了 v27 的 0.81。

失败尝试的经验教训

并非所有尝试都成功了。两桶方案把水印属性和其他属性拆成两次独立的 API 调用，准确率没有明显提升，带框图片的检测率还大幅下降。原因是水印属性不在同一个提示词里时，模型会把水印叠加误判成图片边框。通用提示词同样行不通，换哪个模型都一样。房地产图像领域特征太强，一套通用指令覆盖不了。

结果：成本、准确率与速度

AWS 生成式 AI 创新中心团队用这套无偏评估框架，在 Amazon Bedrock 上评测了多个模型。所有模型都从共享的 v21 提示词出发，然后在开发集上按各自模型家族进行调优。专有模型 A 只做了一轮调优，即 v22；Llama 4 Maverick 17B Instruct 做了多轮，从 v24 到 v27，再加上 Property Finder 的边缘场景规则，投入的调优精力更多。最终与专有模型 A 的对比使用的是 356 张图片的评估集。

Property Finder 基于全部 11 个属性的准确率和成本效率，选择了 Llama 4 Maverick 17B Instruct 用于生产负载。关于各区域的模型可用性，请参阅 Amazon Bedrock 中按 AWS 区域支持的模型。

下表展示了 Llama 4 Maverick 17B Instruct（v27_PF）在 356 张图像评估集上，每个单标签属性的精确匹配准确率。9 个属性中有 6 个达到 90% 或更高，且在全部 11 个属性上达到或超过了专有模型 A。在每张图像可对应多个标签的照片分类任务上，两者得分相同。

每 1,000 张图像的成本

Property Finder 每天要处理数万张图像，所以单张图像的成本很关键。Llama 4 Maverick 17B Instruct 是一个高性价比的开放权重模型，而且整条处理流程只需一次调用，就能拿到一张图像的全部属性。

推理速度

专有模型 A 是 Property Finder 的生产基线，在 256 张图像的开发集上取得了 Micro F1（微观 F1 分数）0.55。它使用的是 v22，即针对其模型系列调优的提示词。v21 之前的分数使用更早的单标签设置，不能直接比较。

逐次迭代

AWS 团队在多个候选模型上测试了早期版本，并添加了结构化输出格式和属性特定定义。最有启发性的修复来自图像级错误分析。

在早期单标签版本中，模型始终将通过门口可见的房间分类为次要房间类型。AWS Generative AI Innovation Center 团队添加了明确指令，要求根据占据画面大部分区域的房间进行分类。后来切换到多标签输出时，保留主房间作为标签，并允许将通过门口可见的房间作为附加标签。

区域定制带来了下一个提升。在某些地区，房源照片带有装饰性阿拉伯文字叠加层，这些不是水印。针对该文字的规则消除了一整类误报。

v21 提示词将照片分类和房间类别切换为多标签输出，并成为每个模型共享的起始提示词。使用它时，来自 Meta 的 Llama 4 Maverick 17B Instruct 在开发集上取得了 Micro F1 0.75。从那里开始，AWS 团队分别调优每个模型的提示词。对于该模型：

• v24 针对房间面积高估、多标签处理和输出格式。
• v25 是自动优化版本，将关键任务移到前面。
• v27 让 MIPROv2 重构照片分类任务，使该任务的 Micro F1 达到 0.76。

终点

最终提示词 v27_PF 是 v27 加上 Property Finder 为渲染图、带边框或画框的图像以及走廊添加的规则。与 v27 一样，它保留阿拉伯文字规则和输出格式指令。每次模型调用后的归一化步骤处理剩余的格式差异。

使用 v27_PF 时，Llama 4 Maverick 17B Instruct 在 356 张图像的评估集上取得了 Micro F1 0.80，而专有模型 A 使用 v22 得分为 0.56。评估集包含 256 张开发图像，并且两个模型的提示词都在这些图像上调优过，因此这些分数偏乐观。

从专有模型 A 切换到 Llama 4 Maverick 17B Instruct，两者各自使用调优后的提示词，在开发集上把 Micro F1 从 0.55 提升到 0.81，相对提升 47%。仅靠提示词调优，Llama 4 Maverick 17B Instruct 就从共享 v21 提示词的 0.75 提升到 v27 的 0.81。

失败方法的教训

并非所有尝试都成功：

• 2-bucket 方法把水印属性和其他属性拆成两次独立的 API 调用，准确率没有带来有意义的提升。
• 带边框图像检测也大幅退步。同一提示词里没有水印属性时，模型会把水印叠加层误认成图像边框。
• 通用提示词不管跑在哪个模型上都失败了。房地产图像的领域特征太强，一刀切的指令行不通。

结果：成本、准确率和速度

AWS Generative AI Innovation Center 团队用无偏评估框架在 Amazon Bedrock 上评估了多个模型。所有模型都从共享的 v21 提示词起步，再在开发集上针对各自的模型系列做调优。

专有模型 A 只调了一轮，即 v22。Llama 4 Maverick 17B Instruct 则调了多轮，从 v24 到 v27，还加上 Property Finder 的边缘情况规则，背后的调优投入更多。最终与专有模型 A 的对比使用 356 张图像的评估集。Property Finder 根据全部 11 个属性的准确率和成本效率，选择了 Llama 4 Maverick 17B Instruct 用于生产工作负载。各区域的模型可用情况，请参阅 Amazon Bedrock 中的 Supported models by AWS Region。

下表是 Llama 4 Maverick 17B Instruct（v27_PF）在 356 张图像评估集上，每个单标签属性的精确匹配准确率。11 个属性中有 6 个达到 90% 及以上，并且在全部 11 个属性上都达到或超过专有模型 A。照片分类允许一张图像有多个标签，两者得分相同。

每 1,000 张图像的成本

Property Finder 每天要为几万张图像评分，单张成本很关键。Llama 4 Maverick 17B Instruct 是一个性价比高的开放权重模型，而且整条流水线一次调用就能取回一张图像的所有属性。

推理速度

每次迭代相当于进化优化循环中的一代。部署这样的流水线时，要加入负责任的 AI 控制措施。比如可以用 Amazon Bedrock Guardrails 执行内容策略，过滤不合适的模型输出。这条流水线给出的属性预测没有经过校准的置信度分数，所以需要找一个实用信号来判断哪些图像要人工复核。模型分歧就是这样一个信号：当两个模型对某个属性给出不同答案时，这张图像通常本身就有歧义。对每张图像都跑第二个模型会增加成本，所以可以先从抽样开始。在依赖这个信号之前，先检查它在你的开发集上找出真实错误的频率有多高。

查看原文