修复评测偏差：Property Finder 如何在 Amazon Bedrock 上选出更优模型

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

数字房地产应用 Property Finder 的工程团队发现，他们的评估标签中有 96.8% 直接沿用了单一模型的预测结果，而非由人类专家验证。他们的真实基准被系统性地偏向现有模型，使得每一种替代方案都显得表现不佳。这些标签也存在错误，但真正阻碍客观模型比较的是这种偏差。他们是在将视觉 AI 工作负载迁移到 Amazon Bedrock 上更具成本效益的选项时发现这一点的。

Property Finder 每天在中东和北非（MENA）地区处理数万张房产图片。他们的系统对每张图片评估 11 项质量属性，涵盖水印检测、房间分类、家具状态、照片质量和建筑指标。这意味着每天有数千条新房源，每条平均包含 15 张图片，全部需要在发布前进行质量评估。

Property Finder 需要一个更具成本效益的选项。但以那些标签为基准来衡量，任何替代方案都处于劣势。

最难的部分不是找到更好的模型，而是发现他们的评估方法本身就是障碍。

在本文中，我们分享 Property Finder 如何识别评估偏差、构建无偏的真实基准，并应用进化式提示优化在 Amazon Bedrock 上选择合适的模型，从而以低 86% 的成本实现了更高的准确率。我们将逐步介绍方法和迭代示例，其中的经验教训可应用于您自己的工作负载。

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

图 1：提示优化循环架构

该图展示了迭代式提示优化循环。一张房产图片由 Amazon Bedrock 处理，输出 JSON 格式的预测属性。在优化过程中，这些预测结果会与包含 256 张图片的专家标注开发集进行 Micro F1 评分对比。随后，错误分析会检查失败的图片并识别视觉模式，为下一个提示版本提供依据。该循环从 v0 运行到 v27。AI 助手帮助改进提示，后续版本使用了自动化优化。

你的评估可能在说谎

许多团队都会遇到这种情况。你想比较视觉模型，于是构建了一个评估数据集。获取标签最常见的方式是运行你当前的模型，并将其输出视为真实基准。该模型已在生产环境中运行，没有人抱怨，所以标签应该足够好。

但这会造成循环评估：任何替代方案都是按其与现有模型行为的接近程度来评判，而非按实际正确性来评判。

Property Finder 的评估数据集恰恰存在这个问题。在他们标注的样本中，96.8% 直接来自现有视觉语言模型（VLM）的预测，而非独立的人工验证。任何替代模型在哪怕处理一张图片之前，就已经在结构上处于劣势。

隐藏的错误证实了严重性。水印文本提取存在字符级错误却被标记为正确，包括幻觉出的品牌名和缺失字符。照片分类将单一标签强加于包含多种房间类型的图像上。

在剩余 3.2% 的人工标注样本中，标注者引入了原始规范之外的类别，例如在提示中不存在该标签的地方出现了 Office。当答案键由你试图替换的模型编写时，模型比较就失去了有效性。

构建可信的基准真值

为了打破这一循环，你需要具备真实领域知识的人类专家独立进行全新标注。不参考先前的模型输出。不接触现有模型的预测结果。

数据集范围

Property Finder 的团队手工标注了 356 张阿联酋图像和一组单独的埃及图像。团队从具有代表性的行业细分中，从未标注的生产列表中选取了这些图像。本文报告的是阿联酋图像上的结果。埃及图像作为跨区域检查，共 230 张，此处不予报告。首批标注的 256 张阿联酋图像构成了用于调优的开发集。最终模型比较的评估集使用全部 356 张，增加了开发运行后标注的 100 张图像。356 张图像的集合大致足以检测模型之间的中等差异。单个属性内的稀有类别样本较少，因此这些属性上的较小差异可能无法检测到。

专家标注

一位战略与分析专家标注了所有图像。他们带来了房地产列表质量标准方面的专业知识。AWS 生成式 AI 创新中心团队通过专门的澄清会议进行了系统性质量审查。这些审查解决了模糊案例，并保持了整个数据集标注的一致性。

多标签过渡

房地产图像经常通过门洞展示多个房间，或呈现重叠的质量特征。从单标签到多标签分类的转变缓解了一个主要的人为歧义来源。

一张通过门洞展示卧室的走廊照片确实两者兼具。在允许多个标签后，你衡量的是模型做对了什么，而不是因合理的次要预测而惩罚它。

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

指标选择

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

将提示优化视为强化学习

有了无偏评估，你就可以开始改进了。你无法改进你无法正确衡量的东西。

优化遵循一个类似于强化学习的循环。把每个提示版本看作一个智能体，把 Micro F1 分数看作奖励信号，把错误分析看作改进的梯度。这一思路类似于 GEPA（Genetic-Pareto reflective prompt evolution），即对提示组件进行变异、评估适应度、选择幸存者并迭代。在这次合作中，AWS 团队通过错误分析改进了大多数版本，由 AI 助手审查失败的图像并提出修改建议。

MIPROv2 是 DSPy 库中的自动化提示优化框架，它在 v27 中为照片分类任务补充了这一手动流程。

起点

第一个提示（v0）使用了通用分类指令，此处为便于说明做了简化：

“将这张图像分类为以下类别之一：Living Room、Kitchen、Bedroom、Bathroom……”

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

逐次迭代

AWS 团队在多个候选模型上测试了早期版本，并添加了结构化输出格式和属性专属定义。

最具启发性的修复来自图像级错误分析。在早期的单标签版本中，模型总是将通过门洞可见的房间分类为次要房间类型。AWS Generative AI Innovation Center 团队添加了明确指令，要求根据占据画面大部分区域的房间进行分类。后来切换到多标签输出后，主房间仍作为一个标签保留，并允许将通过门洞可见的房间作为附加标签。

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

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 一样，它保留了阿拉伯文字规则和输出格式指令。每次模型调用后的归一化步骤处理剩余的格式差异。

借助 v27_PF，Llama 4 Maverick 17B Instruct 在 356 张图像的评估集上取得了 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。

失败方法的经验教训

并非一切都成功。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 中按 AWS 区域支持的模型。

下表显示了 Llama 4 Maverick 17B Instruct（v27_PF）在 356 张图像评估集上对每个单标签属性达到的精确匹配准确率。它在九个属性中的六个上得分达到或超过 90%，并在所有 11 个属性上达到或超过专有模型 A。在每张图像可能有多个标签的照片分类上，两者得分相同。

每 1,000 张图像成本

Property Finder 每天处理数万张图像，因此每张图像的成本很重要。Llama 4 Maverick 17B Instruct 是一个具有成本效益的开放权重模型，并且该流水线通过一次调用即可获取图像的所有属性。

这些数字是截至 2025 年 12 月在美国东部（俄亥俄）区域的估计值。Llama 4 Maverick 17B Instruct 的数字假设每张图像 9,000 个输入 token 和 200 个输出 token，来自最初的双调用成本分析。使用生产提示词的单次调用大约包含 7,500–8,000 个输入 token，因此这是一个上限估计。86% 是与 Property Finder 之前设置（使用 v21 提示词）的成本分析估计值相比。准确率比较使用的是从 v21 调优而来的 v22，因此其成本可能不同。有关当前定价，请参阅 Amazon Bedrock 定价。

推理速度

Property Finder 在生产环境中运行这条优化后的流水线，每天使用 Amazon Bedrock 上的 Llama 4 Maverick 17B Instruct 处理数万张图像。根据其自身的监控，Property Finder 观察到推理延迟相比之前的设置降低了 40–60%。

将此应用于你的工作负载

首先审计你的评估标签。如果它们来自模型预测而非人类专家，你就存在与 Property Finder 发现的相同的偏差问题。

为几百个代表性样本构建领域专家真值，并保留一个从不用于调优的独立测试集。当你的分类任务涉及重叠属性时，采用多标签指标。然后使用图像错误分析迭代提示词，将每次迭代视为进化优化循环中的一代。

当你部署这样的流水线时，要加入负责任的 AI 控制措施。例如，你可以使用 Amazon Bedrock Guardrails 来执行内容策略并过滤不当的模型输出。这条流水线中的属性预测不附带经过校准的置信度分数，因此请使用一个实用信号来选择图像进行人工审核。模型分歧就是这样一个信号。当两个模型对某个属性给出不同答案时，该图像往往存在歧义。对每张图像都运行第二个模型会增加成本，因此你可以从样本开始。在依赖该信号之前，先检查它在你的开发集上捕获真实错误的频率。

结论

在本文中，我们介绍了 Property Finder 如何识别评估偏差、构建无偏真值，并应用进化式提示词优化，通过 Amazon Bedrock 上的模型选择以更低成本实现更高准确率。

这一结果需要三个要素共同作用：无偏评估以诚实地衡量，能够在不重新搭建平台的情况下评估和切换模型系列的灵活性，以及针对该领域精心进化出的提示词。Amazon Bedrock 提供了基础。它通过单一 API 让 Property Finder 能够访问多个模型系列，继承了 AWS 治理和安全控制，并能够在无需更改其基础设施的情况下采用新推出的模型。

要开始在 Amazon Bedrock 上进行模型评估和选择，请访问 Amazon Bedrock 文档。如果你大规模处理视觉工作负载并希望获得构建无偏评估框架的帮助，请联系 AWS 生成式 AI 创新中心。

欢迎在评论中分享你在模型评估和提示词优化方面的经验。

致谢

来自 AWS 的其他贡献者包括 Yousuf Albannai、Amine Sehili、Thomas Ounnas、Aris Tsakpinis、Rafik Soliman、Nikhil Ulhas Pandit 和 Sneh Sharma。

关于作者

Khaled Thabit

Khaled Thabit 是 Property Finder 的数据工程总监，负责领导公司的数据和 AI 战略。他热衷于利用 AI 和数据塑造中东和北非地区房地产市场的未来。

Meriem Boughrara

Meriem Boughrara 是 Property Finder 的高级数据工程师，负责领导平台上的 AI 和数据工程计划。她监督 AI 驱动解决方案的项目交付，并与跨职能团队密切合作，将其投入生产。

Mohamed Desouky

Mohamed Desouky 是 Property Finder 的数据工程师，负责构建和维护数据管道，为 MENA 各市场由 AI 驱动的房源质量系统提供支持。他热衷于构建可扩展的数据解决方案，以推动可衡量的业务影响。

Mina Metias

Mina Metias 负责管理 MENA 地区的 AWS 生成式 AI 创新中心团队，监督从探索到生产部署的客户合作，并支持交付可衡量的业务成果。

Vadim Selyutin

Vadim Selyutin 是 AWS 生成式 AI 创新中心的高级数据科学家。他在客户合作中提供技术领导，与各组织合作，从构思到生产部署设计、构建并交付生成式 AI 解决方案。

Mohamed Noordeen Alaudeen

Mohamed Noordeen Alaudeen 是 AWS 生成式 AI 创新中心的数据科学家，负责构建和部署生成式 AI 解决方案，为各行业的企业客户解决现实世界的业务问题。他乐于应对复杂的技术挑战，并将其转化为可投入生产的解决方案。