Property Finder 如何修正 Amazon Bedrock 上的评测偏差并换用 Llama 4 Maverick

问题出在评测集本身

Property Finder 是一家覆盖中东北非地区的数字房产应用，每天处理数万张房源图片，每张图要判断 11 项质量属性，包括水印检测、房间分类、装修状态、照片质量和施工迹象。在把视觉 AI 负载迁移到 Amazon Bedrock 上更具成本效益的方案时，团队发现了一个更根本的障碍：评测数据集中 96.8% 的标签直接沿用了现有视觉语言模型的预测结果，而非人工专家核验。

这形成了一个循环评测。任何替代模型都是按“与旧模型输出有多接近”来打分，而不是按“判断是否正确”来打分。剩余 3.2% 的人工标签也存在问题，例如标注者引入了原始规范之外的类别。水印文字提取中还有字符级错误被标为正确，包括虚构的品牌名和缺失字符。

重建可信的基准

团队的做法是由具备房产挂牌质量标准的专家重新独立标注，不参考任何旧模型输出。他们手工标注了 356 张阿联酋图片，另有一组埃及图片用于跨区域检查，本文只报告阿联酋结果。前 256 张构成调优用的开发集，全部 356 张用于最终模型比较。原文说明，356 张大致足以检测模型间的中等差异，但单个属性中的稀有类别样本较少，这些属性上的小差异可能无法检出。

同时，照片分类从单标签改为多标签。房源图片常通过门洞同时呈现多个房间，单标签会制造人为歧义。指标以 Micro F1 为主，辅以 Macro F1、各标签的精确率与召回率，以及逐样本 IoU；九个单标签属性另用完全匹配准确率衡量。

提示词迭代与结果

优化过程被比作强化学习：每个提示词版本视为智能体，Micro F1 是奖励信号，错误分析是改进方向。团队从 v0 迭代到 v27，多数版本由 AI 助手辅助分析失败图片后人工修改，v27 在照片分类任务上使用了 DSPy 库中的 MIPROv2 自动优化。关键改进包括：要求按占据画面主体的房间分类，以及针对部分地区的装饰性阿拉伯文字叠加制定规则，消除一类误报。

最终提示词 v27_PF 在 356 张评测集上让 Llama 4 Maverick 17B Instruct 取得 0.80 的 Micro F1，而原专有模型 A 为 0.56。原文明确提示，评测集包含调优用过的 256 张图片，两个模型的提示词都在其上调过，因此这些分数偏乐观。在开发集上，换模型加各自调优提示词使 Micro F1 从 0.55 升至 0.81，相对提升 47%。成本方面，原文给出每千张图片约 2.35 美元的估算，较原方案降低 86%，并注明这是 2025 年 12 月美国东部（俄亥俄）区域的估算值，且输入 token 按 9,000 计属于上限估计。Property Finder 自述其监控显示推理延迟下降 40% 至 60%。

失败尝试也值得记录：把水印属性和其他属性拆成两次 API 调用没有带来明显精度收益，反而使带边框图片检测明显下降；通用提示词在任何模型上都不理想。

编辑部观察

这份复盘的价值不在某个模型胜出，而在揭示了一个容易被忽略的前提：如果答案键由待替换的模型写成，模型比较就失去意义。原文也坦承了方法边界，包括评测集与调优集重叠、样本量对稀有类别的限制，以及成本数字的估算口径。

实践建议

读者可以先审计自己的评测标签来源，若主要来自模型预测，就存在同样的偏差。可参照原文路径：由领域专家标注数百张有代表性的样本，保留一份从不用于调优的测试集，对存在重叠属性的分类任务采用多标签指标，再以错误分析驱动提示词迭代。原文还建议在部署时加入 Amazon Bedrock Guardrails 等控制措施，并用模型分歧作为挑选人工复核样本的信号，但需先在开发集上验证该信号的命中情况。