Property Finder 如何修正 Amazon Bedrock 上的评估偏差，选出更优模型

Property Finder 是一家覆盖中东和北非的数字房产应用，每天处理数万张房源图片，每张图片需评估 11 项质量属性，包括水印检测、房间分类、装修状态、照片质量和施工迹象。在把视觉 AI 负载迁移到 Amazon Bedrock 上更具成本效益的方案时，团队发现自己的评估体系本身才是最大障碍：96.8% 的评估标签直接继承自现有模型的预测，而非人工专家核验，任何替代模型在比较前就已被结构性压低分数。 标签中还藏着错误，例如水印文字提取存在字符级错误却被标为正确，包括虚构品牌名和缺字；照片分类把多房间图片强行压成单一标签；在仅占 3.2% 的人工标注样本里，标注者还引入了原始规范之外的类别。团队由此重建可信基准：由具备房产挂牌质量标准的专家独立标注 356 张阿联酋图片，其中前 256 张作为调优开发集，全部 356 张用于最终评估，另有 230 张埃及图片作跨区域校验。同时把单标签改为多标签分类，避免把门后可见房间等合理预测当作错误惩罚。 优化流程类似强化学习：每个提示词版本视为智能体，Micro F1 为奖励信号，错误分析作为改进梯度，整体思路接近 GEPA，并在 v27 中借助 DSPy 的 MIPROv2 自动优化照片分类任务。循环从 v0 跑到 v27，早期通过图像级错误分析加入“按占据画面主体的房间分类”等规则，并针对部分地区的装饰性阿拉伯文字叠加制定规则以减少误报。 v21 提示词把照片分类和房间类别改为多标签输出，成为所有模型的共享起点，Llama 4 Maverick 17B Instruct 在该提示词下开发集 Micro F1 为 0.75。此后针对该模型单独调优，v24 处理房间面积高估、多标签和输出格式，v25 自动优化把关键任务前置，v27 的照片分类任务 Micro F1 达到 0.76。最终 v27_PF 加入渲染图、带边框图片和走廊规则，并保留阿拉伯文字规则与输出格式指令，每次模型调用后做归一化处理。 在 356 张评估集上，v27_PF 下 Llama 4 Maverick 17B Instruct 的 Micro F1 为 0.80，而专有模型 A 使用 v22 为 0.56；由于评估集包含调优用的 256 张图片，这些分数偏乐观。开发集上两者各自使用调优提示词时，Micro F1 从 0.55 提升到 0.81，相对提升 47%。Property Finder 最终基于 11 项属性的准确率和成本效率选择 Llama 4 Maverick 17B Instruct，实现准确率提升的同时成本降低 86%。失败尝试也值得注意：把水印属性与其他属性拆成两次 API 调用的双桶方案没有带来明显收益，还导致带框图片检测准确率大幅下降；通用提示词在房产图像上同样效果不佳。