【S3W3 交叉评测】看见下一步：任务语义、安全降级与 Agent 复核闭环建议 #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
1. 项目理解
我理解“看见下一步”是一款面向视障、低视力及其他视觉能力受限人群的多模态行动辅助应用。
用户上传环境图片或使用摄像头拍照，并提出找入口、找商品、识别价格、找收银台或障碍检查等任务。系统调用可配置的远程视觉模型，将模型结果解析为方向、风险、障碍、OCR 和行动提示，再经过本地安全规则处理并进行中文语音播报。
当前架构是“单协调器 + 可插拔视觉模型网关 + 确定性安全守卫”，项目文档也明确说明当前不是多 Agent、不是连续实时导航，并且不能替代导盲杖、导盲犬、无障碍设施或人工帮助。
2. 项目亮点
3. 当前问题和疑点
3.1 “方向未确定”会覆盖价格识别和障碍提醒结果
当前规范化逻辑只要发现
direction == 未确定，就会统一把 action 和 speech 改成“未能确认目标方向，请停下并重新拍摄确认”。这一规则适用于找入口、找商品或找收银台，但不一定适用于：
建议根据 intent 使用不同的必需字段和降级策略，避免一条全局方向规则覆盖其他有效信息。
3.2 JSON 可解析不等于业务 Schema 完整
当前只要能够提取一个 JSON 对象，就会通过默认值补齐字段并返回
status=ok。部分模型输出即使缺少关键字段，也可能被包装成完整结果。建议区分：
可以为
find_entrance、read_price、avoid_obstacle等任务定义不同的 Pydantic Schema。3.3 当前 benchmark 更接近格式检查，而非效果评测
现有脚本主要检查 JSON 是否可解析、是否包含精确距离、intent 是否匹配等。
direction_or_unknown只检查方向字段是否非空，而规范化结果始终会产生方向字段，因此不能证明方向判断正确。建议给固定样例增加人工真值，例如：
汇总指标至少应区分解析率、Schema 完整率、方向正确或合理拒答率、障碍漏报率、高风险优先率和 OCR 人工一致率。
3.4 Agent 属性仍主要依赖单次模型调用
当前每次图片请求相互独立。最值得增加的不是形式上的多 Agent，而是一个最小状态化复核循环：
这会同时增强安全性、用户价值和 W3 阶段的 Agent 完整性。
3.5 项目定位文档需要统一
根目录
PROJECT_PROPOSAL.md仍以 MiniCPM-o 4.5 为核心模型描述，而 README 和 W3 文档已经切换为独立远程视觉模型 API 架构。建议统一当前技术基线，旧方案可以移入历史目录并标注已废弃。4. 优先改进建议
建议优先完成以下三项：
之后再用真实授权图片补齐 benchmark 和人工核对记录。
5. 综合评价
项目选题具有明确社会价值，当前代码也已经形成可运行的应用骨架。尤其值得肯定的是，项目对模型能力、安全责任和当前非多 Agent 状态保持了较诚实的表述。
当前最需要提升的不是增加更多功能，而是让不同任务拥有正确的降级语义，并将“能解析模型输出”进一步推进到“能够验证、复核并谨慎形成行动建议”。完成任务级 Schema 和二次确认循环后，项目的安全可信度和 Agent 完整性都会明显增强。
感谢老师非常细致、专业的评审。您的反馈帮助我们进一步明确了项目当前的技术边界，也指出了从“能够运行”走向“能够验证、复核并谨慎输出”的关键改进方向。
我们认同项目当前最需要提升的不是继续堆叠功能，而是完善不同任务下的安全降级逻辑、任务级结果校验和二次确认机制。
关于方向未知覆盖价格识别和障碍提醒的问题，我们会优先修改安全规范化逻辑。目前“方向未确定”统一触发行动和语音降级，确实可能导致价格、OCR或障碍识别等有效信息被覆盖。后续将按照 intent 分别设计降级策略。
对于找入口、找商品和找收银台等方向依赖较强的任务，如果方向无法确认，将明确提示用户重新拍摄或调整角度。对于价格识别和文字识别，只要文本结果可靠，即使方向未知，也会保留并播报识别结果。对于障碍提醒，即使无法判断具体方向，只要识别到台阶、车辆、玻璃门等潜在风险，也会优先播报风险信息，并明确说明位置和方向暂时无法确认。对于不依赖方向的一般辅助问题，也不会再使用统一的方向失败逻辑。
关于 JSON 可解析但业务 Schema 不完整的问题，我们会将当前的结果状态进一步拆分为 parsed、validated、degraded 和 rejected 四类。parsed 表示成功提取 JSON，但不代表结果已经满足业务要求；validated 表示满足当前任务所需字段和安全条件；degraded 表示可以提供有限信息，但存在关键字段缺失或不确定；rejected 表示无法形成安全、可信的结果，需要重新拍摄或寻求人工帮助。
同时，我们会针对 find_entrance、read_price、avoid_obstacle 等不同 intent 定义独立的任务级 Schema，并根据任务分别设置必需字段。例如，价格识别重点检查 OCR 文本和价格结构；障碍提醒重点检查障碍类别、风险等级和可确认程度；寻找入口则重点检查方向、相对位置和目标可见性。默认值不会再简单地把缺少关键字段的结果包装成 status=ok。
关于 benchmark 更接近格式检查而不是效果评测的问题，我们也完全接受。后续会为固定样例补充人工真值，包括可接受方向集合、主要障碍类别、最低风险等级、OCR 关键文本以及是否允许返回“未确定”等信息。
评测指标也会从单纯的 JSON 解析率扩展为解析率、Schema 完整率、方向正确率或合理拒答率、障碍漏报率、高风险优先率和 OCR 人工一致率。对于暂时无法可靠判断的样例，我们会把“正确拒答”与“错误猜测”明确区分，避免只通过字段是否为空来判断系统效果。
关于 Agent 属性的问题，我们同意最有价值的方向不是为了形式拆分出多个 Agent，而是增加一个最小化的状态化复核流程。后续计划引入“首次识别—风险和置信度判断—提示用户调整拍摄—接收第二张图片—对比前后结果—最终确认或继续拒答”的流程。
当首次识别出现低置信度、高风险、方向未知或目标被遮挡时，系统会明确告诉用户如何调整拍摄，例如靠近目标、改变角度、保持画面稳定或扩大目标范围。第二次识别后，系统会对比两次结果。如果结果趋于一致，则输出更谨慎的确认结果；如果前后结果冲突，则继续提示无法可靠判断，而不是强行选择其中一个结果。这一机制可以同时提升安全性、用户体验和项目的 Agent 特征。
关于项目技术文档不一致的问题，我们会统一当前技术基线。README、W3 文档和 PROJECT_PROPOSAL.md 将统一描述为“单协调器＋可插拔远程视觉模型网关＋确定性安全守卫”的架构。MiniCPM-o 4.5 方案将移入历史方案或废弃方案目录，并标注当前不作为主要技术基线，避免评审和使用者对项目模型架构产生误解。
我们计划按照以下优先级推进：
第一，修复按 intent 处理的安全规范化逻辑，避免方向未知覆盖价格识别和障碍提醒。
第二，引入任务级 Schema，并区分 parsed、validated、degraded 和 rejected 状态。
第三，补充识别、要求复拍、二次确认的状态化流程。
第四，基于真实授权图片补充 benchmark、人工真值和误差记录。
第五，统一项目文档、README和W3阶段材料中的技术架构描述。
再次感谢老师对项目边界、安全责任和实际工程质量的关注。我们会继续保持项目对模型能力的诚实表述，不把当前系统包装成实时导航或多 Agent 系统。下一阶段的重点将从“能够调用模型并展示结果”，进一步推进到“能够根据不同任务进行校验、复核、拒答，并在安全边界内形成可执行的信息提示”。