こんな時におすすめ
手作業による食事記録は、良い栄養習慣が失われる原因となります。昔ながらの方法でチキンカレーを一皿記録するには、ユーザーは「チキンカレー」を検索し、リストをスクロールし、摂取量を推測し、皿にある全ての品目についてこれを繰り返します。理論上は正確でも、実際には利用されません。手間がモチベーションを上回ってしまうからです。
カメラを使えば、全てをショートカットできます。食事にスマートフォンを向けるだけで、数秒後には栄養情報が完全に揃ったレシピが記録できる状態になります。このパターンは、データ取得がユーザーと製品の価値の間の障壁となっている場合にその真価を発揮します。つまり、「写真を撮るだけ」で多段階の手動入力を置き換えられるような状況です。これは、MicrocosmWorksのAI開発サービスがまさに得意とする領域の問題です。技術的に優れたモデルを、実際の手間を解消するパイプラインに変えることです。
パターンの概要
写真が記録され、定量化された食事となるまでの4つの段階です。
- キャプチャ — 写真を撮るか、画像を選択します。アップロード前にデバイス上で最適化します。
- 認識 — ビジョンモデルが料理を識別します。生ラベルではなく、ランク付けされた検索語として表現されます。
- マッチング — それらの検索語がレシピ検索を駆動し、モデルの信頼度がランキングに反映されます。
- 記録 — ユーザーはレシピを選択し、材料と栄養情報を確認し、量を指定して保存します。
重要なアイデアは、ビジョンと検索が別々のシステムとして結合されているわけではないということです。ビジョンモデルは、検索エンジンが求めるものを正確に生成するようにプロンプトされ、検索エンジンはモデルが生成する順序を信頼します。「表示するもの」と「写真にあるもの」の区別はなくなります。
リファレンスアーキテクチャ
デバイス上で最適化されたキャプチャ。 画像はアップロード前に幅約512pxにリサイズされ、約40%のJPEG品質に圧縮されます。ビジョンAPIには厳格なサイズ制限があり、スマートフォンの生の写真はそれをはるかに超えてしまいます。サーバーはバックストップとして2MBの上限を課します。
認識：モデルが検索を記述。 画像はGPT-4oに送られます。プロンプトは、「これは何の食べ物ですか？」ではなく、最も確信度の高いものから最も広範なフォールバックまで、料理全体（トッピングではなく）を命名した検索可能なレシピ名を5つ要求します。ハンバーガーは次のように返されます。
["cheeseburger", "beef burger", "cheese burger", "hamburger", "burger"]マッチング：確信度が関連性になる。 5つの名前は、Elasticsearchレシピインデックスに対して1つの「match-any」検索として実行され、それぞれに位置加重ブースト（50倍から5倍まで）が適用されます。Cheeseburgerというタイトルのレシピは、一般的なBurgerよりも、テキスト統計からではなく、モデルの確信度が高かったために上位にランクされます。5つのORマッチされた用語があることで、ユーザーはほとんど常に何らかの結果を目にします。ブーストは最も良い推測をトップに押し上げます。
記録：レシピカードから定量化された食事へ。 材料は、プレーンテキスト、厳選された参照、および外部のFatSecret参照として保存され、1つのクリーンなリストに正規化されます。ユーザーは単位と量を指定し、カロリーとマクロがその場で計算され、食事がログに保存されます。
生食材用の第2トラック。 検索する料理がない場合、専用の食品認識APIが栄養情報を直接返します。これは汎用ビジョンモデルよりも安価で適しています。アプリは意図に基づいてルーティングします。
設計上の決定とトレードオフ
モデルを次のシステムの入力形式にプロンプトする。 自由形式のラベルではなく、ランク付けされた検索可能な名前が引き渡しをクリーンにします。プロンプトは契約の一部であり、コピーとしてではなくコードとして扱います。
広範な網羅が単一の最善の推測に勝る。 5つのORマッチされた用語により、「結果が見つかりません」が劇的に減少し、その代償としてリストの下位に時折関連性の低い結果が表示されることがあります。
画像は存在する場所で最適化する。 デバイス上での圧縮はアップロード時間を節約し、API制限を回避します。これは小さなクライアントサイド依存関係を伴いますが、現実世界のモバイルの信頼性のためには価値があります。
適材適所のモデル。 汎用ビジョンモデルは「これは何の料理ですか？」という質問には優れていますが、「このリンゴに何カロリー含まれていますか？」という質問には過剰です。2つのトラックにより、コストを抑えつつ結果を改善します。
正直に劣化させる。 検出なし、マッチングなし — アプリはそれを明確に伝え、ごまかしたりフローを中断したりせずに手動検索を提供します。
レート制限、アップロード上限、優雅な失敗などのガードレールは、基盤となるインフラストラクチャがそれに対応して構築されている場合にのみ機能します。これこそ、MicrocosmWorksのクラウドインフラストラクチャサービスが提供するために構築された種類の基盤です。
利用すべき状況と避けるべき状況
このパターンは、手動でのデータ入力が真の障壁となっている場合、写真が複数ステップの入力の代わりになる場合、マッチング対象のカタログがある場合、「完璧ではないが即座に利用できる」ことが「最終的には完璧だが時間がかかる」よりも優位な場合に利用してください。このパターンを避けるべきは、その領域が研究室レベルの精度を必要とする場合、マッチング対象のカタログがない場合、ビジョンAPIのコストが得られるエンゲージメントを上回る場合、または入力が視覚的に曖昧すぎて確実に識別できない場合です。
私たちのアプローチ
コンピュータービジョンにおいて、完璧に食品を識別するモデルを追い求めるのが本能的な行動かもしれません。しかし、真のレバレッジは別の場所にあります。それは、ビジョン出力が下流のすべてにどのように接続されるか、という点です。モデルに検索エンジンの言語を話すようにプロンプトし、その確信度をランキングに反映させ、裏で煩雑な情報を正規化する — そうすることで、すべてが数回のタップで完結します。勝利はより賢い分類器にあるのではなく、継ぎ目のないパイプラインにあるのです。
同様のものを構築中ですか？MicrocosmWorksのAIエージェントソリューションをご覧になるか、お問い合わせいただき、パイプラインアーキテクチャについてご相談ください。
その他のブログ
1. パーソナライズされたレシピ検索：次に何を食べるべきかを知る検索機能
2. マイクロサービスによるデジタルヘルスプラットフォームのスケーリング
3. Apple HealthとHealth Connectの同期
