你何时需要它
手动记录食物是良好营养习惯的终结之处。以传统方式记录一盘咖喱鸡，用户需要搜索“咖喱鸡”，滚动列表，猜测份量，并对盘中的每种食物重复此操作。这在理论上是准确的，但在实践中却被抛弃——操作的摩擦远大于其带来的动力。
摄像头可以简化所有这些操作。将手机对准一顿饭，几秒钟后，带有完整营养信息的匹配食谱就准备好记录了。当数据捕获是用户与您的产品价值之间的障碍时——当“只需拍张照片”可以取代多步骤手动输入时，这种模式就有了用武之地。这类问题恰好位于 MicrocosmWorks 的 AI 开发服务 所涵盖的领域：将一个技术上可行的模型转化为一个能够消除实际摩擦的管道。
模式概述
一张照片通过四个阶段成为一份已记录、已量化的膳食：
- 捕获 (Capture) — 拍摄照片或选择图像；在上传前在设备上进行优化。
- 识别 (See) — 视觉模型识别菜肴，以排名搜索词而非原始标签的形式表达。
- 匹配 (Match) — 这些术语驱动食谱搜索，其排名继承了模型的置信度。
- 记录 (Log) — 用户选择一个食谱，查看食材和营养信息，选择数量，然后保存。
关键思想是：视觉和搜索不是相互独立、拼凑在一起的系统。视觉模型被提示以精确生成搜索引挚所需的内容，而搜索引挚信任模型生成的顺序。“我们展示的”与“照片中的”之间的区别消失了。
参考架构
捕获，设备端优化。图像在上传前会被调整为约 512 像素宽，并压缩至约 40% 的 JPEG 质量——视觉 API 有严格的尺寸上限，而原始手机照片很容易超出这些限制。服务器强制执行 2MB 的上限作为备用保障。
识别：模型生成搜索。图像被发送到 GPT-4o。提示要求提供五个可搜索的食谱名称，从置信度最高到最宽泛的备选顺序排列——命名菜肴整体，而非其配料——而不是“这是什么食物？”。例如，一个汉堡会返回：
["cheeseburger", "beef burger", "cheese burger", "hamburger", "burger"]匹配：置信度转化为相关性。这五个名称作为一次“匹配任意”搜索针对 Elasticsearch 食谱索引运行，每个名称都带有位置加权提升（从 50 倍递减到 5 倍）。标题为 Cheeseburger 的食谱会比普通的 Burger 排名更高，这不是基于文本统计，而是因为模型更具置信度。五个或匹配的术语意味着用户几乎总能看到一些结果；这些提升会将最佳猜测推到顶部。
记录：从食谱卡到量化膳食。食材——以纯文本、精选参考和外部 FatSecret 参考的形式存储——被标准化为一个简洁的列表。用户选择单位和数量；卡路里和宏量营养素会即时计算，然后该膳食会保存到他们的日志中。
原始食材的第二条路径。当没有菜肴可供搜索时，一个专用的食物识别 API 会直接返回营养信息——这比通用视觉模型更经济且更适合。应用程序根据意图进行路由。
设计决策与权衡
将模型提示为下一个系统的输入格式。排名靠前、可搜索的名称——而非自由形式的标签——使交接清晰。提示是契约的一部分；我们将其视为代码，而非文案。
广撒网胜过单一最佳猜测。五个或匹配的术语大大减少了“未找到结果”的情况，代价是列表下方偶尔会出现一些关联不大的结果。
在图像所在位置进行优化。设备端压缩节省了上传时间并避免了 API 限制，代价是引入了一个小的客户端依赖——为了实际的移动可靠性，这是值得的。
合适的模型，合适的任务。通用视觉模型擅长识别“这是什么菜？”，但对于“这个苹果有多少卡路里？”来说则是大材小用。两条路径可以控制成本并改善结果。
诚实地降级。如果没有检测到，也没有匹配到——应用程序会明确告知用户，并提供手动搜索选项，而不是假装或中断流程。
速率限制、上传上限和优雅降级等防护措施只有在底层基础设施为此而构建时才有效——这正是 MicrocosmWorks 的云基础设施服务 旨在提供的基础。
何时使用它——以及何时避免它
当手动捕获是真正障碍时，当一张照片可以替代多步骤输入时，当您拥有可供匹配的目录时，以及当“足够好，立即可用”胜过“完美，最终达成”时，请使用此模式。当领域需要实验室级别的准确性时，当没有目录可供匹配时，当视觉 API 成本高于所获得的参与度时，或者当输入在视觉上过于模糊而无法可靠识别时，请避免使用它。
我们的方法
对于计算机视觉，本能是追求一个能够完美命名食物的模型。但真正的优势在于其他地方：在于视觉输出如何连接到所有下游系统。提示模型以搜索引挚的语言进行“交流”，让其置信度成为排名依据，并在幕后规范化各种混乱——整个过程就简化为几次点击。胜利不在于更智能的分类器；而在于一个无缝的管道。
正在构建类似的东西？探索 MicrocosmWorks 的 AI 代理解决方案 或 联系我们 讨论您的管道架构。
其他博客
3. 同步 Apple Health 与 Health Connect
