本文由 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 的迭代。人工智能助手协助完善了提示内容，而后续版本则采用了自动化优化方法。
您的评估可能是错误的
许多团队都会遇到这种情况：你想比较不同的视觉模型，于是构建了一个评估数据集。获取标签的最常见方法，是运行你当前的模型，并将其输出视为真实值。该模型已经在生产环境中运行过，且无人提出异议，因此这些标签应该足够可靠。
但这就导致了一种循环评估：任何替代方案都只能以其与现有方案行为的相似程度来评判，而非依据其实际的正确性。
Property Finder 的评估数据集就存在这一问题。在其标注样本中，96.8% 直接来自现有视觉语言模型（VLM）的预测结果，而非经过独立的人工验证。在任何图像尚未被处理之前，任何替代模型就已经处于结构上的不利地位。
隐藏的错误证实了问题的严重性。水印文本提取在字符级别上存在错误，却被标记为正确，其中包括凭空捏造的品牌名称和缺失的字符。照片分类则强制为包含多种房型的图像赋予单一标签。
在剩余的3.2%由人类标注的样本中，标注者引入了原始规范之外的类别，例如在提示中不存在“Office”这一标签的情况下，标注者却将其归入该类别。当答案标准是由你试图替换的模型生成时，模型比较便失去了有效性。
构建您可信赖的真实数据
要打破这一循环，你需要具备真正领域知识的人类专家独立进行新的标注。不得参考先前模型的输出，也不得访问现有系统所作出的预测。
数据集范围
Property Finder 的团队对 356 张阿联酋地区的图像以及另一组埃及地区的图像进行了人工标注。这些图像均取自各具代表性的行业细分领域的未标注房源列表。本文仅报告阿联酋地区图像的实验结果，而埃及地区的图像则作为跨区域的对照，共包含 230 张图像，此处不予赘述。在首批待标注的 256 张阿联酋图像中，有 256 张被用作模型调优的开发集。用于最终模型对比的评估集则涵盖全部 356 张图像，并额外增加了 100 张在开发阶段结束后标注的图像。总体而言，356 张图像的规模大致足以检测出模型之间的中等程度差异。然而，由于单个属性中的稀有类别样本数量较少，因此在这些属性上可能难以察觉更细微的差异。
专家标注
一位战略与分析专家对所有图像进行了标注。他们具备房地产房源质量标准方面的专业知识。AWS生成式AI创新中心团队通过专门的澄清会议开展了系统性的质量审核，这些审核解决了存在歧义的情况，并确保了整个数据集的标注一致性。
多标签转换
房地产图片经常通过门洞展示多个房间，或呈现相互重叠的品质特征。从单标签分类转向多标签分类，有效缓解了人为歧义的主要来源。
一张走廊照片透过门框展示了一间卧室，这确实同时具备两种特征。在允许使用多个标签后，您衡量的是模型的正确预测，而不是因为它做出了合理的次要预测而对其进行惩罚。
一种混合方法可以补充这一方法：来自不同模型族的模型会输出候选标签及意见分歧，由人类专家对每个案例进行裁决，因此不会直接将任何模型的输出用作标签。这将减轻未来数据集扩展时的标注负担。
指标选择
Micro F1 被用作主要指标，因为它对每项预测赋予同等权重，这与整体标签正确性的业务目标相一致。同时报告了 Macro F1，因为 Micro F1 容易被高频类别所主导，从而掩盖了稀有属性上的薄弱表现。逐标签的精确率和召回率有助于识别具体的失败模式。逐样本的交并比（IoU）用于衡量每张图像的预测标签与专家标签之间的重叠程度。九个单标签属性，例如旋转检测或水印检测，每张图像都只有一个正确答案。AWS 团队还以完全匹配准确率对其进行评分，即答案与专家标签完全一致的图像所占比例。
作为强化学习的提示优化
在建立公正的评估机制后，您就可以着手改进了。无法正确衡量的事物，也就无从改进。
该优化过程遵循一种与强化学习类似的循环。可以将每个提示版本视为一个智能体，将微F1分数视为奖励信号，而将错误分析视为改进的梯度。这一思路类似于GEPA（基于遗传—帕累托的反思式提示进化），即通过变异提示组件、评估适应度、选择优胜者并不断迭代。在本次实践中，AWS团队主要依据错误分析对多数版本进行了优化，由AI助手审阅失败的图像并提出改进建议。
MIPROv2 是 DSPy 库中的一个自动提示优化框架，在 v27 中为照片分类任务补充了这一手动流程。
它从哪里开始
第一个提示（v0）使用了通用的分类指令，此处为便于说明而予以简化：
“请将这张图片归类为以下类别之一：客厅、厨房、卧室、浴室……”
专有模型A——Property Finder的生产基准——在256张图像的开发集上取得了0.55的微F1分数。该模型使用了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 张图像的评估集上取得了 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张图像的评估集上，针对每个单标签属性所达到的精确匹配准确率。在九个属性中，有六个的准确率达到了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 相同的偏见问题。
为几百个具有代表性的样本构建领域专家标注的真值，并保留一个独立的测试集，该测试集在调优过程中绝不使用。当分类任务涉及属性重叠时，采用多标签评估指标。随后，通过图像错误分析迭代优化提示，将每一次迭代视为进化优化循环中的一次生成过程。
当您部署此类流水线时，请添加负责任的人工智能控制措施。例如，您可以使用 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。
关于作者