Property Finder 如何修正 Amazon Bedrock 上的评估偏差，以 86% 更低成本选出更优视觉模型

本文由 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）使用了通用的分类指令，此处为便于说明做了简化：

“将这张图像分类为以下类别之一：客厅、厨房、卧室、浴室……”

专有模型 A 是 Property Finder 的生产基线，它在 256 张图像的开发集上取得了 0.55 的 Micro F1。它使用的是 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 一样，它保留了阿拉伯文字规则和输出格式指令。每次模型调用后的归一化步骤处理剩余的格式差异。

借助 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 生成式 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 张图像评估集上对每个单标签属性达到的精确匹配准确率。在九个属性中有六个达到 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 提供了基础。它让 Property Finder 通过单一 API 访问多个模型系列，继承了 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 的数据工程师，负责构建和维护数据管道，为覆盖中东北非市场的 AI 驱动房源质量系统提供支持。他热衷于构建可扩展的数据解决方案，以推动可衡量的业务影响。

Mina Metias

Mina Metias 负责管理 AWS 生成式 AI 创新中心中东北非地区团队，统筹客户合作项目从需求发现到生产部署的全过程，并支持实现可衡量的业务成果。

Vadim Selyutin

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

Mohamed Noordeen Alaudeen

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