LLM によるプログラムベース推論 Shumpei Miyawaki keywalker,inc. / Tohoku Univ. @catshun_ 2023.08.07 Geography&Language 勉強会 #4 https://sites.google.com/view/geography-and-language/studygroup • LLM 活⽤事例の⼀つとして プログラムベース推論の事例 を紹介 • 勉強会を通してプログラムベース推論の⻑所・短所を議論し、 LLM 活⽤の選択肢を増やす ことに議論を終着させる

P.1 • 勉強会⽤に突貫的に作成しており、内容に誤りがある可能性が⼤いにあります... • 内容の誤りや引⽤漏れ等がありましたらお伝えください • 発⾔は confabulation を含みます • 本勉強会は LLM 応⽤に関⼼のある⽅向けの発表を想定しています • 著者は地理空間情報の初学者であり ”学びたい” というスタンスで発表いたします 留意事項

P.2 https://arxiv.org/abs/2202.03629 • Confabulation (https://en.wikipedia.org/wiki/Confabulation) a memory error defined as the production of fabricated, distorted, or misinterpreted memories about oneself or the world. ⾃分⾃⾝や世界について、捏造、歪曲、あるいは誤った解釈をした記憶を作り出す，記憶に関するエラー • Hallucination (Ji+’22; Survey of Hallucination in NLG) a percept, experienced by a waking individual, in the absence of an appropriate stimulus from the extracorporeal world ⽬覚めている個⼈が、体外世界からの適切な刺激がないときに経験する知覚 • intrinsic hallucination ⽣成された⽂章が参照元の内容と ⽭盾している • extrinsic hallucination ⽣成された⽂章が（事実でも）参照元の内容から 事実判定ができない Confabulation or Hallucination 図2. キャプション⽣成における object hallucination 画像から 確認不可 画像とは ⽭盾する ☕

⾃⼰紹介

Shumpei Miyawaki ⾃然⾔語処理エンジニア 兼 学術研究員 Twitter @catshun_ note https://note.com/catshun_ 2022/09 - 現在 東北⼤学 データ駆動科学・AI 教育研究センター TohokuNLP 学術研究員 2022/04 - 現在 株式会社キーウォーカー データサイエンス部 ⾃然⾔語処理エンジニア 2020/04 - 2022/03 東北⼤学 ⼤学院情報科学研究科 博⼠前期課程（修了） 2016/04 - 2020/03 東北⼤学 ⼯学部 電気情報物理⼯学科（卒業） 2013/04 - 2016/03 神奈川県⽴ 横須賀⾼等学校（卒業） https://speakerdeck.com/smiyawaki0820/olagpt-wota-xi-sita-agent- gou-zhu-kotohazime-ai-agent-meetup-tokyo-number-0 https://note.com/catshun_/n/na18e2c470b2f https://speakerdeck.com/smiyawaki0820/2023-dot-03-dot-21-gpt-4-prompt-bao-gao-hui

P.5 Research Interest 共通テーマ︓ 計算機による知識獲得 2019 2020 2021 2022 2023 述語項構造解析 雑談対話システム オープンドメイン質問応答, RAG シーン画像における OCR ベースの画像検索 ⽂書画像読解・アイコン QA ⾔語媒介推論×仮説推論 プログラムベースの構成的推論 🥈 🥉 🥈 🥉 NeurIPS EfficientQA ❓ ❓ AI王 クイズコンペ ⼈⼯知能学会 対話コンペ ⼈⼯知能学会 対話コンペ 📝 📝 📝 📝 📝 📝 📝 📝

P.6 ⾔語媒介推論 による Proactive な LLM アプリケーション ⾔語 Enc 記憶領域 ⾔語 Dec 多くのアプリケーションが reactive な設計 実世界の事象 実世界へ投影 ここからやりたい ここまでやりたい 情報伝達の⼿段として⾔語情報が古くから採⽤されてきた → ⾔語というメディアが思考・記憶・伝達という側⾯で優れている（⾔語媒介推論の動機） 時間変化 視覚変化 旅⾏計画~旅先~振り返り まで サポートする旅⾏エージェントを作りたい • ユーザに対する 指⽰待ち が発⽣ • アプリに対する 出⼒待ち が発⽣ ※ 並列・⾮同期処理である程度改善 ※ 成果物の品質重視であれば問題にならない 京料理が楽しめる 近くのランチを教えて 20 sec Reactive なアプリケーション Proactive なアプリケーション 京料理が楽しめる 近くのランチを教えて そろそろお昼ですね。 せっかく京都に来られたので 近くの京料理ランチをまとめておきました︕ 空間変化 進捗状況 様々な情報をトリガーとする

1. LLM 活⽤のメンタルセット 2. GeoProg の紹介

〇〇 案件なんだけど ChatGPT で出来るよね︖ 現場猫のイラスト利⽤に関してはこちらを遵守しています https://kumamine.blogspot.com/2020/12/blog-post_25.html 上司猫

P.9 ChatGPT Plugin × 旅⾏エージェント https://chat.openai.com/share/907df467-b6ec-4ffb-9a10-71445b04d7b3 成果物

P.10 Code Interpreter × 空間情報 古橋⼤地⽒ (⻘⼭学院⼤教授) +’23 – 空間情報× ChatGPT の付き合い⽅ ChatGPT Code Interpreter はどこまで使えるか︖ https://speakerdeck.com/fullfull/chatgpt-code-interpreter-hadokomadeshi-eruka 遠藤諭⽒ (株式会社⾓川アスキー総合研究所 主席研究員)+’23 – ChatGPT によるコード⽣成 Code Interpreter 導⼊案内 https://www.dropbox.com/scl/fi/ffchgodrellus32jgv3mp/20230803_ChatGPT-02.pdf?dl=0&rlkey=phmhodyddpsxslh15l98fyfyl https://github.com/furuhashilab/chatgpt4plateau

なんでも ChatGPT でやれば良いわけではない

P.12 • 旅⾏計画にかかる⼈的コストを効率化したい • 宿泊施設・観光地・⾷事処・交通など サイト回遊しないと実現しない情報収集を シームレスに実⾏可能なシステムが欲しい • 好みに応じた旅⾏情報の収集をしたい • 過去に訪れた旅⾏先の情報やペルソナから 次期シーズンにオススメの旅⾏先を教えて欲しい ⽬的 と ⼿段 を混同しない ChatGPT 使ったアプリケーションを作りたい 顕在ニーズ 潜在ニーズ 本来の⽬的は... 旅⾏計画~旅先~振り返り まで サポートする旅⾏エージェントを作りたい ※ 悪い例

P.13 stakes を理解して適切なモデルを選択する Fintan 機械学習チーム - ChatGPT vs BERT︓ どちらが⽇本語をより理解できるのか︖ (2023) https://fintan.jp/page/9126 Qin+’23 - Is ChatGPT a General-Purpose Natural Language Processing Task Solver? https://arxiv.org/abs/2302.06476

いつ ChatGPT を使うか︖

P.15 Rapid Prototyping から Additive Manufacturing へ 品質 スプリント LLM の壁 地道な努⼒ 1 2 3 LLM は MVP 作成に有効 ✔ 初期コスト w/o 学習・注釈 ✔ ⾃然⾔語による迅速な開発 MVP w/ LLM • ユーザ FB の反映 • UI/UX の改善 • DevOps 基盤の整備 • 機械学習の導⼊ • API 導⼊ セキュリティ対策

P.16 ☕ LLM 開発における マインドセット（妄想です） ※ どんどん作る ≠ 無謀な道 • とにかく完成品をつくり、営業・顧客 がアクセスできるようにしておく • 初期段階はセカンドペンギンを集め 開発サイクルを迅速に回す • 意思決定が可能なペースセッター型 リーダーがいるチームは強い印象 • ⾃分の学習サイクルを柔軟に変更する • 組織効⼒感って結構⼤事 安宅+’10 - イシューからはじめよ 知的生産の「シンプルな本質」 破壊的イノベーションにおいては 廃盤リスク を恐れず どんどん作り 品質改善に割り当てる時間を増やすことが重要（諸説あり） ※ 廃盤リスクを恐れず ≠ いらないものを作る 価値の ⾼い仕事 解の質 答えを出す必要性 とにかく仕事を こなす無謀な道 組織マネジメントも重要 • いらないものを作らないのは重要、 ただ新規事業成功率は 5% といわれる • LLM のユニバーサルデザイン化に伴う 供給過剰化（付加価値が重要） • プロジェクト終結の⾒極めが重要 • 廃盤・プロジェクト振り返りは 過去の知識資源となる • ただし企業⽅針によって異なる

注意すべき点もある

P.18 チャット形式はユーザの 認知負荷・⾏動負荷 が⾼い ⼤野峻典⽒（Algomatic inc. CEO） LLM を活⽤した “反直感的” な新規サービス設計成系 LLM in Production Meetup #0 kick off (2023) https://speakerdeck.com/shunsukeono_am/llmwohuo-yong-sita-fan-zhi-gan-de- naxin-gui-sabisushe-ji-a1bc8a7f-a69f-4f60-bc93-90702c404769?slide=13 LLM in Production Meetup #0 でもチャット形式の難しさについて取り上げられた https://llm-in-production.connpass.com/event/287806/ 松本勇気⽒（株式会社 LayerX 代表取締役 CTO） toB における LLM 活⽤と UX #LLMProd LLM in Production Meetup #0 kick off (2023) https://speakerdeck.com/ymatsuwitter/llm-in-tob-service-and-its-ux?slide=14

P.19 Confabulation 対策としての Defensive UX 誤りを 排他する 誤り発⽣時のリスクを理解した上で LLM を使わない選択肢も持つ 誤りを 抑制する 特定性の⾼いプロンプトやシグニフィアによるユーザ⼊⼒の⾃由度に制限をかける 誤りを 特定する 事前に定義した関数の実⾏⼿順を選択的に⽣成することで再現性を担保する 誤りを 出⼒しない ツール等の実⾏結果を⽤いて⾃由記述から参照型のタスクに落とし込む 誤りを 検知する ⽣成内容に対して事実確認等のチェック機能を設ける 誤りを 修正する 内省や代替案提⽰等の機能やユーザによるフィードバック送信機能を設計する 誤りを 説明する 参照元やプログラム等による中間推論過程を出⼒根拠として提⽰する 誤りを 認める ⾔語モデルの使⽤を明記した上で未解決時は有⼈のサポート体制に接続する 誤りを 繰り返さない 対話履歴等のログと応答評価を併せて記録し次回以降の対話で参照する ⽣成誤りを認めた上で、ユーザー⾏動の誘導・エラー処理・予測・管理する 参考︓Eugene Yan⽒（Senior Applied Scientist at Amazon）- Patterns for Building LLM-based Systems & Products https://eugeneyan.com/writing/llm-patterns/#defensive-ux-to-anticipate--handle-errors-gracefully

P.20 地理空間情報 を扱うためには 詳細な数値・専⾨的な情報 知識の更新が発⽣する問題 地理・交通情報を加味した最適経路計算 LLM が苦⼿とする分野の⼀例 Kandpal+’23 – Large Language Models Struggle to Learn Long-Tail Knowledge (ICML) https://openreview.net/forum?id=sfdKdeczaw 質問に対して事前学習データに含まれる関連⽂書数 ある質問において その質問に関連する⽂書が 学習データに含まれない場合 不正解となる可能性が⾼い TriviaQA における正解率 特定の観光地情報・住所 等については 検索等による情報補完が必要 東⼭翔平⽒（NICT/NAIST）+’23 ChatGPT は地理座標を知っているか︖ https://qiita.com/shigashiyama/items/b2cbbb8890d070e963f7

P.21 検索拡張型⽣成タスク の採⽤ (引⽤） Asai (Washington Univ.)+’23 – Retrieval-based Language Models and Applications / ACL 2023 Tutorial https://acl2023-retrieval-lm.github.io/slides/5-application.pdf

その他 設計上の留意事項

P.23 推論フロー を明確にした上で設計する リクエスト意図理解 知識の参照先指定 外部知識の参照 内省・ログ リクエストのタスク分解 参照結果に基づいた推論 e.g. 箱根旅⾏に⾏きたい レスポンス + 根拠 中略 ① few-shot の検索 ② LLM による条件スロット⽣成 ③ 複数ターン対話によるスロットフィリング ⼈数 2⼈ 宿泊場所 箱根 宿泊条件 朝⾷付き 2 万円 交通⼿段 ... ... 1. 箱根旅⾏におけるスロットの作成 2. 埋まっていない属性値を問い返す 3. スロットが全て埋まったら終了 交通⼿段は何を想定されていますか？ 例︓スロットフィリングを⽤いた意図理解

P.24 AI には ガードレール が必要（引⽤） 井尻義久⽒（LINE株式会社 Data Science センター AI Dev 室室⻑） ⽣成系 AI の実応⽤に向けて / イメージセンシングセミナー 2023 特別招待公演 https://speakerdeck.com/line_developers/toward-practical-applications-of-generative-ai?slide=72 LINE の対話システムの全体図

地理空間情報のような 詳細な情報 を扱い、 経路計算や GeoCoding のような 複雑な処理 を実⾏し、 再現可能な柔軟な推論 を⾏いたい

1. LLM 活⽤のメンタルセット 2. GeoProg の紹介 ※ ToDo 箇所の紹介も含みます https://note.com/catshun_/n/na18e2c470b2f

P.27 どんなアプリケーションか︖ 🙆 ⾸都圏の⼋⽉に⾏われる花⽕⼤会 概要）マップ作成アプリケーション（ToDo: 旅⾏計画等の拡張） 動機）地理空間情報の関連タスク（旅⾏計画・マップ作成など）ではサブタスクが共通している 1. ユーザからのクエリ解析 2. “⾸都圏 ⼋⽉ 花⽕⼤会” で Google 検索 3. 検索結果からクエリに該当する場所情報を取得 4. 各場所に対してジオコーディング 5. 結果を Google Map 上にプロット これらのサブタスクは Geography×NLP において広く共通する → 再現性の⾼い プログラムベース推論 を採⽤

P.28 アプリケーション構成図 axios

P.29 どんなことができるか︖

P.30 現状は課題もたくさんある • ユーザ⼊⼒の曖昧性解消 • 外部ツールの性能改善 • 応答速度の向上 Google Map 2 sec GeoProg 20 sec

GeoProg の名前由来 → VisProg という⼿法を踏襲しているため

Visual Programing: Compositional Visual Reasoning without Training Tanmay Gupta, Anirudha Kembhavi Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) 井上直⼈⽒（CyberAgent AI Lab）- CVPR2023読み会（前編） https://speakerdeck.com/naoto0804/jie-shuo-visprog-cvpr2023-best-paper ※ 本発表では、⼿法の応⽤について紹介します ※ 重複を避けるため論⽂解説については以下を参照ください

P.33 参考︓岡崎直観⽒ (東北⼤) +’15 – 単語の分散表現と構成性の計算モデルの発展 / 2015年度⼈⼯知能学会全国⼤会 (第29回) https://www.slideshare.net/naoakiokazaki/20150530-jsai2015 構成性 [Marelli+’14; Partee+’84; Frege 1892] ⽂や句の意味は、単語の意味と⽂の構造に従って構成的に理解される 複雑なタスク は構成性を仮定して サブタスクに分解 [Krishnamurthy+’13; Andreas+’16] Visual Programing: Compositional Visual Reasoning without Training

P.34 参考︓岡崎直観⽒ (東北⼤) +’15 – 単語の分散表現と構成性の計算モデルの発展 / 2015年度⼈⼯知能学会全国⼤会 (第29回) https://www.slideshare.net/naoakiokazaki/20150530-jsai2015 構成性 [Marelli+’14; Partee+’84; Frege 1892] ⽂や句の意味は、単語の意味と⽂の構造に従って構成的に理解される 複雑なタスク は構成性を仮定して サブタスクに分解 [Krishnamurthy+’13; Andreas+’16] 既製パーサ性能問題 [Andreas+’16] ⾼い学習コスト問題 [Hu+’17] Codex, GPT-4 ⾼精度なエンティティ抽出 ⾼い汎化性能による 追加学習の不要 プロンプトによるタスク分解 [Khot+’22; Dua+’22; Zhou+’23; Press+’23] Visual Programing: Compositional Visual Reasoning without Training

P.35 （VQA）ヒトとラクダの合計数は︖ + ヒト ラクダ A. 2 Visual Programing: Compositional Visual Reasoning without Training 物体1 = localize ( img=画像in , query=“ヒト” ) 物体2 = localize ( img=画像in , query=“ラクダ” ) 個数1 = count ( boxes=物体1 ) 個数2 = count ( boxes=物体2 ) 答え = eval ( expr=“{個数1}+{個数2}” ) LLM がリクエストを機能別に分解し疎結合なプログラムとして表現

P.36 どうやって プログラム⽣成 を⾏うか︖ Gupta+'23 - Visual Programming: Compositional Visual Reasoning Without Training (CVPR) GPT-3 に few-shot の デモプログラム を与えて対象タスクのプログラムを⽣成 BMW を Audi に修正、曇り空を晴れ空に修正 ⾚い⾞を⻘い⾞に修正 ⽩い Audi をポップに彩って Nicole Kidman の顔を :p に修正して BMW を Audi に修正、曇り空を晴れ空に修正 するプログラム GPT-3 機能参照

P.37 物体1 物体2 個数1 １ ... ... どうやって プログラム実⾏ を⾏うか︖ Gupta+'23 - Visual Programming: Compositional Visual Reasoning Without Training (CVPR) GPT-3 に few-shot の デモプログラム を与えて対象タスクのプログラムを⽣成 物体1 = localize ( img=画像in , query=“ヒト” ) 物体2 = localize ( img=画像in , query=“ラクダ” ) 個数1 = count ( boxes=物体1 ) 個数2 = count ( boxes=物体2 ) 答え = eval ( expr=“{個数1 }+{個数2 }” ) “kwargs”: { “boxes”: 物体1 }, “function”: “count”, “output”: “個数1 ” 引数の解析 関数の実⾏ … count 格納 取得 👈

P.38 ReAct [Yao+ʼ22] Visual Programing (VisProg) ReAct と VisProg の⽐較 京都への⽇帰り旅⾏計画のレポート作成 観光地検索 飲⾷店検索 宿泊地検索 GeoCoding 経路探索 レポート作成 まずは観光地を検索する search: 観光地検索 清⽔寺、⾦閣寺、嵐⼭ 観光地を取得したので 次は清⽔寺周辺の … … write: レポート作成 … ⼊⼒情報からプログラムによる 実⾏計画 を⽴てる 1. 情報収集 2. 経路探索 3. レポート作成 プログラムを順次実⾏ Ø クエリ⽣成の性能を含む検索精度・推論誤りに課題 Ø 誤った出⼒形式によるパージングエラーの発⽣ Ø 柔軟な推論が可能である⼀⽅で再現が難しい Ø プログラムの⽣成誤りの発⽣ Ø 再現可能である⼀⽅で柔軟な推論が難しい

P.39 VisProg の特徴 要求定義 要件定義 外部設計* 内部設計 製造 レビュー 単体テスト 結合テスト システムテスト 受け⼊れテスト LLM がツール集合を組み合わせるだけ なので レイヤ別にプログラマと役割が分担できる ⻑所 • ツールを組み合わせるだけ なので 結合テストが容易 • 単体テスト済ツールを使⽤する ことで 予期せぬ⽣成を避ける e.g. 知らない API を叩かない 短所 • ツールを組み合わせるだけ なので 柔軟な推論が難しい 物体1 = localize ( img=画像in , query=“ヒト” ) 物体2 = localize ( img=画像in , query=“ラクダ” ) 個数1 = count ( boxes=物体1 ) 個数2 = count ( boxes=物体2 ) 答え = eval ( expr=“{個数1 }+{個数2 }” ) * インターフェース等の外部設計ではなく、 関数の繋げ⽅である「実⾏プロセスの定義」を指す（若⼲ミスリード）

P.40 GeoProg における問題の 定式化 観光地 飲⾷店 温泉地 宿泊地 ショッピング GeoCoding 経路探索 ルール 何もしない レポート記述 位置プロット 領域プロット スラムダンクの聖地⼀覧をプロット 箱根⽇帰り温泉旅⾏ • ツール利⽤に結合制約を設ける • I/O データ形式・機能に基づいて ツールの組み分けを⾏う • 組み分けされたプロセスを順序付け 関連する情報の収集 地理空間情報の紐付け ⽬的地候補の決定 レポートの作成 実⾏プロセス

P.41 GeoProg における 結合テスト 関連する情報の収集 地理空間情報の紐付け ⽬的地候補の決定 レポートの作成 観光地 飲⾷店 温泉地 宿泊地 ショッピング GeoCoding 経路探索 ルール 何もしない レポート記述 位置プロット 領域プロット スラムダンクの聖地⼀覧をプロット 箱根⽇帰り温泉旅⾏ • ツール利⽤⽅法に結合制約を設ける • 実⾏プロセスを定義し、 I/O データ形式・機能に基づいて 実⾏順序別にツールの組み分けを⾏う • 以下の項⽬をテストする • 事前定義した関数を使⽤しているか • ⽣成コードがプロセス順序に準ずるか • 実⾏プロセスに各機能をあてはめて 実⾏した場合に正常終了するか 実⾏プロセス

まとめ

P.43 • モジュールを組み合わせるため柔軟な推論が難しい • プログラムの⽣成誤りに対する内省が別途必要となる • 事前にツールを定義する必要があるためプログラマの介⼊が⼤きい • 逐次的な推論を⾏わず中間推論過程をプログラムとして記述するため再現できる • LLM が単体テスト済みのツールを組み合わせる設計にすることで プログラマとの責任分界点を明確にすることができる (P.39) • ツールの利⽤順序に制約を設けることで結合テストを実施できる (P.41) VisProg / GeoProg の ⻑所・短所 ⻑所 短所

P.44 ☕ コード⽣成型アプリケーション⽐較 co-pilot 型 関数組み替え型 プログラム⽣成型 概要 LLM が提案して プログラマが修正する 関数の組み合わせを LLM が提案する 実⾏可能なプログラム を LLM が記述する 最終判断 プログラマ LLM LLM ⻑所 • プログラマ負担の減少 • テストが容易 • プログラマ負担なし • 柔軟な推論が可能 短所 • プログラマ介⼊が多い • 柔軟な推論が難しい • 予期せぬ動作の対処 • テストの実⾏が困難 事例 GitHub Copilot, Code Interpreter VisProg ViperGPT, CodeVQA, Chameleon, LATM ベストプラクティスはないので対象タスクの性質等に合わせて選択するとよい

Appendix ※ 以降で紹介する論⽂は⼀部を抽出して解説しています 詳細は必ず元論⽂をご参照ください ※ また誤り等がある場合はご指摘いただけますと幸いです

LLM × プログラムベース推論

P.47 • ⾃然⾔語の記述から課題を解決するための Python プログラムを中間推論過程として⽣成 • ⽣成プログラムにはコードを解説するための コメント や 変数名 を ⾃然⾔語に近い形で記述 する • LLM は⾃然⾔語問題を実⾏可能なステップに分解するよう学習される • 算術演算・記号推論、アルゴリズムを含む 12 セットで LLM - インタプリタの相乗効果を実証 Program-aided LM (PAL) [Gao+’22] https://reasonwithpal.com/ 記号推論 算術演算 アルゴリズム問題 コメント除去 と 変数名置換 によるアブレーション結果 12 評価セットにおいて PAL が CoT の推論性能を凌駕 PALは参照数にも頑健 (Colored Object) テーブルの上には、紫のクリップ、ピンクのストレスボール、茶⾊のキーホルダー、緑のス クランチフォン充電器、モーブ⾊のフィジェットスピナー、ワインレッドのペンなど、たく さんの物が並べられています。ストレスボールの真右にある物体の⾊は何⾊でしょうか？ スケール依存 & ⼩規模でもPALが有効

P.48 • 推論過程をプログラム⾔語で表現し Python インタプリタにオフロードする PoT を提案 • ５MWP /３⾦融データセットの評価により Chain of Thoguht を上回る精度を⽰した Program of Thought (PoT) [Chen+’22] https://arxiv.org/abs/2211.12588 フィボナッチ数列における50番⽬の値 を 50 回の推論ステップによって算出 フィボナッチ数列における50番⽬の値を 8 ⾏の Python コードの実⾏により算出 ⼤規模⾔語モデルにおける CoT の問題点 • 特に⼤きな数 を扱うと算術計算の誤りが起こりやすい • 多項式や微分⽅程式のような 複雑な数式 を解くことが難しい • 反復回数が多い 場合は⾮常に⾮効率である Chain of Thought (左) と Program of Thought (右) の⽐較 self-consistency zero-shot CoT と PoT の精度⽐較

P.49 https://arxiv.org/abs/2301.13379 • モデルの予測結果は CoT による推論過程を反映していない場合がある • モデルが本質的に解釈可能であるとヒトに誤解させる可能性がある • 説明の納得度が⾼い場合、モデルに暗黙バイアスがあってもヒトはモデルを過信する（Pruthi+ʼ20; Slack+ʼ20） Faithfulness [Lyu+’23, ICLR] (1/2) 答えは 0 だが、推論過程が反映されていない クレアは毎朝、朝⾷に３つの卵を使ってオムレツを作る。 彼⼥は４週間で何ダースの卵を⾷べるでしょうか？ プログラムとして計算処理をインタプリタにオフロードする plausibility

P.50 • 推論タスクを２段階に分解する構築フレームワークを提案 1. 翻訳 Codex がクエリから 記号⾔語 と ⾃然⾔語 による推論の連鎖を記述する 2. プログラム実⾏ 外部ソルバが推論チェーンを実⾏して解答を出⼒する • 複数の記号⾔語・ドメインに対して汎化可能性を⽰した Faithful CoT [Lyu+’23, ICLR] (2/2) Strategy QA の予測誤りのエラーカテゴリ分析（図9） • Datalog のプログラムエラーが 50% 以上 • ⾃然⾔語による推論・読解 45% 程度 • プログラム実⾏の利点を活かせないタスク設定 ※ 記号演算よりも 事実の抽出や思考連鎖が重要 Python インタプリタ Datalog ⾃然⾔語︓ #i. サブ質問？（サブ質問間の依存関係、根拠） 記号⾔語︓ プログラム 4ドメイン 10 評価セットを⽤いて有効性を検証（表1） 誤答した 100 事例に対するエラーカテゴリ（図6） • ⾃然⾔語によるサブ質問の⽣成・読解によるエラーが 49.0% • プログラムにおける誤りが 24.0% https://arxiv.org/abs/2301.13379

P.51 LEVER [Wang+’23] https://arxiv.org/abs/2210.12810 • ⽣成されたプログラムをその実⾏結果で検証するように学習することでコード⽣成を改善 • ⽣成 ... タスク⼊⼒とデモに基づいてコード LLM からプログラムを⽣成 • 実⾏ ... インタプリタを⽤いて実⾏結果を取得 • 検証 ... タスク⼊⼒・プログラム・実⾏結果に基づいて、学習済検証器を⽤いて正しい確率を出⼒ • Spider, GSM8k, WikiTableQuestion, MBPP の 4 タスクにおいて SoTA を達成 SQL parsing Table QA Math Reasoning Python Programing ⾃然⾔語による質問を SQL クエリに変換する # 質問 -- ⾃然⾔語: クラスに 20 歳から 30 歳の⽣徒は何⼈いますか︖ -- SQL: # 例 -- ⾃然⾔語: What …? -- SQL: SELECT … ❶ ⽣成 ❷ 実⾏ ❸ 検証 𝑃 𝑦 | prompt 𝑥, 𝑥!, 𝑦! !"# 𝑃$% + 𝑦|𝑥 , 𝑃& 𝑣'(|𝑥, + 𝑦, 𝜀 + 𝑦 = 𝑃) + 𝑦, 𝑣'( | 𝑥 ⽣成スコア ⼆値分類スコア (T5/RoBERTa) 温度サンプリングを⽤いて n 個のユニークなプログラムを⽣成 few-shot ⾃然⾔語 プログラム Final Score 実⾏結果 ⾃然⾔語 プログラム 同じ結果 → 0.27 ∗ 0.85 + 0.13 ∗ 0.95 表4. GSM8k の正解率 表4. MBPP の正解率

VisProg 関連研究 ⾔語モデルを⽤いたプログラムベース推論

P.53 Code as Policies [Liang+’22] https://code-as-policies.github.io/ • ロボティクスにおいて⾔語モデルによるコード⽣成の枠組みを利⽤ • ループや条件分岐や、numpy, shapely などを⽤いることで複雑なポリシーを階層的に表現 • 再帰的に新しい関数を定義することで階層化し、定義された関数はコードベースに蓄積される 原⽥憲旺⽒（東京⼤）- Code as Policies: Language Model Programs for Embodied Control / DL 輪読会 (2022) https://www.slideshare.net/DeepLearningJP2016/dlcode-as-policies- language-model-programs-for-embodied-control 図1. Code as Policies の概要 未定義関数を 再帰的に⽣成 （⼊⼒）⾃然⾔語による指⽰ ブロックを空のボウルの上に積み上げて下さい ユーザ 視覚情報の把握 構成要素としての制御を呼び出し 詳細な解説や関連研究は以下を確認されたい︓

P.54

P.55 image_patch = ImagePatch ( image ) toy = image.simply_query ( “What is this toy?” ) answert = llm_query ( ”The real live version of {} does what in the winter?”, toy ) OK-VQA の例: The real live version of this toy does what in the winter? • 視覚タスクにおいて Codex を⽤いて、視覚処理と推論処理をプログラムとして記述する • デモベースプロンプトによる疑似コード⽣成 VisProg と異なり、 即時に実⾏可能な Python プログラムを直接⽣成することで柔軟な推論を⾏う • RefCOCO, GQA, OK-VQA, NexT-QA でゼロショット推論の有効性を実証 ViperGPT [Surís+’23] https://viper.cs.columbia.edu/ image_patch = ImagePatch ( image ) pizza_patches = image_patch.find ( “pizza” ) pizza_patches.sort ( key=lambda pizza: pizza.compute_depth ()) answer = pizza_patches[0] Image Grounding (RefCOCO) の例: pizza front

P.56 ⾺ get_pos BLIP+GradCAM CodeVQA [Subramanian+’23, ACL] https://aclanthology.org/2023.acl-short.65/ • Codex によって⽣成された Python プログラムを実⾏することで視覚推論を⾏う • VisProg, ViperGPT と異なり、プログラム⽣成の利点を調査するため PnP-VQA を⽤いた対照実験を⾏う • 画像・テキストペアで事前学習された視覚モデルの少ない依存関係で推論を実⾏する • COVR, GQA, NLVR2 においてプログラム⽣成の有効性を実証 ⾺⾞ horse_exists = query (img, “⾺⾞”) answer = “no” if horse_exists == “yes”: carriage_pos_x, carriage_pos_y = get_pos (img, “⾺⾞”) horse_pos_x, horse_pos_y = get_pos (img, “⾺”) if carriage_pos_x > horse_pos_x: answer = “yes” プログラム例 (few-shot) Codex ⾺⾞は⾺の右側にあるか？ ⾺⾞ PnP-VQA “yes” Tiong+’22 (EMNLP) query get_pos BLIP+GradCAM x=12 y=11 x=5 y=11 > No GQA 正解率 (評価セット) 20 40 60 80 And Or Other Spatial 図3. GQA において PnP-VQA を凌駕 構成的推論の恩恵 プログラムによる論理推論 表1. 先⾏研究との⽐較

P.57 Plug-and-Play Compositional Reasoning [Lu+’23] https://arxiv.org/abs/2304.09842 (A)パトス（情熱） (B)エトス（信頼） (C)ロゴス（論理） この広告で使われている 主な説得⼒はどれか︖ • 広告 で使われている主な 説得⼒ を特定する問題。 • 説得⼒ のあるアピールには主に 3 つのタイプがある︓エトス、パトス、ロゴス • エトス とは、話し⼿や書き⼿の 信頼性、性格、権威 に対するアピールです。 • パトス は、聴衆の感情、感情、または同情へのアピールです。 • ロゴス とは、事実、統計、論拠を⽤い、論理、理性、合理性に訴えること。 広告 を分析してどの 説得⼒ が使われているかを判断する。この広告 では、 Earthzy paper には Sierra Club の承認シールが貼られている ことに⾔及してい る。これは本製品が環境にやさしく、信頼できる団体に⽀持されていることを暗 ⽰している。この 説得 は Sierra Club の 信頼性 と 権威 に基づいており、 エトス（信頼）の⼀例である。 エトス（信頼） • LLM が質問に対する課題解決の道筋を⾃然⾔語型プログラムで記述することで解答を取得 • ドメインに依存しない 豊富なツール を定義することで質問をサブタスクごとに順次実⾏する • ScienceQA, TabMWP で既存の⾔語媒介推論の⼿法を⼤きく凌駕

P.58 • ツール拡張型 LLM のプロンプトにおいてツール仕様書と利⽤デモ間の性能を⽐較する • ツール数が多い場合はツールセットに対して TF-IDF で選定を⾏う • Cameleon, VisProg においてツール仕様書の利⽤が効果的であることを実証 ツール仕様書 の利⽤ [Hsieh+’23] https://arxiv.org/abs/2308.00675 複数デモを⽤いてツールの利⽤⽅法を提⽰するよりも、 デモなしでツール仕様書を記述する ⽅が有効 Tool 毎に仕様書を記述する 仕様の単語⻑にも依存

NLP モデルのテスト

P.60 Minimum Functionality Test プレースホルダ型テンプレートにより 期待される出⼒が得られるか Invariance Test タイポや固有表現等の摂動を置換・追加 出⼒が変化しないかを確認 Directional Expectation Test 予測結果を変える否定表現等を追加 出⼒が変化・反転するかを確認 Behavioral Testing of NLP Models [Ribeiro+’20, ACL Best Paper] https://aclanthology.org/2020.acl-main.442/ • 分類・抽出型 NLP モデルに対して⾏動テストに基づくチェックリストを提案 Negative Template: I {否定語} {肯定的動詞} the {物事}. love, like, .. food, flight, service, .. • I canʼt say I recommend the food. • I didnʼt love the flight. didnʼt, canʻt say I, .. … negative … neutral ✅ ❌ Chicago Cicago Dallas @AmericanAir thank you we got on a different flight to ... … negative … neutral … positive ❌ ❌ ✅ @JetBlue AA45 … NewYork to Los Angeles. @JetBlue AA45 … NewYork to Los Angeles. You are brilliant. タイポ 置換 … neutral … neutral ✅ ❌ 肯定⽂を追加

P.61 1. Early Answering 2. Adding Mistakes Human: 5! はいくつ？ Assistant: 5! = 1×2×3×4×5. 1×2×3×4×5 = 120. よって解答は 120. Human: 最終解答は? Human: 5! はいくつ？ Assistant: 5! = 1×2×3×4×5. 1×2×3×4×5 = 120. よって解答は 120. Human: 最終解答は? Human: 5! はいくつ？ Assistant: 5! = 1×2×3×4×5. 1×2×3×4×5 = 100. よって解答は 100. Human: 最終解答は? テスト⽅法 CoT の中間推論部分を除去 CoT の中間推論過程の⼀部を 誤った内容に置換 予測変化しない場合 なにが分かるか CoT の中間推論過程に ⼿がかりとなる情報が 含まれていない可能性がある CoT の中間推論過程を モデルが無視している 可能性がある。 https://arxiv.org/abs/2307.13702 • CoT の中間推論過程を⼀部変更することで忠実性に関する４つのテストを提案 Measuring Faithfulness of Chain-of-Thought [Lanham+’23] 図1. CoT の忠実性を測定するためのテスト例（⼀部省略） 図7. ⼊⼒において CoT を除去した際に CoT 有/無 で出⼒結果が異なるかを モデルサイズ別に調査 AQuA: 代数問題 LogiQA: 論理推論 パラメータサイズが⼤きくなるほど CoT の有無が性能に⼤きな影響を与える

P.62 Adaptive Testing [Ribeiro+’22] https://aclanthology.org/2022.acl-long.230/ • LM の⽣成能⼒とヒトの判別能⼒を利⽤し NLP モデルによる単体テストの記述⽅法を提案 • 専⾨家・⾮専⾨家共に 8 タスクで 5~10 倍ほど効率的にバグを発⾒した LLM がテストを提案 良いテストをユーザが抽出 テストツリーを構築 対象モデルを再テスト テスト中のバグを修正 Riberio+ʼ20 による初期化 f(“私は⿊⼈⼥性です”) ≠ neg f(“友⼈はキリスト教の牧師です”) ≠ neg f(“沈黙に疲れた”) ≠ neg f(“私は⼈種的マイノリティです”) ≠ neg f(“私は⼈種的マイノリティの⼀⼈である”) ≠ neg f(“私は⼈種的マイノリティです”) ≠ neg f(“私は⾮正規滞在者である”) ≠ neg f(“私は⾮正規滞在の⼥性です”) ≠ neg f(“恐怖の中で⽣き続けることはできない”) ≠ neg f(“私は⾮正規雇⽤の新⼊社員です”) ≠ neg sensitive/immigration f(“私は⾮正規雇⽤の新⼊社員です”) ≠ neg f(“私は難⺠の受け⼊れに賛成です”) ≠ neg sensitive/racial sensitive ・有効なテストを抽出 ・サブトピック毎に整理 ・選択トピックにおける テストを⽣成して提案 ⽣成対象を選択 ・有効なテストをスコア ベースに選択して追加 sensitive/immigration 対象 モデル 中⽴的な移⺠発⾔は neg と予測すべきでない Testing Loop f(“私は⾮正規雇⽤の新⼊社員です”) ≠ neg f(“私は難⺠受け⼊れに賛成です”) ≠ neg sensitive/immigration f(“私は⾮正規雇⽤の新⼊社員です”) ≠ neg f(“私は難⺠受け⼊れに賛成です”) ≠ neg sensitive/immigration Debugging Loop 移⺠受け⼊れに否定的な発⾔は neu と予測されている f(“私は全ての強制送還に反対です”) ≠ neg f(“イスラム教徒の⼊国禁⽌に反対”) ≠ neg sensitive/immigration f(“私は全ての強制送還に反対です”) ≠ neg f(“イスラム教徒の⼊国禁⽌に反対”) ≠ neg sensitive/immigration Debugging Loop 対象モデル 微調整 対象モデル 微調整 Pass | Fail

P.63 LLM における ブラックボックステスト Ribeiro+’23 - Testing Language Models (and Prompts) Like We Test Software / TowardsDataScience Blog https://towardsdatascience.com/testing-large-language-models-like-we-test-software-92745d28a359 以下の⽂章を要約して下さい ・半⾓数字の項番付き箇条書きで記述すること ==== Iʼm sorry man, but youʼll have to do that guidance demo without me ... Iʼm going rock climbing with our children tomorrow. • 出⼒がどうあるべきかを想定してブラックボックステスト⽤の⼊出⼒ペアを作成する • 出⼒を変化させる・変化させないような摂動を加えた⼊出⼒ペアを作成する • ⽣成内容に対するテストが難しい場合は プロパティに対するテスト を⾏う Sorry, I canʼt do the guidance demo tomorrow. • 出⼒内容の⽂字数が少なくなったか︖ • 出⼒形式は制約に従っているか︖ 情報を損なうことなく⾔い換えているか︖ → 精緻なテストが難しい → 分類器を作成して性能が妥協できるか確認 プロパティに対してはテスト可能︓

P.64 • ツール拡張型 LLM の枠組みを⽤いて Bot 応答等に対する factuality* チェックを⾏う • ツールを⽤いて主張に対して裏付けとなる証拠を収集 する • ４タスク（知識ベース QA、コード⽣成、算術演算を伴う推論、引⽤を伴う⼩論⽂⽣成）を対象に検証 FacTool [Chern+’23] *factuality … ⽣成シグナル（テキスト・コード・数式等）の主張が、特定ルール下において、ある証拠によって指⽰されること e.g. 知識ベースとの整合性、Python ライブラリ内で指定されたユニットテスト、etc... コード⽣成タスクにおける FacTool の枠組み 1 2 3 4 5 ツールへの クエリ⽣成 クエリを⽤いて ツール実⾏ 実⾏結果から 証拠収集 factuality 検証 ! FacTool 評価対象から 主張抽出 プロンプト 評価対象 主張 1. 2. ツールクエリ 1. 2. 実⾏結果 1. 2. 証拠 1. 2. factual is

P.65 FacTool [Chern+’23] FacTool を⽤いたファクトチェック https://github.com/GAIR-NLP/factool#chatgpt-plugin-with-factool

(コード⽣成型) LLM における内省・反復改良 self-correction に関するサーベイ論⽂は以下︓ Pan+’23 - Automatically Correcting Large Language Models: Surveying the landscape of diverse self-correction strategies https://arxiv.org/abs/2308.03188

P.67 • ReAct 推論において各出⼒に対し、不合理な予測の検出・reflection・推論の再実⾏を導⼊ • Heuristic が不合理な予測を検出した場合、エージェントは self-reflect を実⾏する • (失敗例, reflection) の 2-shot プロンプトを LLM に挿⼊して reflection を⽣成 • reflection をエージェントのメモリに追加し、推論を再実⾏する Reflexion [Shinn+’23] (1/2) https://arxiv.org/abs/2303.11366 hallucination や ⾮効率なプランを検出 ⾏動の繰り返しを検出 試⾏あたりの act 数を制限 バイナリ報酬 各⾏動に 0:失敗, 1:成功 を割り当て HotPotQA では EM を⽤いて採点 𝐿𝐿𝑀 𝑠*, 𝑟*, 𝑎+, 𝑜+, … , 𝑎*, 𝑜* , 𝑚𝑒𝑚 h 𝑠* , 𝑎* , 𝛺, 𝜀, 𝑎+ , 𝑜+ , … , 𝑎*,( , 𝑜*,( = ; 1 1 0 repeat 𝑎+, 𝑜+, … , 𝑎*,(, 𝑜*,( > 𝛺 𝑡 > 𝜀 otherwise 図3. reflection によって⼤幅に正解率が向上する （HotPotQA 完全⼀致評価）

P.68 質問 ローマ議定書は 3 名の⾸相によって署名された。うち 1 名はなぜ暗殺された︖（HotPotQA） 𝑡 = 1 思考 ローマ議定書を検索して、3 名の⾸相を⾒つけ彼らが暗殺された理由を⾒つける。 ⾏動 Search [ローマ議定書] 結果 1934.03.17 にローマでイタリア、オーストリア、ハンガリーの三国間で締結された国際協定。 べニート・ムッソリーニ (伊)、エンゲルベルト・ドルフース (墺)、ゲンベシュ・ジュラ (洪) の 3 名の⾸相によって署名。 すべての議定書は 1934.07.12 に発効し、1934.12.12 に国際連盟の条約シリーズに登録された。 𝑡 = 2 思考 3 名の⾸相はムッソリーニ,ドルフース, ジュラだった。 ムッソリーニを検索し、彼がなぜ暗殺されたかを⾒つける必要がある。 ⾏動 Search [べニート・ムッソリーニ] 結果 べニート・ムッソリーニ(1883.07.29 ‒ 1945.04.28) は、イタリアの政治家・ジャーナリストで、National Fascist Party を創設。 1922 年のローマ進軍から 1943 年までイタリア⾸相を務め、 1919 年の Italian Fasces of Combat 設⽴から、 1945 年にイタリア・パルチザンによって処刑されるまで Duceöf Italian fascism として活動した。 𝑡 = 3 思考 ムッソリーニは、第⼆次世界⼤戦中の枢軸国崩壊の⼀環として暗殺された。 ゆえにローマ議定書は 3 名の⾸相によって署名され、うち 1 名は第⼆次世界⼤戦の⼀部として暗殺されたのです。 ⾏動 Finish [第⼆次世界⼤戦] reflection 調印に関わった⾸相の⼀⼈を検索してすぐに回答しようとした。 各⾸相を検索し、それぞれのページで死亡情報を調べ、より多くの情報を得てから回答すべきでした。 • ReAct 推論において各出⼒に対し、不合理な予測の検出・reflection・推論の再実⾏を導⼊ Reflexion [Shinn+’23] (2/2) https://arxiv.org/abs/2303.11366

P.69 • １つの LLM を⽤いて Feedback, Refine を繰り返す反復改良法を提案 • Feedback 時刻 t の⽣成⽂に対して改善指摘と複数観点によるスコアを⽣成 • ①反復回数の閾値 ② “every thing looks good” というフィードバック ③ スコアによる閾値、のいずれかで終了判定 • Refine 時刻 t の⽣成⽂に対して Feedback を反映して、時刻 t+1 における改良⽂を⽣成 Self-Refine [Madaan+’23] https://selfrefine.info/ 時刻 t+1 の出⼒ ⼊⼒ + 時刻 t の出⼒ フィードバック 過去の出⼒もプロンプ トとして⼊⼒される チューリングテストっぽいことをしている ※ Base LLM の評価値が分からなかった…。 Human Eval. 表3. 反復改良の有無における評価 表4. 各時刻ごとに改善が確認 表6. フィードバック別改善 Generic Feedback: （例）どこかしら間違っています Actionable Feedback: 問題箇所の指摘 + 改善のための指⽰ 左２つの % が何を表してるのか分からなかった... Self-Refine の各結果に対してアノテーションした割合︖

P.70 Self-Repair [Olausson+’23] https://arxiv.org/abs/2305.17126 • 単体テストの合格率をサンプリングされたトークン総数 t に対して重み付けした pass@t を提案 • サンプルコード数 k に対する合格率* pass@k に対して、pass@t では修復における追加作業分を考慮 • APPS で GPT-{3.5, 4} の⾃⼰修復性能を調査し GPT-4 で⾃⼰修復の有効性を⽰した • GPT-3.5 でプログラム⽣成 → GPT-4 の FB → プログラマの FB によって⼤幅な性能向上が可能であると⽰唆 ユーザ タスク指⽰ コード⽣成 実⾏ FB (フィードバック) コード再⽣成 *pass@k (Kulal+’19) k個のコードサンプルのうち、いずれかのサンプルが 単体テストに合格した場合に正解としたときの正解率 図1. ⾃⼰修復に基づく典型的なアプローチ GPT-3.5 は修復がうまくいかない 図3,4. 同じ予算で補間されたベースライン (w/o 修復) に対して正規化された平均合格率 ※ 算出⽅法がよく分からなかった… 同じ予算において... <1 修復が不要 =1 修復有=修復無 >1 修復が有効 GPT-4 は初期プログラム数を 増やした場合に修復が有効 表1. GPT-4, ヒトによるフィードバックの合格率⽐較 図5. コード⽣成器・FB ⽣成器のモデル別合格率⽐較

P.71 Self-Edit [Zhang+’23, ACL] https://aclanthology.org/2023.acl-long.45 • プログラマによるコード⽣成⼿順を踏襲した３段階のコード⽣成を提案 • ⽣成 ... パラメータ固定した LLM を⽤いて、タスク説明 から 初期コード を⽣成 • 実⾏ ... ブラックボックステストを実⾏し、その結果を コメント として記述 • 編集 ... 微調整した PyCodeGPT が タスク説明・初期コード・コメント から 修正版コード を⽣成 • APPS-test, HumanEval において有効性を検証 プログラマ 提案法 初期コード記述 LLM による 初期コード⽣成 テスト事例を 作成して実⾏ デバッグ & 修正 提出 提出 修正モデルを⽤いて 初期コードを修正 ブラックボックス テストを実⾏ 図1 (a) プログラマによるコード⽣成と Self-Edit の⽐較 図2. Self-Edit の概要図 初期コード ... print n+k コメント Line3. print n+k SyntaxError: Missing parentheses in call to ‘print’. Do you mean print(n+k)? Fix the bug. タスク説明 ... find the smallest integer x greater than n, so it is divisible by the number k ... ----- テスト事例 ----- Input: 5 3 Output: 6 … ① LLM が 初期コードを生成 ② ブラックボックス テストを実行 ③ 微調整済みモデルが 初期コードを修正 修正版コード ... print(n+k) 図7. アブレーション (Pass@k) 修正による⼤幅な pass@k 改善 図6. リランキングベースの既存⼿法との⽐較

P.72 問題記述 ユニットテスト 1. プログラム 候補⽣成 2. コード実⾏ フィードバック プログラム 3. コード解説 解説 LLM Self-Debugging [Chen+’23] https://arxiv.org/abs/2304.05128 Rubber duck debugging アヒルに向かって コードを⼀⾏ずつ説明することで デバッグを⾏う⼿法 https://ja.wikipedia.org/wiki/ラバーダック・デバッグ 図1. Self-Debugging の概要図 表1. Spider (text-to-SQL) の正解率⽐較 表2. MBPP (text-to-Python) の正解率⽐較 正解・不正解の情報を与える + コード解説 正解・不正解の情報を与える ユニットテスト ユニットテスト + コード解説 Codex ユニットテスト・コード解説のいずれも有効 text-to-SQL C++-to-Python text-to-Python 質問に対する予測結果のタイプを推測する [Question] Which customers have both “On Road” and “Shipped” as order status? List the customer names. [Question Explanation] “List the customer names” は 1 つのカラムを返します。 質問は order_status に ‘On Road’ と ʻShippedʼ の両ステータスを持つ顧客名が含まれた 1 カラムのテーブルを返す。 実⾏結果のタイプを要約する [SQL #0] SELECT customers.customer_name FROM customers JOIN orders ON customers.customer_id = orders.customer_id WHERE orders.order_status = ‘On Road’ OR orders.order_status = ʻShippedʼ [⽣成コードの説明 #0] • 上記を実⾏すると、1 つのカラムを持つテーブルが返る • 最初のカラム customers.customer_name には 顧客名 が格納される • customers JOIN orders で、テーブルには orders を持つ顧客のデータが結合される • WHERE orders.order_status = ‘On Road’ OR orders.order_status = ʻShippedʼ で、テーブルは order_status が ‘On Road’ または ʻShippedʼの顧客のみを含むようにレコードをフィルタリングする • したがって、上記の SQL クエリは 1 つのカラムを持つテーブルを返す [Question] Which customers have both “On Road” and “Shipped” as order status? List the customer names. [Explanation summary #0] • #0 の SQL クエリでは、注⽂ステータスが ‘On Road’ または ʻShippedʼ の顧客名の 1 カラムからなるテーブルを返す。 • 質問は order_status に ‘On Road’ と ʻShippedʼ の両ステータスを持つ顧客名が含まれた 1 カラムのテーブルを返す。 [Feedback #0] 上記の SQL クエリは誤っているため修正する必要があります。 [Revised SQL #1] SELECT customers.customer_name FROM customers JOIN orders ON customers.customer_id = orders.customer_id WHERE orders.order_status = ‘On Road’ AND orders.order_status = ʻShippedʼ [Explanation summary #1] • WHERE 句には互いに排他的な条件が含まれているため SQL クエリは空のテーブルを返す。 • 質問は order_status に ‘On Road’ と ʻShippedʼ の両ステータスを持つ顧客名が含まれた 1 カラムのテーブルを返す。 [Feedback #1] 上記の SQL クエリは誤っているため修正する必要があります。 [Revised SQL #2] SELECT customers.customer_name FROM customers JOIN orders ON customers.customer_id = orders.customer_id WHERE orders.order_status = ‘On Road’ INTERSECT SELECT customers.customer_name FROM customers JOIN orders ON customers.customer_id = orders.customer_id WHERE orders.order_status = ‘Shipped’ [Explanation summary #2] • SQL クエリは order_status が ‘On Road’ と ʻShippedʼ の両ステータスを持つ顧客名が含まれた 1 カラムのテーブルを返す。 • 質問は order_status に ‘On Road’ と ʻShippedʼ の両ステータスを持つ顧客名が含まれた 1 カラムのテーブルを返す。 [Feedback #2] 上記の SQL クエリは正しいです！ • ①コード⽣成 ②実⾏ ③デバッグによるプログラム修正を提案 • ユニットテスト や コード解説 によるデバッグの実現 • Spider, TransCode, MBPP で有効性を検証 図3. Spider における 3 段階の Self-Debugging

P.73 • ①プロンプトから知識を⽣成 ②⽣成知識に基づいて⾃⼰改良型プログラマを起動する • 検索拡張による知識ではドメイン不整合や R@~5 が低いため LLM による⽣成拡張を採⽤ • DS-1000, HumanEval, TransCoder において⼀貫した効果を実証 Self-Evolve [Jiang+’ 23] https://arxiv.org/abs/2306.02907 Data Science CodeGen General CodeGen C++-to-Python 問題：{problem description} 解答： {code context} [insert] print(result) 推論コードを記述してその出⼒を変数 `result` に格納するのを⼿伝ってください。 [insert] ブロックに⼊るコードのみを出⼒してください。 他の説明や⾃然⾔語は記述せずにコードのみを出⼒してください。 コードは ``` で囲んでください。 これは {library} コードのスニペットです：{code_snippet} コードで使われている API を表⽰してください。 API を表⽰する際のルールを以下に⽰します： 1. print(), import, __str__, __repr__ などの基本的な API は表⽰せず、 {library} に関する API のみを表⽰すること 2. クラスメソッドは `tk.random.normal`のように、 クラス名とライブラリ名をドット 2 つで区切って追加すること 3. 重複した API は出⼒しないこと 上記のコードが呼び出す API を⼀⾏ずつ⽰します： Code Snippet api list 以下の API の API 仕様書を⾒せてください：{api list} 各 API の例を⽰す必要はありません。 回答は `1.` から始めること。 ドキュメント：{generated doc} 問題：{problem description} 解答: {code context} [insert] print(result) 解答コードを書き、その答えを変数 result に格納するのを⼿伝ってくれませんか？ [insert]ブロックを埋められるコードだけを出⼒してください。 何の説明もなく、⾃然な⾔葉でコードを出⼒してください。 コードは ``` で囲んでください。 generated doc final solution 図4. DS-1000 おける Self-Evolve の第⼀ステップのプロンプト例（和訳） 表1. DS-1000 における pass@1 評価． Self-Evolve・⾃⼰改良が有効 表4. ChatGPT, GPT-4 との性能⽐較 表3. TransCoder における 正解率・pass@1 評価． 表2. HumanEval における pass@1(greedy) , pass@10(grid-search) 評価．

P.74 ALGO [Zhang+’23] • 解答の正しさのみ考慮した 参照⽤オラクル をテストに⽤いて解答候補となるプログラムを⽣成する • Verifier LLM ... 冗⻑だが正確なコードを⽣成する。ChatGPT Code Interpreter のゼロショット推論。 • Coder ... 効率かつ正確なプログラムを⽣成する。直接的・反復的なコード⽣成など • CodeContests, LeetCode で有効性を検証 • 検証プロセスの介⼊なしに⾼精度なコード⽣成を実現することは困難 • CodeT のようなテスト⽣成⾃動化も正確性や網羅性の観点から厳しい • ⽣成コードの検証は⼈⼿作成されたオラクルに依存しており⾼コスト 先⾏研究 問題点 動機）実⾏効率を犠牲にすれば、冗⻑でも正確な参照⽤オラクルを LLM が作成できるのでは︖ 総当たりアルゴリズムでこの問題を解いてください。 コードを⽣成した後は、指定されたサンプルケースのみに対してテストしてください。 独⾃のテストケースは⽣成しないこと。 出⼒を⽐較するときは、改⾏やスペースを考慮しないでください。 ある整備⼠のランクを表す整数配列 𝑟𝑎𝑛𝑘𝑠 が与えられる。𝑟𝑎𝑛𝑘𝑠 𝑖 は 𝑖 番⽬の整備⼠のランクを表す。 ランク 𝑟 の整備⼠は、𝑛 台の⾞を 𝑟 ∗ 𝑛, 分で修理できる。 またガレージで修理待ちの⾞の総数を表す整数 𝑐𝑎𝑟𝑠 が与えられる。 すべての⾞の修理にかかる最短時間を返して下さい。 ### Examples {examples, omitted} 関数を Solution クラスで定義する代わりに、クラス名を BruteforceSolution に変更します。 前述の通り、アルゴリズムを解くには、最も簡単な総当たりアルゴリズムを使⽤してください。 効率の問題は⼀切考慮せず、可能な限り総当たりな解法を講じてください。 解法が正しい限り、⾮常に⼤きな探索空間を⾛査しても構いません。 解答に影響を与える可能性のある変数は何ですか？またそれらはどのように⾛査できますか？ 問題 問題 冗⻑だが正確 効率的だが 改善の余地あり 検証結果 & 失敗したテストケース Verifier 出⼒ Coder 出⼒ プロンプト プロンプト オラクルの⽣成 解答候補の⽣成 ⼊⼒ 参照⽤オラクル 解答候補 ⼊⼒⽣成器 • ChatGPT Code Interpreter • Codex, CodeT • ChatGPT Code Interpreter • PG-TD 競プロ⽤コード GAFA 等⾯接 学習⽤サイトより 図1. ALGO の概要図 図2. LeetCode における 参照⽤オラクルの 正解率は 88.5% https://arxiv.org/abs/2305.14591 表2. ALGO が⽣成したテストケースの品質 図3. オラクル⽣成に使⽤するプロンプトの例（和訳） 表1. CodeContests における pass@k

P.75 • Python 関数として定義されるツールにおいて ①⽣成 ②実⾏に基づく評価 の分業を⾏う • GPT-4 を⽤いて再利⽤可能なツールを⽣成し、推論時は安価な GPT-3.5 を⽤いる LLM as Tool Makers (LATM) [Cai+’23] https://arxiv.org/abs/2305.17126 Dispatcher ツールを 新たに作成する No Yes 定義済みの ツールを利⽤する Tool Maker (e.g. GPT-4) Tool User (e.g. GPT-3.5) タスクに適したツールが すでに存在するか？ タスク タスクを解くための再利⽤可能なツールを作成 エラー時はメッセージを履歴に追加して再⽣成 3 つの検証サンプルを⽤いて単体テストを実⾏ テスト失敗時は履歴に登録して問題を修正 実⾏・検証に成功したツールを登録 1. 提案 2. 検証 3. ラッピング 登録されたツールを利⽤してタスク要求を実⾏する関数を作成 Tool Maker に GPT-4 を⽤いることで Tool User に GPT-3.5 を使⽤しても⾼精度（低コスト） 参考）AI-SCHOLAR - LATMがLLMを使って、機能拡張ツールを⽣成、実⾏します (2023) https://ai-scholar.tech/articles/large-language-models/LLM-ToolMaker

その他の参考⽂献

P.78 • 鈴⽊教授（東北⼤学）- ChatGPT 周辺のファクト（⽤語・技術・課題）/ ⾔語処理学会 緊急セッション (2023) https://www.fai.cds.tohoku.ac.jp/research/activities/#nlp2023 • ⿊橋教授（京都⼤学）- ChatGPT の仕組みと社会へのインパクト / NII 教育機関 DX シンポ (2023) https://www.nii.ac.jp/event/upload/20230303-04_Kurohashi.pdf • NTT ⼈間情報研究所 – NLP と Vision-and-Language の基礎・最新動向 (1) / DEIM Tutorial Part 1: NLP (2023) https://speakerdeck.com/kyoun/deim-tutorial-part-1-nlp • 松尾教授（東京⼤学）- AI の進化と⽇本の戦略 / (2023) https://note.com/akihisa_shiozaki/n/n4c126c27fd3d • 横井助教（東北⼤学）- ChatGPT と⾃然⾔語処理 / ⾔語の意味の計算と最適輸送 / Workshop OT (2023) https://speakerdeck.com/eumesy/chatgpt-and-intro-of-ot-for-nlp • 岡崎教授（東京⼯業⼤学）- ⼤規模⾔語モデルの脅威と驚異 (2023) https://speakerdeck.com/chokkan/20230327_riken_llm • 岩澤講師（東京⼤学）- 基盤モデルの技術と展望 / JSAI 2023 Tutorial (2023) https://speakerdeck.com/yusuke0519/jsai2023-tutorial-ji-pan-moderunoji-shu-tozhan-wang • 今井⽒（東京⼤学） - ChatGPT ⼈間のフィードバックから強化学習した対話AI (2023) https://speakerdeck.com/imai_eruel/chatgpt-imai • ⻄⽥⽒, 壱岐⽒（NTT ⼈間情報研究所）- Collaborative AI: 視覚・⾔語・⾏動の融合 / 第13回 Language and Robotics 研究会 https://speakerdeck.com/kyoun/collaborativeai • Asai, Min, Zhong and Chen – Retrieval-based Language Models and Applications / ACL 2023 Tutorial (2023) https://acl2023-retrieval-lm.github.io/ • Suzuki, Okazaki and Nishida - A Gentle Introduction to Technologies Behind Language Models and Recent Achievement in ChatGPT (PAKDD 2023 Tutorial) https://pakdd2023.org/tutorials/#t2 • ⾼瀬⽒（LINE） - 科学技術の創造プロセス – ChatGPT に使われている技術と研究⽣活 / 東⼯⼤講義 (2023) https://speakerdeck.com/line_developers/technology-used-in-chatgpt-and-life-and-work-of-research-students • Yoshihira（LINE） – ⽣成形 AI の実応⽤に向けて / 画像センシング展 イメージセンシングセミナー (2023) https://speakerdeck.com/line_developers/toward-practical-applications-of-generative-ai • ⼩林助教（東京⼤学）- Foundation Model and Robotics | 基盤モデルとロボティクス / 深層強化学習スプリングセミナー 第6回 (2023) https://speakerdeck.com/mertcooking/foundation-model-and-robotics-ji-pan-moderutoroboteikusu • 松林准教授（東北⼤学）- ChatGPT と教育における信頼性 / NII 教育機関 DX シンポ (2023) https://www.nii.ac.jp/event/upload/20230421-05_Matsubayashi.pdf • 畠⼭⽒（Microsoft）- ChatGPT Impact – その社会的/ビジネス価値を考える (2023) https://speakerdeck.com/dahatake/bizinesujia-zhi-wokao-eru • 蒲⽣⽒（Microsoft）- ChatGPT – Azure OpenAI ⼤全 / (2023) https://speakerdeck.com/hirosatogamo/chatgpt-azure-openai-da-quan • 花ヶ﨑⽒, 松崎⽒（Microsoft）- Azure OpenAI Services Developer Seminar (2023) https://www.youtube.com/watch?v=tFgqdHKsOME • 花ヶ﨑⽒, 松崎⽒, 尹⽒（Microsoft）- Azure OpenAI Services Developer Seminar 2nd (2023) https://www.youtube.com/watch?v=cEynsEWpXdA • 吉⽥准教授（東京⼤学）教員向け ChatGPT 講座 〜基礎から応⽤まで〜 (2023) https://www.youtube.com/watch?v=lwccHzqfuvc • ⼭⽥⽒, 鈴⽊⽒, ⼭⽥⽒, 李⽒ - ⼤規模⾔語モデル⼊⾨ / 技術評論社 (2023) https://gihyo.jp/book/2023/978-4-297-13633-8 • 塩崎議員（⾃⺠党）- ⾃⺠党 AI の進化と実装に関するプロジェクトチーム / note https://note.com/akihisa_shiozaki/n/n4c126c27fd3d • NII 国⽴情報学研究所 - 「教育機関DXシンポ」過去開催⼀覧 https://www.nii.ac.jp/event/other/decs/past.html • 第 1,2 回 LLM 勉強会 / 国⽴情報学研究所 (2023) https://llm-jp.nii.ac.jp/llm/2023/05/21/first-study-group.html

P.79 • Amershi (Microsoft) – Guidelines for Human-AI Interaction (2019) https://www.microsoft.com/en-us/research/uploads/prod/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf • Google – People + AI Guidebook (2019) https://pair.withgoogle.com/guidebook/ • Apple – Human Interface Guidelines (2023) https://developer.apple.com/design/human-interface-guidelines/machine-learning • Eugene Yan (Amazon) – Patterns for Building LLM-based Systems & Products (2023) https://eugeneyan.com/writing/llm-patterns/#defensive-ux-to-anticipate--handle-errors-gracefully デザインガイドライン

P.80 • Ribeiro+’23 - Testing Language Models (and Prompts) Like We Test Software / TowardsDataScience Blog https://towardsdatascience.com/testing-large-language-models-like-we-test-software-92745d28a359 • James Murdza+’23 - Evaluating code generation agents — LangChain and CodeChain https://medium.com/@jamesmurdza/evaluating-llms-on-code-generation-langchain-and-codechain-5a804cb1e31c LLM × テスト