人類のあらゆる料理を2メガバイトに圧縮する
(arxiv.org)- Epicureは、414万件のレシピとFlavorDBの化合物データを用いて、1,790個の標準食材について300次元の埋め込みを学習したモデルである
- 既存のFlavorGraphにあった英語中心コーパス、固定的な化学・レシピ混合、分散した食材語彙の問題を軽減するよう設計されている
- Cooc、Chem、Coreは同じ構造でランダムウォークのスキーマだけを変え、レシピ共起と化学シグナルの比重を比較する
- 3つの埋め込みは、27の感覚・栄養方向と8つの料理マクロ地域を線形に復元し、教師なしで20の要因を得る
- 最近傍とSLERP方向演算により、riceをSouth-Asian方向へ回転させるような食材探索が可能だが、コードと成果物は未公開の状態である
Epicureの目標
- 食材埋め込みは、食材同士の相性、文化圏ごとの類似食材、感覚・栄養軸上での位置を見つけるための基盤である
- 味噌にはみりん、だし、ごま油が合い、オリーブオイルにはバジル、トマト、プロシュートが合う、といった知識は、複数文化圏のレシピコーパスとシェフの直感に蓄積されている
- メニュー・レシピ支援ツール、手持ち食材ベースの推薦、地中海食材から東アジア圏の対応食材への移動探索、脂っぽさ・発酵・苦味・高タンパクのような軸に基づく探索に活用できる
- 既存研究は、化学ベースのフレーバーネットワークと、レシピ・知識グラフベースのアプローチへとつながってきた
- Ahn et al. [2011]はフレーバーネットワークを導入し、共有化合物に文化圏ごとの差異が現れることを示した
- Garg et al. [2017]のFlavorDBは936件の食品エンティティの芳香分子を一覧化し、FooDBは70,000件の化合物で化学的範囲を拡張した
- FlavorGraph [Park et al., 2021]はFlavorDBとRecipe1M+を結合し、6,653個の食材と1,645個の化合物からなる異種グラフを作成してMetapath2Vecで学習した公開食品埋め込みである
- FoodKG [Haussmann et al., 2019]は、レシピ、栄養、オントロジーデータをRDF知識グラフに統合し、推薦を目的とした
FlavorGraphの限界とEpicureの設計
- 以前の分析では、FlavorGraphの300次元埋め込みから、味、食感、栄養、地理、文化、加工を含む15個以上の解釈可能な料理次元が確認され、LLMで補強した語彙統合が大半のシグナルを強化したことが示されている
- FlavorGraphの固定的な事前学習には3つの制約があった
- 英語中心コーパス1つに依存していた
- 化学シグナルとレシピ文脈シグナルが1つの固定的な帰納バイアスとして融合されており、設計軸として調整しにくかった
- 食材語彙に調理法の詳細や非食品項目が混在する分散構造が残っていた
- Epicureは、これらの制約を減らすためにゼロから学習した3つの姉妹skip-gram食材埋め込みで構成される
- 11のソースから414万件のレシピを収集
- 言語範囲は英語、中国語、ロシア語、ベトナム語、スペイン語、トルコ語、インドネシア語、ドイツ語、Indian-English
- 生の食材文字列をLLM補強パイプラインで1,790個の標準食材項目に正規化
- 3モデルはアーキテクチャとハイパーパラメータを共有し、skip-gram目的関数が参照するランダムウォークのスキーマだけが異なる
データと3つの埋め込み
- Epicureは2種類のグラフを出発点とする
- 食材-食材NPMIグラフは203,508本のエッジで構成される
- FlavorDB食材-化合物グラフは80,019本のエッジで構成され、15カテゴリにまたがる2,247個の型付き化合物ノードを含む
- 3つのMetapath2Vec変種は、化学とレシピ文脈のあいだのスペクトラム上で異なる位置を占める
-
Cooc
- レシピ共起グラフだけを歩くモデルである
- 食材が実際のレシピで一緒に現れる文脈シグナルに焦点を当てる
-
Chem
- 型付き化合物メタパスだけを歩くモデルである
- 食材と化合物の関係から来る化学的シグナルに焦点を当てる
-
Core
- 化合物ベースの経路と食材-食材経路をあわせて使う
- 制御された混合比率で食材-食材walkを注入し、化学シグナルとレシピ文脈シグナルを混ぜる
- この構成により、同じ入力データと学習構造の中で化学 vs レシピ文脈の比重が設計軸として表に出る
- 3つの姉妹モデルの違いはランダムウォークのスキーマにのみ生じるよう設計されている
- 埋め込みの性質の差を入力データではなくwalkスキーマの効果として比較できる
-
埋め込み空間で復元された料理的意味
- 3つのEpicureモデルは、教師あり学習のprobeで連続的な感覚・栄養方向27個と料理マクロ地域8個を線形に復元した
- 料理圏の分離可能性の平均Cohen’s dはCooc/Core/Chemの順に2.43/2.70/3.07である
- probeの範囲にはcuisine、food-group、NOVA加工等級、USDA多量栄養素、19の感覚カテゴリが含まれる
- 教師なし分析では、各モデルから20個の解釈可能な要因を復元した
- food-groupで残差化した埋め込みに対して、複数seedで安定なFastICAを適用
- 各要因の上位四分位項目をGMMで分割し、モデルごとに150〜200個の名前付き料理モードを得た
- GMMモードの平均一貫性はランダムペア基準線より高かった
- Cooc/Core/Chemの平均一貫性は0.611/0.833/0.703である
- 対応するランダムペア基準線は0.097/0.348/0.115である
- 既存の埋め込み研究の観点も検証に用いられた
- Mikolov et al. [2013]のword2vecにおける線形方向性の観点は、27個の教師あり料理probe、20個のFastICA要因、SLERP回転演算の基盤となっている
- Mu et al. [2017]の等方性の観点に従い、participation ratioと平均pairwise cosineで埋め込みの等方性を直接測定した
- 3つの姉妹モデルは等方性スペクトラム上で明確に異なる位置にあり、これは入力データではなくwalkスキーマの特性として扱われる
- Caliskan et al. [2017]のWEATは、名前付き意味軸が幾何構造に反映されているかを診断する補助検証として使われた
探索演算と活用可能性
- Epicureは同じ300次元埋め込み空間で、2つの補完的な演算系を提供する
-
最近傍ベースの対応付け
- top-K近傍検索で食材の周辺にある近い項目を探す
- モードメンバーシップ照会で、特定の料理モードに属する項目を探索する
-
SLERP方向演算
- seed食材を、教師ありpole vectorまたは創発的なfactor-mode poleの方向へ回転させる
- 連続角度θが、seed優勢の検索とtarget優勢の検索のあいだを補間する
- 例として、riceにSouth-Asian方向を加えると、curry leaf、urad dal、chana dal、fenugreek seedの方向へ移動する
- 教師ありの意味方向と、教師なしの創発モードの両方を食材探索に使える
- シェフ向けツールでは、食材を回転・混合・検索しながら、感覚・栄養・文化的に一貫した方向に沿って探索できる
- 化学ベースの関係とレシピ文脈ベースの関係は、モデル選択とwalkスキーマによって調整できる
- コードと学習済み成果物は現在公開されていない
-
1件のコメント
Hacker Newsの意見
研究自体は興味深いが、タイトルは誤解を招く
より良いタイトルは「人類が使う食材を1,800個の原始要素に圧縮」くらいだと思う
実際の調理法、つまり準備方法や比率のような内容はほとんどないが、世界的にトマトが牛肉と相性が良いといった種類の情報は、味の組み合わせを作る際にかなり有用で興味深い資源になり得る
1,800個の食材のすべての組み合わせを載せているわけではないが、広く使われるハーブ、スパイス、野菜、肉をかなりうまく扱っている。この本を圧縮してもテキストサイズはそれほど大きくならない気がする
LLMが作ったレシピの問題は、調理技法の微妙さを見落とす点だ。成否が1つの工程や1つの比率にかかっていることが多く、たとえば「フライドチキン」は世界中に無数のバリエーションがあるが、レシピを平均化してもおいしいフライドチキンにはならない
11のデータソースがいくつかの一般的な料理を扱っているが、英語と中国語のソースがデータセットの90%を占めている。アフリカ圏とアラブ圏もデータにないが、この2つだけでも世界人口の約25%になる
非英語の用語をすべてAIで英語に翻訳したのも、方法論としては理解できるが、誤りの余地があるのは明らかだ
牛肉は煮方を間違えると固くなるが、トマトの酸が再び柔らかくしてくれる
興味深い
レシピを小さな図式に圧縮しようとしているところだ: https://leontrolski.github.io/recipes.html
ずっとこういうものを想像してきたし、レシピが材料を巨大で区別のないリストとして並べたあとに「乾いた材料を深いボウルで混ぜる」と言ってくるのがいつも不満だった
しばらくは、これをうまく実装すれば収益性があると思っていたが、今では強力なインターフェースが1つ出た瞬間に簡単に複製されそうだ
表は Modernist Cuisine のレシピを思い出させる。そこでは材料を手順ごとにまとめ、重さ、時には体積や比率まで一緒に書いてある
例: https://modernistcuisine.com/wp-content/uploads/2013/01/Mac-...
参考までに、https://publicdomainrecipes.com 全体が https://browse.library.kiwix.org で22MiBの単一ファイルとして提供されている: https://browse.library.kiwix.org/viewer#publicdomainrecipes....
レシピの追加は https://github.com/ronaldl29/public-domain-recipes でできる
「英語、中国語、ロシア語、ベトナム語、スペイン語、トルコ語、インドネシア語、ドイツ語、インド英語など7言語の11ソース」なら、人類全体の料理 と言うのは難しい
ただし、世界的に非常に人気のある イタリア、日本、ギリシャ、メキシコ料理 が抜けており、アフリカと中東もまったくないので不完全だ
論文でもすぐに認めてはいるが、バランスの取れたデータセットではないのは確かだ
[1]で、この論文が説明しているものの以前の反復版のように見えるデモを見ることができる
どんな食材を選んでいるのか気になって、Peter Gilmore[2]の『Organum: Nature, Texture, Intensity, Purity』に出てくる見慣れない食材をいくつか試してみた。彼はオーストラリア・シドニーのQuayレストランで知られている
ジュニパーベリー、マカダミア、ニゲラシード、オレンジフラワーウォーター、レモンバーベナのようなかなり冒険的な材料も理解していて、ごま油と焙煎ごま油も区別している。食材リストには「米」「黒米」「玄米」「もち米」しかないのに、「米」を選ぶと炒飯には炊いたジャスミンライスを冷まして使えと指示し、ピラフにはバスマティライスを浸してすすげと言うくらい賢い
「ラム」を選び、煮込みによく使う野菜を一緒に選ぶと、肩肉やすね肉のような部位を選んでくれる
グレープシードオイル、オルゾ、マンゴスチン、レモンマートルは知らず、karkallaのようなPeter Gilmoreクラスしか使わず、たいていのシェフは聞いたこともないような食材も当然知らない。ただ、そうした食材は地域性が強いか特殊なものなので、大きな制約ではないと思う
「かぼちゃの種」は知っているのに「pumpkin」は知らず「squash」として扱っているので、イギリス英語／アメリカ英語の使い分けを改善するには、さらにローカライズが必要だ。「ラム」と「アボカド」を組み合わせてサラダを作ってくれることを期待したが失敗し、後で見たら食材リストにレタスやルッコラはなく、アメリカ英語の表現である「salad greens」しかなかった。ほかのサラダ材料や鶏肉、あるいはタンパク質なしでも試したが、サラダは作らず、タンパク質の塊のまわりにトマトゼリー（寒天）とアボカドピュレを添えた、なんちゃって高級料理ばかり生成した
[1] https://epicure.kaikaku.ai/
[2] https://en.wikipedia.org/wiki/Peter_Gilmore_(chef)
アメリカ人にとっては、一般的に使うさまざまな種類のsquashがあり、pumpkinはそのうちの一つにすぎない。思い浮かぶのはacorn、butternut、spaghettiで、厳密に言えばzucchiniも入る
X/Twitterで見たが、人類の料理とあらゆる技法、食材、文化的文脈ごとの調理法を2メガバイトに圧縮できるというのは信じがたい
「ツール呼び出しとコーディングができる1GBモデル」と言われて使ってみたら、ほとんど動かなかったのに似ている。技術的には1GBのコーディングモデルなのだろうが、良いモデルではないということだ
英語とドイツ語を含めていながら、イタリア語とフランス語を除外した食品モデル／コーパスは信頼しにくい
本物のフランス語で書かれたレシピは入っていなくても、英語で書かれたフレンチオニオンスープのレシピは確実にあるはずだ
「[Claude]が決定論的デコーディング（temperature 0–0.1）ですべての食材分類を行った」とあるが、この文脈では大きな問題ではないものの、低いtemperatureがそのまま決定論を意味するわけではない
クリックベイトを除けば、かなり興味深い概念だ。こうした埋め込みによって、食材や風味プロファイルにword2vecの瞬間が訪れるのか気になる
ほかの人たちが適切に指摘しているように、より代表性のあるデータソースで作り直すこともできるし、このアプローチがどんな効果を出すのか楽しみだ
Claude Codeにそのデータと情報を入れて実装させてみたが、かなり良さそうに見える
レシピ生成よりも、代替食材の推薦に向いているのかもしれない: https://viz.roshangeorge.dev/recipe-model/