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 反思式提示词进化）：对提示词组件进行变异、评估适应度、选择幸存者并迭代。在这次合作中，AWS 团队的大部分版本都是从错误分析中改进而来的，由 AI 助手审查失败的图片并提出修改建议。

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

起点

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

“将此图片分类到以下类别之一：客厅（Living Room）、厨房（Kitchen）、卧室（Bedroom）、浴室（Bathroom）……”

专有模型 A 是 Property Finder 的生产基线，在 256 张图片的开发集上 Micro F1 得分为 0.55。它使用 v22，一个针对其模型系列调优过的提示词。v21 之前的分数采用早期的单标签设置，不具备直接可比性。

逐次迭代

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

最有启发性的修复来自图片级别的错误分析。在早期的单标签版本中，模型总是将通过门口看到的房间分类为次要房间类型。AWS 生成式 AI 创新中心团队加入了明确的指令，要求根据占据画面主要部分的房间进行分类。后来切换到多标签输出时，保留了主房间作为标签，并允许将通过门口看到的房间作为附加标签。

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

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 生成式 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 发现的相同的偏差问题。

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

当您部署这样的流水线时，请添加负责任的 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。

关于作者