本文由来自 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张阿联酋(UAE)图像和另一组埃及图像。团队从未标注的生产房源中选取了这些具有代表性细分行业的图像。本文报告的是阿联酋图像上的结果。埃及图像作为对230张图像的跨区域校验,在此不作报告。最先标注的256张阿联酋图像构成了用于调优的开发集。用于最终模型比较的评估集使用全部356张图像,其中包括在开发运行之后标注的100张图像。356张图像的数据集大致足以检测模型之间的中等差异。单个属性中的稀有类别样本较少,因此这些属性上较小的差异可能无法检测出来。
专家标注
一位战略与分析专家对所有图像进行了标注,具备房地产房源质量标准的专业知识。AWS 生成式AI创新中心团队通过专门的澄清会议进行了系统性质量审查。这些审查解决了模棱两可的案例,并保持了整个数据集标注的一致性。
多标签转换
房地产图片经常通过门框展示多个房间,或呈现重叠的质量特征。从单标签分类切换到多标签分类,消除了人工歧义的一个主要来源。
一张通过门框展示卧室的走廊照片确实既是走廊又是卧室。在允许多个标签之后,你衡量的是模型做对了什么,而不是因为它做出的合理次要预测而惩罚它。
一种混合方法可以补充这一方法论:来自不同系列的模型提出候选标签和分歧,由人类专家对每个案例进行裁决,因此任何模型输出都不会被直接用作标签。这将减少未来数据集扩展的标注负担。
指标选择
Micro F1 被用作主要指标,因为它对每个预测的权重相同,这符合整体标签正确性这一业务目标。Macro F1 也一并报告,因为 Micro F1 被高频类别主导,可能掩盖稀有属性上的薄弱表现。逐标签的精确率和召回率帮助识别具体的失败模式。逐样本的交并比(IoU)衡量每张图片的预测标签与专家标签的重叠程度。九个单标签属性(例如旋转或水印检测)每张图片只有一个正确答案。AWS 团队还用精确匹配准确率(即答案与专家标签一致的图片比例)对它们进行评分。
作为强化学习的提示词优化
在建立无偏评估之后,你就可以开始改进了。你无法改进你无法正确衡量的东西。
这一优化遵循一个类似于强化学习的循环。可以把每个提示词版本想象成一个智能体,把 Micro F1 分数想象成奖励信号,把错误分析想象成用于改进的梯度。这个思路类似于 GEPA(Genetic-Pareto reflective prompt evolution),即在 där 中变异提示词组件、评估适应度、选择幸存者并迭代。在本次合作中,AWS 团队的大多数版本都是通过错误分析改进的,由 AI 助手审查失败图片并提出修改建议。
MIPROv2,一个来自 DSPy 库的自动化提示词优化框架,在 v27 中为照片分类任务补充了这一手动流程。
起点
第一个提示词(v0)使用了通用的分类指令,此处为说明目的进行了简化:
“将该图片分类为以下类别之一:客厅(Living Room)、厨房(Kitchen)、卧室(Bedroom)、浴室(Bathroom)……”
专有模型 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 percent 的相对提升。仅提示词调优一项,在 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 Region列出的受支持模型.
下表显示了Llama 4 Maverick 17B Instruct(v27_PF)在每个单标签属性上达到的完全匹配准确率,该准确率在356张图像的评估集上评分得出。它在九个属性中有六个达到90%或更高,并且在全部11个属性上均达到或超过专有模型A。在每张图像可能有多个标签的照片分类上,两者得分相同。
| 属性 | 完全匹配准确率 |
| 旋转检测 | 100% |
| 人物检测 | 97% |
| 带框图像检测 | 97% |
| 水印检测 | 94% |
| 渲染图检测 | 93% |
| 家具配备状态 | 91% |
| 施工中的房间 | 81% |
| 房间大小 | 65% |
| 水印文本提取 | 55% |
每1,000张图像的成本
Property Finder每天对数万张图像进行评分,因此单张图像的成本非常重要。Llama 4 Maverick 17B Instruct是一个具有成本效益的开源权重模型,并且该流水线可通过单次调用获取一张图像的全部属性。
| 结果 | 值 |
| 每1,000张图像的估计成本 | $2.35 |
| 与Property Finder先前设置相比的成本降低幅度 | 86% |
这些数字是截至2025年12月在美国东部(俄亥俄)区域的估算值。Llama 4 Maverick 17B Instruct的数字假设每张图像有9,000个输入令牌和200个输出令牌,来源于最初的双调用成本分析。使用生产提示词的单次调用大约携带7,500–8,000个输入令牌,因此这是一个上限估算。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。