はじめに
こんにちは、デリッシュキッチン開発部でソフトウェアエンジニアをしている新谷です。
エブリーの開発部では、日常業務から離れて新しい技術やアイデアに挑戦する「挑戦week」という取り組みを定期的に開催しています。 今回は限定的に2日間という短期間での開催でしたが、この挑戦weekを活用し、ヘルシカの画像解析機能の精度をさらに高めることを目指して、技術検証として性質の異なる2つのAIアプローチを構築・比較しましたので、その内容についてご紹介します。
※ 挑戦weekの詳細については過去の記事で紹介していますので、興味のある方は以下をご覧ください。
比較する2つのアプローチ
画像からの栄養素推定というタスクに対して、私たちは2つの異なるアプローチを設計しました。
LLM単体アプローチ
一つ目は、LLMが持つ広範な知識を用いて、画像から料理名や材料を特定し、栄養素を直接推定するアプローチです。この手法の強みは、一つのモデルで完結するため、シンプルで高速な応答が期待できる点です。
RAG活用アプローチ
二つ目は、LLMの推定能力に加えて、検索拡張生成（RAG）の技術を活用するアプローチです。LLMが推定した材料名を基に、デリッシュキッチン（DK）の食材データベースを検索し、得られた正確な栄養素データを基に最終的な計算を行います。よりデータに基づいた、精度の高い推定を目指すアプローチです。
具体的には、RAG活用アプローチでは以下のアーキテクチャを設計しました。
ナレッジベースの構築にあたっては、当初、より高度なアプローチを試みました。具体的には、Amazon OpenSearch Serverlessに専用のインデックスを作成し、AWS Lambdaを用いて食材データを自動的に流し込む仕組みです。この方法では、食材名のみをベクトル化し、各栄養素（カロリー、たんぱく質など）をメタデータとして付与することで、検索精度向上を目指しました。
しかし、検証を進める中で、メタデータが意図した通りに結果へ反映されないという課題に直面しました。 設定の見直しなどを試みましたが、短期間での解決が難しかったため、今回はアプローチを変更し、食材と栄養素をすべてCSVにしてS3にアップロードしBedrockの機能で直接ナレッジベースを作成するという、よりシンプルな方法を採用しました。
検証結果
これら2つのアプローチの性能を比較するため、特定の料理写真を用いて検証を行いました。デリッシュキッチンのレシピが持つ栄養素データを「参考値」として、各アプローチの推定結果がどれだけ近いかを比較します。
検証1：にらと豚肉の味噌炒め
| 項目 | DKレシピ | RAG | LLM単体 |
|---|---|---|---|
| カロリー(kcal) | 615 | 501 | 250 |
| たんぱく質(g) | 18.2 | 14.4 | 12 |
| 脂質(g) | 48.7 | 47.2 | 15 |
| 炭水化物(g) | 18.6 | 0.2 | 5 |
| 糖質(g) | 15.5 | 0.8 | 4.3 |
| 塩分(g) | 2.4 | 1.2 | 1.2 |
検証2：きゅうりとちくわのめんつゆナムル
| 項目 | DKレシピ | RAG | LLM単体 |
|---|---|---|---|
| カロリー(kcal) | 98 | 105 | 70 |
| たんぱく質(g) | 4.8 | 0 | 4 |
| 脂質(g) | 5.5 | 11.4 | 2 |
| 炭水化物(g) | 7.6 | 0.3 | 8 |
| 糖質(g) | 6.9 | 0.3 | 6.5 |
| 塩分(g) | 1.5 | 0.4 | 0.8 |
検証3：鶏むね肉のみぞれ煮献立
| 項目 | DKレシピ | RAG | LLM単体 |
|---|---|---|---|
| カロリー(kcal) | 741 | 1312 | 670 |
| たんぱく質(g) | 43.5 | 44.1 | 35 |
| 脂質(g) | 15.4 | 32.2 | 15 |
| 炭水化物(g) | 104.6 | 134.4 | 84 |
| 糖質(g) | 97 | 127.2 | 75 |
| 塩分(g) | 4.5 | 2.1 | 3.6 |
検証4：大根のとろとろ煮献立
| 項目 | DKレシピ | RAG | LLM単体 |
|---|---|---|---|
| カロリー(kcal) | 745 | 726 | 678 |
| たんぱく質(g) | 29.6 | 4.3 | 35.2 |
| 脂質(g) | 25.8 | 16.2 | 26.8 |
| 炭水化物(g) | 89.5 | 59.3 | 78 |
| 糖質(g) | 83.4 | 17.3 | 70.5 |
| 塩分(g) | 5 | 0.8 | 3.3 |
結果の考察
結果を見ると、RAGは、LLM単体と比較して参考値であるDKレシピの値に近くなるケースもあれば、逆に大きく外れてしまうケースもあるという、一長一短な結果となりました。
今回のRAGの試みは、LLM単体では推定が難しい「食材ベースでの栄養素計算」を、デリッシュキッチンの具体的な食材データを参照させることで、どれだけ推定値を参考値に近づけられるかを検証するものでした。
今後の課題と展望
今回の比較検証から、いくつかの課題が見えてきました。
- 材料の特定と量の推定のばらつき
- 画像に写っていない材料や、写っていても正確な量を推定するのは、現状のLLMの精度では依然として困難です。
- 材料検索のノイズ
- ベクトル検索時に、無関係な食材がヒットしたり、逆に必要な食材がヒットしなかったりする問題がありました。
- 栄養素の足し合わせが不安定
- LLMによる最終的な集計処理が、必ずしも期待通りに行われないケースがありました。
- 実行時間が長い
- 複数のステップを踏むため、LLM単体より処理に時間がかかります。
特に課題2, 3, 4については、改善の余地があると考えています。例えば、ベクトルDBのチューニングや全文検索への切り替え、栄養素の集計をルールベースで行う、といった対策が考えられます。
これらの課題を踏まえ、今後は以下のような別のアプローチも検討しています。
- 推定した料理名から類似のDKレシピを検索し、その栄養素の平均値を採用する。
- DKのレシピ画像と料理名で新たなベクトルDBを構築し、画像で類似検索を行う。
- 栄養素推定に特化したモデルをファインチューニングする。
まとめ
今回は、画像からの栄養素推定の精度向上を目指し、性質の異なる2つのAIアプローチ（LLM単体/RAG）を構築・比較検証しました。 結果として、RAGは特定の条件下で精度が向上する可能性を示しましたが、安定性や応答速度の面ではLLM単体に分があるなど、それぞれに利点と課題があることが明らかになりました。
この挑戦で得られた知見を活かし、さらなる精度向上に向けて、今後も検証を続けていきたいと思います。
