採用中ポジション一覧カジュアル面談
採用中ポジション一覧カジュアル面談

2025-07-15 機械学習勉強会

今週のTOPIC

※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
技術的に学びのあるトピックを解説する時間にできると🙆（AIツール紹介等はslack channelでの共有など別機会にて推奨）
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi

[docs] Context Engineering Guide

  • コンテキスト エンジニアリングは、多くの場合、単純なプロンプトを超えて、システムの知識を取得、強化、最適化するためのより厳密な方法が必要。評価プロセスまで含まれる。
    • 開発者的には、LLMへの命令とコンテキストを最適化して望ましい結果を得るための最適化プロセス (Feature Engineeringのようなもの)
  • Deep Research AgentのContext Engineeringの例
    • Planner AgentのSystem Promptは以下のように分かれる
      • Instructions
        • ここで終わってしまう人がほとんど
      • Structured Inputs and Outputs
        • サブタスクをどのように生成するかの指示を事細かに。これが重要。
          • 加えて、どのような出力を期待するかも合わせてコンテキストに入れる
          • Tools
            • 日付と時刻は非常にシステムにとって重要なコンテキスト。これを渡さないと先週の記事を調べてと言っても調べることができない。
            • RAG & Memory
              • ここではより効率化、コストを削減するためのテクニックとしてのRAG&Memory
              • 似たようなユーザクエリに対しては、ベクトルストアから検索してその結果を流用する。
            • States & Historical Context
              • Deep Research Agent V1では、最終的に結果を最適化することがとても重要。この場合、Agentはクエリ、サブタスク、検索結果全て、また過去の状態、場合によっては履歴コンテキスト全てにアクセスする必要がある。
              • 何を渡すかは最適化の対象によって変わるし、どれくらい反復するべきかも変わる。
              • だからこそ評価することがとても重要。
        @Yuya Matsumura

        [blog] How To Build Agents Users Can Trust

        • ミスが許されない領域において真のビジネス価値を生み出すAIエージェントの構築方法に関するrampの記事
        • LLMが活躍できる場を選ぶ（Choose problems where LLMs can shine）
          • 以下の特徴を持つ場合、fitする可能性が高い。
            • 1. 曖昧さがある：単純なヒューリスティックが適用できない場合。
            • 2. 高ボリューム：人間が行うには膨大な時間がかかる場合。
            • 3. 非対称的なアップサイド：AIプロダクトによる自動化の恩恵が、エラーが発生した際のリスク・コストをはるかに上回る場合
              • 医療器具のプロダクトにおいて最悪ケースは人がなくなることだが、新機能開発においては？経理領域においては？
          • → 経理領域はfitしていると考える。
            • 適切なガードレールさえ敷くことができれば壊滅的な失敗の可能性が低く、ユーザーにとっては時間の浪費として感じれないなくすべき・なくせたら嬉しい領域であるから。
            • 実際 Ramp では、経費精算申請の承認の65%以上がエージェントで自動化されている。
        • 「思考のプロセス」を示す（Show your work）：LLMの推論結果をどのように伝えるのかは、最終的な正確性よりも重要になることがある。つまり、確信が持てないときはきちんとユーザーに質問するなどの振る舞いが、ユーザーからの信頼を得るのとシステムとしての信頼性を高めるために重要である。
          • 理由とともに結果を説明する（Explain outcomes with reasoning）
            • 単に「この経費を承認すべきです」とユーザーに伝えるだけでは不十分
            • 開発者にとっても、継続的なプロンプト・コンテキストエンジニアリングのために指針になるし、ユーザーにとってもどこに注意を払うべきかの指針となる。
          • 情報源を引用する（Cite your sources）
            • すべての事実と数値は、製品やユーザーから得られる簡単に検証可能なコンテキストに基づいているべきです。
            • たとえば、Rampのポリシーエージェントは、推論が参照するユーザーの経費ポリシーのセクションに直接リンクしています。（例では info が社内規程へのリンクとなっている）
          • 「エスケープハッチ」を構築する（Build escape hatches）
            • 分からないときに無理やり答えさせない。
              • rampでは早い段階でLLMに「よくわかりません」と言い、その理由を説明できるようにしました。エージェントが確信が持てないときは、ユーザーが慣れ親しんでいるエージェントへのエスカレーション・プロセスに戻ります。
            • 「わからない」状態をエラー状態のように見せない
              • その状態が重要な情報となり、ユーザーの意思決定の指針となる。そして信頼を獲得できる。
              • カフェの経費精算って言ってるのにゴルフの領収書が提出されたという実際の例
          • 信頼度スコアはハルシネーション（Confidence scores are hallucinations）
            • 信頼スコアを定量的な数値として出させるのは愚策。
              • 信頼スコアはトラディッショナルな統計モデルの強みである
              • LLMはほぼ常に同じ出力をする状況でも、70-80%の信頼度スコアを出し続けたりする。
            • Ramp では代わりに「承認（Approve）」、「却下（Reject）」、「レビューが必要（Needs review）」といったラベルを利用している。
              • わかりやすいし、ユーザーの行動が明確になる。
        • コンテキストは協調的であるべき（Context should be collaborative）
          • コンテキスト（AIが参照する経費精算ルール等）を一度与えて変わらないものにするのではなく、ユーザーとAIで作り上げていく・改善し続けていくものとするのが最も効果的なアプローチだという結論に至った。そのために、
            • ユーザーがコンテキストを定義できる（経費精算ルールを設定できる）機能を提供
            • そのコンテキストをエージェントによる出力・意思決定に利用する
            • ユーザーがエージェントの出力に満足しない場合、コンテキストを改善できるようにする
          • 実際にRampでは
            • ユーザーがPDF形式などの申請ポリシーをRampにアップロードし、かつ最新に保ち
            • それをエージェントの意思決定に利用させ
            • エージェントの出力に満足しない際にポリシーを修正できるエディターを提供した
        • Give users an autonomy slider
          • どこまでをエージェントに任せるかをコントロールできるようにすることが大切。
          • エージェントに判断させる部分と、厳格なルールベース（これがガードレールにも）、人間の介入をうまく組み合わせられる形に。
          • Start with suggestions, graduate to actions
            • いきなりエージェントを提供しないことも大切。最初はサジェストからはじめ、性能が担保されてユーザーからの信頼が得られたのちにエージェントを導入する。
        • Evals are the new unit tests
          • 従来のアプリケーションのユニットテストと同様に、LLMシステムにもテストが必要。（MLシステムで言われていたことがうまく整理されている）
            • 這い歩き、歩き、走る（Crawl, walk, run）：プロダクトの成熟度に応じて評価の規模を拡大していく。迅速かつ簡単なものから始め、より深いカバレッジとより正確な洞察を提供するように拡張していく。
            • エッジケースを優先する：LLMがエラーや矛盾を起こしやすい曖昧なシナリオに焦点を当てる。
            • 失敗をテストケースに変える：ユーザーが指摘したすべてのエラーは、評価の候補とすべきである。これは、データセットを早期に構築する上で特に役立つ。
            • 信頼するが検証する（Trust but verify）：ユーザーは間違っている場合も、怠惰な場合も、あるいはその両方の場合もあります。フィードバックループに追加のレビューとラベリングステップが必要かどうかを検討します。
              • ユーザーのFBデータが常に正しいとは限らないというアレ。実際にRampの経理チームでも、合理的だが完全にはポリシーに準拠していない経費精算申請を頻繁に承認していることがわかった。
              • → ゴールデンデータセットを複数作成した。
         
         
        @Shun Ito

        [blog] Kimi K2: Open Agentic Intelligence

        • by Moonshot AI
        • Mixture-of-Expert (MoE) Model
          • DeepSeek V3/R1と比べてattention headが半分（128 → 64）になりExpert数は増加（256 → 384）
        • 総パラメータ数1兆、推論時のアクティブパラメータ32億
        • モデルはBaseモデルとInstructモデルの2種類
        • Benchmark
        • Optimizer
          • 以前提案されたMuonでトークン効率が改善（AdamWより2倍速く収束）するが、MoEでは学習が安定しない
          • MuonClipを提案 → q, kの重みに対する正規化を取り入れて学習を安定化
        • Agentic Capability（あまり詳しく書かれていなかった…）
          • Large-Scale Agentic Data Synthesis for Tool Use Learning
            • 生成（用意されたものから選択 or 組み立て？）された環境（Domains・Tools）の中で評価可能なTaskについてAgentを動かし、その結果が良ければ生成データとして利用する
          • General Reinforcement Learning
            • 正解・不正解のはっきりしたvertifiableなタスクに加えて、non-verifiable（調査レポート生成）の評価もしつつ学習させる
            • non-verifiableのタスクは自分で評価結果を生成させる？
              • Going beyond verifiable rewards, our general RL system uses a self-judging mechanism where the model acts as its own critic, providing scalable, rubric-based feedback for non-verifiable tasks.
        • 今日Groq（inference platform）に追加されて200 tokens per secondsくらいあるらしい
         
        @qluto (Ryosuke Fukazawa)

        [blog] LLMを本番品質に育てる PromptOps：”100回の試行錯誤”を支えた仕組みと文化

        論文などでは絶対出てこない生々しい話。
        評価設計、SeｍVerでの丁寧なバージョン管理、LLM-as-a-judgeも交えたスクリプトによる定量評価などを組み合わせて改善サイクルを形にしている。
         
        数多くの人が手を入れられるようNotionでプロンプト管理
        数多くの人が手を入れられるようNotionでプロンプト管理
         
        使用モデルとプロンプトバージョンの組み合わせ評価をGoogle Spreadsheet上で管理
        使用モデルとプロンプトバージョンの組み合わせ評価をGoogle Spreadsheet上で管理
        @Yosuke Yoshida

        生成AIで非定型帳票処理を進化させる：AI inside の取り組み

        • 非定型帳票処理のステップ
          • 全文OCRによる帳票全体の読み取り
            • 帳票全体の文字 & 明細項目の抽出用にテーブル検出
          • LLMによる必要項目の抽出（項目抽出処理）
            • ユーザーが定義した任意(複数可)の項目を抽出
        1. 通常項目に対するアプローチ：二段階推論と自律学習でSLMを進化
            • 全文OCRで取得したテキストをベースに、SLMによる初期の項目抽出処理
              • 採用したSLMは、Polyshere2に比べレイテンシー1/3
              • 独自ベンチマーク「japanese-bizform-table-kie」では、Polysphere2と同等以上の精度
            • 信頼度ベースでLLMを併用
              • SLMの出力に対し、信頼度評価を実施
              • 信頼度が一定基準に満たない場合には、LLMを使用し、再度項目抽出
              • このLLMは同じベンチマークで他の一般的なモデルと比較しても非常に高い性能
            • 非同期の蒸留学習でSLMが成長する
              • LLMの出力結果をSLMへと学習させる
              • LLMに頼る回数が次第に減っていき、コストパフォーマンスを維持したまま精度の高い処理が可能
        1. 明細項目に対するアプローチ：視覚と言語を融合するVLMの活用
            • 明細処理の全体フロー
              • 帳票全体を全文OCRで処理し、表部分（テーブル）を画像として抽出
              • このテーブル画像をVLMの入力として使用し、明細データの抽出処理を実行
            • 合成データによるアノテーション時間の短縮化
              • 約2ヶ月の期間で「10万件の明細画像を生成し、そのデータでの学習まで完了させる」という挑戦
              • 合成データの作成の流れ
                • Llama3.1-405Bにより架空のテーブルデータを作成
                • テーブルのセルや列をランダムに削除するなどを追加で実施
                • テーブル表をHTMLに変換し、ランダムなスタイルを適用してレンダリング
              • 独自ベンチマーク「japanese-bizform-table-kie」においても、明細項目の抽出精度は、Polyshere2の明細抽出機能は、VLMの活用により約3pt向上
              • 生成画像の例
            • 独自のベンチマーク「japanese-bizform-table-kie」における通常項目
        @Takumi Iida (frkake)

        [Slide] 20250714_IMC2025振り返り会_Team_Sony_Matching

        KaggleのImage Matching Challenge 2025の10th placeの手法解説

        問題設定

        3次元再構成を行うだけでなく、どの画像グループを使って3次元再構成を行うかをクラスタリングするコンペ。
        要するに、以下を推定するタスク
        • どの画像同士が同じシーンを撮影しており
        • どのような画角でそれぞれ取られているか
        上図のようなETsデータセットは簡単に類似度の評価を行うことで同じシーンの画像かどうかのクラスタリングができる。
        しかし、下図のような見た目が酷似したデータセットだと画像の類似度だけでペアかどうかを判断するのは難しい。

        解法

        以下のパイプラインのようにペア候補選定をする段階で特徴点マッチングを利用。
         
        1. Top-kの動的調整 (Dynamic Top-k)
            2. グローバル特徴を使って大まかに類似度を判定し、特徴点マッチングを取る候補を選出する。
            そのとき、類似度に応じてtop-kを動的に調整する。
            これ面白い
        1. 特徴点マッチングベースの類似度の評価を行い、厳密にペアかどうかを評価

        結果

        画像のペア抽出
        比較対象：グローバル特徴でクラスタリング
         
        カメラ位置の推定結果
        おおよその位置が誤差なく推定できている。
        一方で、反対方向から撮影された画像群は別クラスタ（別シーン）として扱われてしまう。
         
        感想
        Dynamic Top-kがシンプルなアイデアながら（むしろシンプルだからこそ）面白かった。
        1st placeの手法はMASt3Rを使っているらしい。読まないと。
         
        @ShibuiYusuke

        [論文] Working with AI: Measuring the Occupational Implications of Generative AI

        • Microsoft Researchによる20万件に及ぶユーザとBing Copilotのやり取りの分析。
        • AI適用可能性スコアが高い職業グループ：コンピューター・数学関連、事務・管理サポート、および販売など、知識労働や情報伝達に関わる職種

        3. データと方法 (Data and methods)

        3.1 Bing Copilot データ (Bing Copilot data)

        • Microsoft Bing Copilotとの20万件の匿名化された会話データを分析対象に選定。
        • 分析期間は2024年1月1日から9月30日までの9ヶ月間。
        • データは米国からのものであり、プライバシーが除去済み。
        • 主要な分析に使用されるCopilot-Uniformは、代表的な利用状況を示す約10万件の会話データ。
        • ユーザー満足度を測定するためのCopilot-Thumbsは、thumbs-up/downフィードバックを含む約10万件の会話データ。

        3.1.1 ユーザーの目標とAIのアクション (User goals and AI actions)

        • 会話におけるAIの労働力への影響は、「ユーザーの目標（user goal）」と「AIのアクション（AI action）」の2つの明確な側面を分析。
        • ユーザーの目標：ユーザーがAIの支援を求めているタスク。
        • AIのアクション：会話中にAI自身が実行しているタスク。
        • 両者は異なる場合があり、例えば、ユーザーが情報収集を目標とする場合、AIは情報提供をアクションとする。

        3.2 O*NET および BLS データ (O*NET and BLS data)

        • 米国の労働構造理解のため、O*NET 29.0データベースを利用。
          • O*NET：米国の職業情報提供サイト
          • 日本版O*NET：‣
        • 職業をタスク、詳細な作業活動（DWA）、中間作業活動（IWA）、一般化された作業活動（GWA）の階層に分解。
        • 分析は、複数の職業に共通して適用される中間作業活動（IWA）に焦点を当てる。
        • 米国労働統計局（BLS）の雇用・賃金統計データと組み合わせて使用。

        3.3 作業活動の分類 (Work activity classification)

        • 各会話に対し、GPT-4oベースのLLM分類パイプラインを用いて、ユーザーの目標とAIのアクションに合致するすべての中間作業活動（IWA）を特定。
        • 分類粒度をIWAレベルに設定した理由：高い精度と信頼性、タスクレベル（18,796件）に比べてIWA数（332件）が少なく冗長性が低い、ユーザーの職業不明でも潜在的影響を広く把握可能。
        • 1つの会話に複数のIWAが割り当てられる場合、均等に活動シェアを配分。
        • 人間によるアノテーションと比較し、分類器の妥当性を検証済み。

        3.4 職業のカバレッジとAI適用可能性スコア (Occupational coverage and AI applicability score)

        • AIが職業に与える潜在的影響を測るため、「AI適用可能性スコア」を算出。
        • スコアは、AIが職業の作業活動に非自明なレベルで（カバレッジ）、成功裏に（タスク完了率）、広い範囲で（インパクトスコープ）利用されているかを総合的に評価。
        • カバレッジ：IWAがCopilotデータに非自明に（活動シェア0.05%以上）出現する加重割合。
        • タスク完了率：LLM分類器により、AIがユーザーのタスクを完了した割合を評価。ユーザーの明示的なフィードバック（thumbs feedback）と高い相関。
        • インパクトスコープ：IWA内でCopilotが支援または実行できる作業の割合を6段階のリッカート尺度で評価。
        • 絶対的な影響度ではなく、異なる職業間の相対的な影響度を比較する指標として設計。
         

        4. 結果 (Results)

        4.1 一般化された作業活動 (Generalized Work Activities)

        • Bing Copilotの利用データと米国の労働力データの比較分析。
        • 労働力における実際の作業量が多い領域はLLMチャットボットが苦手な領域
          • 物理的活動（例：物の運搬、一般的な身体活動）
          • 監視活動（例：プロセス監視、機器検査）
          • 人や機械の指導活動（例：機械制御、部下指導）
        • 労働力に比べてCopilotの割合が多い領域
          • 情報収集、情報の解釈、創造的思考、関連知識の更新と活用、コンピューター作業など、知識労働に関連する活動。
        • AIアクションとしてより顕著に利用されているGWA（青色表示）
          • 利用者へのサービス提供（例：「他者への支援・ケア」「助言の提供」「コーチング・トレーニング」）
          • コミュニケーション活動（例：「他者とのコミュニケーション」「上司との連絡」）
        • ユーザーの目標として利用される割合が高いGWA（赤色表示）は、ほとんどが知識作業関連
          • 例：「情報の取得」「創造的思考」「知識の更新と使用」「意思決定」「データ分析」
         

        4.2 中間作業活動 (Intermediate Work Activities)

        4.2.1 満足度、タスク完了率、スコープ (Satisfaction, task completion, and scope)

        • 一般的なIWAの50%以上が肯定的なフィードバックを受けており、Copilotの全体的な有用性を示唆。
        • 特に肯定的なフィードバックが多い活動は、文章の執筆・編集、情報調査、商品評価・購入。逆に低いフィードバックが多い活動は、データ分析や視覚デザインに関連する活動。
        • AIが直接サポートやアドバイスを提供する場合よりも、ユーザーが他者にサポートやアドバイスを提供することを支援する場合の方が、ユーザー満足度が高い傾向。
        • IWAの肯定的なフィードバック率とタスク完了率の間には強い相関関係がある（ユーザー目標IWAで加重r = 0.83、AIアクションIWAで加重r = 0.76）。
        • AIが職業に与える潜在的影響の度合いを示すインパクトスコープの評価。
        • 情報収集や執筆に関連するIWAは高いインパクトスコープを示し、データ分析や視覚デザインに関連するIWAは低いインパクトスコープを示す。
        • AIアクション側のインパクトスコープは、ユーザー目標側よりも一貫して低い傾向。
        • インパクトスコープは、人々がAI支援を最も頻繁に求める活動を予測する上で、タスク完了率や満足度よりも良い指標となる (r = 0.64)。

        4.3 職業 (Occupations)

        • AI適用可能性スコアが最も高い職業は、通訳者・翻訳者、歴史家、サービス販売員、作家・著者、カスタマーサービス担当者、CNCツールプログラマーなど、知識労働やコミュニケーションに焦点を当てた職種。
        • 最もAIの影響を受けにくい職業は、看護助手、マッサージセラピスト、水処理プラント・システムオペレーター、皿洗い、屋根葺き職人など、肉体労働、機械操作、身体的活動を必要とする職種。
        • AIの高い適用可能性スコアを持つ職業の主な要因は、AIの情報伝達能力（例：旅客アテンダント、販売担当者、カスタマーサービス担当者など）。
        • 知識労働に関連するIWA（例：文書の編集、知識の維持、コンピュータープログラミング）も、技術ライター、編集者、データサイエンティストなどの職業に大きく貢献。
        • SOC主要グループ別では、販売関連、コンピューター・数学関連、事務・管理サポートの職業が最も高いAI適用可能性スコアを持つ。
        • 医療サポート、農業、建設など、肉体労働や機械操作を伴う職業はAI適用可能性スコアが低い。

        4.3.1 予測との比較 (Comparing to predictions)

        • Eloundou et al. の予測した職業レベルのAI影響度（E1）と、本研究のAI適用可能性スコアの間には高い相関関係が見られる（職業レベルで加重r = 0.73、SOC主要グループレベルでr = 0.91）。
        • 一部の職業では、本研究の測定結果とEloundouらの予測が乖離する（例：マーケットリサーチアナリスト、CNCツールプログラマーは本研究のスコアが高い一方、旅客アテンダント、スクールバス監視員はAI適用可能性スコアが低く評価される可能性がある）。

        4.3.2 社会経済的相関 (Socioeconomic correlates)

        • AI適用可能性スコアと平均賃金との間には弱く一貫性のない相関が見られる（雇用加重相関は0.07）。
        • 学歴要件との相関では、学士号を必要とする職業が、それ以下の学歴要件の職業よりもAI適用可能性スコアが高い傾向にある（学士号必要職種の平均スコア0.27に対し、それ以下は0.19）。
        • 雇用加重がない場合、賃金や学歴との関係はより明確な傾向を示す。

        5. 考察 (Discussion)

        • AIの役割の限界: AIは単一の職業のすべての作業活動を実行するわけではなく、オーバーラップがある場合でもタスク完了率が100%ではなく、影響範囲も通常は中程度。
        • 分析の限界:
          • 単一のLLMプラットフォーム（Bing Copilot）のデータのみを分析対象。
          • O*NETデータベースに基づく職業の分解は、労働の全体像を完全に捉えているわけではない可能性あり。
          • 会話が仕事環境で行われたかレジャー目的であったかの判別が困難。
          • 会話データのみからAIが作業活動に与える影響の大きさを正確に判断することは困難。
          • O*NETデータが米国中心であり、実際の職務活動から遅れている可能性あり。
        • AIの主な対話での役割:
          • AIの行動: コーチ、トレーナー、アドバイザーとして人間を支援する役割。
          • ユーザーの目標: 情報収集、執筆、コミュニケーションが最も一般的。
        • 活動の成功度: 情報収集と執筆は、ユーザーのフィードバック、タスク完了率、インパクトスコープにおいて最も成功した作業活動として評価。
        • 慎重な解釈の必要性: AIが実行する活動は自動化、支援する活動は拡張につながるという単純な結論は避けられるべき。
        • 今後の研究課題:
          • AIの進展に応じた職業の役割再構築。
          • AIの台頭による新たな職業の出現。
          • AI能力のフロンティアの変化と、それに対する職業の重複度の推移の測定。
          • AI利用の変化を時系列で追跡することによる、新しい能力の活用状況の把握。
         

        メインTOPIC

        @Hiromu Nakamura

        LLMs Get Lost In Multi-Turn Conversation

        Introduction

        本研究は、LLMが現実世界の会話(Multi -Turn & Underspecification: ユーザーの指示が完全には特定されていない状態)で直面する「迷子になる(Lost in Conversation)」現象を明らかにし、その原因が主に信頼性の欠如にあることを示唆している。これは、これまでのLLM評価が現実の利用状況と乖離している可能性を示している。

        本研究の実験:

        本研究では、大規模なシミュレーション実験を行い、LLMの性能を単一ターン設定とマルチターン設定で比較した。

        マルチターンでの性能低下

        実験の結果、評価した全てのトップクラスのLLMは、マルチターン会話において単一ターンと比較して著しく低い性能を示すことが確認された。6つの生成タスク全体で、平均39%の性能低下が見られた。

        Background and Related Work

        • 現在のLLMは会話インターフェースとして使われているにもかかわらず、その評価は依然としてシングルターンに偏っている現状
        • 一部のマルチターン評価も本研究が焦点を当てる「underspecificationを含む、より現実的な会話」ではなく、「エピソード的な会話（各ターンが独立したサブタスクとして評価可能な会話）」に偏っている点を指摘。(後に6章で詳しく)
          • 「エピソード形式の会話」は以前の会話のターンに関連するサブタスクを導入するが、個別に評価できる。
          • エピソード的なタスクでは、単に過去の情報を参照するだけでなく、散らばった情報や不完全な情報を統合して、不明確な指示に対応するという、より複雑な「情報の能動的な融合」のプロセスは必要とされない
         
        • 本研究では、制御された柔軟性と多様性を実現するために、LLMベースのシミュレーターを採用する。
          • 我々がシミュレートする会話は、人間とAIの会話を代表するものではない。 したがって、このシミュレーションはユーザーの行動ではなく、複数ターンの設定におけるLLMの挙動を研究するためのツールとして位置づける。

            • Simulating Underspecified, Multi-Turn Conversation

          • multi-turn &underspecificationにおけるLLMの性能を評価するために、単一ターン指示のデータセットから分割された指示を作る。
            • 分割された指示の最初のシャード（シャード1）は、常に指示に対する高レベルの意図を導入し、後続のシャードはそれぞれ指示に対する明確化を提供。
            • シャードのセットは、完全な指示(fully-specified)で提供されるのと同じ情報を反映しており、情報はシャード間で明示的に分割されています。
            • シャーディング手法 → Appendix B/Appendix C(後で言及)
             
             
          • 分割された指示に基づいて複数ターンの会話を実行するシャーディングシミュレーション環境を実装した。
            • Evaluated Assistantはシミュレーションで評価されるLLM
              • タスクを達成するために必要なコンテキスト（データベーススキーマや利用可能なAPIツールの一覧など）を提供する最小限のシステム命令を最初のターン前に受け取る。
              • 複数ターンの、underspecifiedな会話に参加していることを明示的に知らされない
            • User Simulatorはsharded instruction全体にアクセスでき、会話のターン中にshardをAssistantに渡す役割を担う。
              • GPT-4o-miniを利用。シャーディング全体とこれまでの会話にアクセスできる。
              • 進行中の会話に最も自然に適合する次のシャードを決定する。
              • 情報の内容を変更せずに、会話の中で自然に適合するようにシャードを言い換える役割も担う。
            • Strategy Classifierは回答試行(Answer Attempt)とそれ以外のものに分類し、いずれかに処理を渡す。
            • Answer Attemptの場合は、回答部分のみを抽出するTask Evaluatorを経由してTask Evaluatorに渡す。
            • 会話は、次の2つの条件のいずれかが満たされた場合に終了。
              • task-evaluatorが、assistantの回答試行が正しいと評価した場合、
              • 新しいターンの開始時に、user simulatorが会話で明らかにするshardを使い果たした場合
             
          • シミューレーションタイプ
            • FULLY-SPECIFIED (FULL): LLMには最初のターンで元の指示全体が与えられる。ベースライン性能を評価するために使用。
            • SHARDED: これは、上記で概説されたマルチターンのunderspecificationされた会話をシミュレートする
            • CONCAT: シャーディングによる情報損失/言い換えを評価するため
            • RECAP: 最終的な要約ターンを追加。LLMに最後の応答の機会が与えられる。このような介入が、SHARDEDで観察される性能損失を軽減できるかを評価するため
            • SNOWBALL:各ターンが前のターンからのすべての情報に加えて1つの追加のシャードを明らかにする。
         

        Task and Metric Selection

         
        • 大規模シミュレーション実験のために、6種類のタスク(上記)に対して「シャード化された指示 (sharded instructions)」を作成した。
          • これらの指示は、高品質な既存の単一ターン（fully-specified）ベンチマークから選ばれたものを基にしている。
          • 「シャード化プロセス (sharding process)」という半自動的な手法を用いて、元の指示をシャード化された指示に変換した。このプロセスは、人間によるレビューと編集を含む。
          • 各タスクについて、90〜120個のシャード化された指示セットが準備された。
         
        • 6つのタスク
          • Code: Python関数の生成 (HumanEval、LiveCodeBench からデータを取得)。
          • Database: SQLデータベーススキーマに基づいた自然言語クエリからのSQLクエリ生成 (Spider からデータを取得)。
          • Actions: APIスキーマとユーザー指示に基づいたAPI呼び出し生成 (Berkeley Function Calling Leaderboard (BFCL) からデータを取得)。
          • Math: 初等算術問題からの数値回答生成 (GSM8K からデータを取得)。
          • Data-to-text: 表形式データとメタデータに基づいた表のキャプション（自然言語の文章）生成 (ToTTo からデータを取得)。
          • Summary: 約20の文書とユーザー検索クエリに基づいた引用付き要約生成 (Summary of a Haystack からデータを取得)。このタスクは、ロングコンテキスト能力を評価する唯一のタスクである。
         
        • タスクの性能評価には、元のベンチマークで使用されていた指標を再利用している。
        • さらに、LLMの確率的な性質を利用するために、各指示に対して複数回（N=10回）のシミュレーションを実行し、その結果を用いて平均性能（P）、Aptitude（A）、そしてUnreliability（U）という3つの指標を算出している。
          • 平均性能 (Averaged Performance - P): 全シミュレーション実行の平均スコア。これは、特定の指示におけるモデルの全体的な平均的な性能を示す。
          • アプティチュード (Aptitude - A90): スコアの90パーセンタイル値。ベストケースの会話シミュレーションでモデルが達成するであろう性能を推定する指標であり、モデルが持つタスク遂行能力の潜在的な上限を示す。
          • アンリライアビリティ (Unreliability - U90_10): スコアの90パーセンタイル値と10パーセンタイル値の差。ベストケースの性能とワーストケースの性能との間のギャップを測定しており、モデルの応答の一貫性のなさ、つまり信頼性の低さを示す。
         
        • スコアの共通スケール: 各タスク固有の評価指標は、統一的に0から100のスケールにマッピングされている。
         
        この指標設定により、単に平均的な性能を見るだけでなく、LLMが最高の能力を発揮できた場合の性能（アプティチュード）と、その性能がいかに不安定であるか（アンリライアビリティ）を分離して分析することが可能になっている。
         

        Simulation Scale and Parameters

        このセクションでは、本研究の主要なシミュレーション実験の規模と設定について説明している。
        • 使用した指示（Instructions）の総数: 600件。
          • これらは6種類のタスク（Code, Database, Actions, Math, Data-to-Text, Summary）から選ばれた。
          • シミュレーションの種類: 3つの異なる設定(FULL, CONCAT, SHARDED)で会話をシミュレーションした。
        • 評価対象のLLM数: 15種類。最先端のオープンウェイトとクローズドウェイトのモデルを含む多様なモデルが選ばれた。
        • シミュレーション実行回数: 各LLMと各シミュレーションの種類（FULL, CONCAT, SHARDED）の組み合わせに対して、10回のシミュレーション（N=10）を実行。
        • シミュレーション総数: 200,000回以上の会話シミュレーションが実行された。この大規模な実験により、LLMのマルチターン会話における性能を詳細に分析することが可能になった。
        • デフォルト温度（Temperature）: LLMのテキスト生成時の温度は、デフォルトで T=1 に設定された。これは、ある程度のランダム性を持たせた状態でのモデルの振る舞いを評価するため

        Result

         
        • 性能の顕著な劣化: 実験で評価されたすべてのLLMは、テストされたすべてのタスクにおいて、単一ターンのFULL設定と複数ターンのSHARDED設定を比較した場合、性能が著しく劣化している。平均での劣化率は39%であった。
        • Lost in Conversation
          • 単一ターンの設定で優れた性能（90%以上）を発揮するLLMが、同じタスクであっても、会話が複数ターンになり情報が不完全であるという、より現実的な設定では苦戦することを示している。
        • CONCAT設定との比較
          • sharded instructionを用いて単一ターンで行われるCONCAT設定での性能は、元の完全な指示を用いたFULL設定での性能とほぼ同等であり、平均でFULL設定の95.1%の性能を示した。
          • SHARDED設定での性能劣化は、指示をシャードに分割したことによる情報損失が原因ではなく、複数ターンでのやり取りと情報の不完全さそのものが原因であることが示唆されている。
        • モデルサイズと劣化
          • 小規模なモデル（例: Llama3.1-8B-Instruct, OLMo-2-13B, Claude 3 Haiku）は、CONCAT設定でも比較的大きな劣化（86-92%）を示しており、これは大規模モデルと比較して言い換えに対するロバスト性が低いことを示していると考えられる。
          • しかし、SHARDED設定での大幅な劣化は、より高性能なモデルでも同程度に観察された。
        • タスクによる劣化のばらつき
          • モデルによっては、特定のタスクで劣化が比較的抑制されている。
            • Command-AによるActionsタスクで
            • Claude 3.7 SonnetやGPT-4.1によるCodeタスクで
            • Gemini 2.5 ProによるData-to-Textタスクで
          • この結果は、LLMのマルチターン能力がドメインによって一様ではないことを示唆している。
         

        Aptitude vs. Reliability Analysis

        • FULLやCONCATのようなシングルターン設定
          • 一般的にAptituleの高いモデル（より性能の良いモデル）ほどUnreliabilityが低い、つまり信頼性が高い傾向がある。
        • SHARDEDのようなマルチターン設定
          • Aptituleはシングルターンから平均で16%程度のわずかな低下に留まる。 一方、Unreliabilityは平均で112%と劇的に増加する（2倍以上）。
          • マルチターン設定では、よりAptituleの高いモデルも含め、テストした全てのモデルが高いUnreliabilityを示している。つまり、モデルのシングルターンでの能力が高くても、マルチターンでは同様に信頼性が低下する。
        • 「Lost in Conversation」現象の再定義
          • この分析により、Lost in Conversation現象は、主にAptituleの大きな損失ではなく、モデルのUnreliabilityの劇的な増加に起因することが明らかになった。マルチターンになると、LLMは一貫性を保つのが非常に難しくなる。

        Gradual Sharding Experiment

        指示の粒度（元の指示が何個のシャードに分割されるか）がLLMの性能低下にどう影響するかを追加調査
        • 実験方法:
          • 元の実験から、正確に8つのシャードを持つ31の指示を選出
          • 各指示を2～8シャードの7つのバリアントに拡張し、同一問題に対してシャード数1つ（CONCAT）から8つまでの計248指示セットを作成
          • GPT-4oとGPT-4o-miniの2モデルを使用し、各指示とモデルの組み合わせに対して10回の会話シミュレーションを実施
        • 実験結果 (上に添付したFigure6(c)):
          • わずか2つのシャードでも「Lost in Conversation」現象（能力の軽微な低下と信頼性の大幅な低下）が観察された
          • シャード数が増加しても（粒度が細かくなっても）、性能低下の程度はほぼ一定だった
          • → これは、情報が不完全で、かつ2ターン以上の会話が発生すると、モデルが「迷子」状態になりやすいことを示している
         
        この実験は、LLMが複数ターンの会話で苦戦する原因が、単に多量の情報追跡の難しさではなく、指示が分割され徐々に明らかになるという会話の性質自体にあることを示唆している。
        LLMが会話で直面する課題は、情報単位の細かさよりも、情報の分割と逐次的な提示という会話のダイナミクスに根本的な原因があると考えられる。
        これは今後のLLM開発において、単にコンテキストウィンドウを拡大するだけでなく、会話の流れや情報提示の方法に焦点を当てることの重要性を示唆している。
         

        Implications

        Implications for System and Agent Builders

        • LLMのマルチターン性能の課題は、LangChain のようなエージェントフレームワークにマルチターン処理をオフロードすれば解決するのではないか？という疑問を検証した。
          • → これに対して、ユーザーの発話内容を繰り返すことでLLMの性能を向上させる試み（RECAPおよびSNOWBALLというシミュレーションタイプ）を行い、ある程度の改善は見られたものの(Table 2)、完全には課題を解決できないことを示している。
          • この結果から、エージェントフレームワークに頼るだけでは限界があり、LLM自体がマルチターンインタラクションをネイティブにサポートする必要があることを示唆している。

        Implications for LLM Builders

         
        • LLMの開発において、これまでAptitudeの向上に多くの努力が注がれてきたが、本研究で明らかになった「迷子になる」現象は、モデルのUnrelabilityが主な原因であることを強調している。
        • 実験結果(Table 3)から、temperatureを下げることなどの工夫が、マルチターンUnderSpecificationな設定においてはUnrelabilityの問題を効果的に解決しないことを示している。
        • したがって、LLM開発者に対して、将来のモデル開発においては、AptitudeだけでなくマルチターンのReliability も同時に最適化することの重要性を訴えている。

        Implications for NLP Practitioners

         
        • WMT 2019のドキュメントレベル翻訳のペア文書を活用し、ドイツ語から英語へのドキュメント全体（10文）を翻訳する実験を行なった。
          • タスクがエピソード的である場合（つまり、ターンレベルのサブタスクに分解できる場合）、モデルはマルチターンのコンテキストを処理する必要なく、各サブタスクを完了することで、会話の中で迷子になることを回避できる示唆を得た。
          • シャーディングが可能で、かつLLMが「迷子になる」傾向があるタスクの特性として、以下の3点を挙げている。
            • 生成タスクであること: 情報抽出や分類と異なり、新しい内容の編集や洗練が含まれるタスク。
            • 十分に複雑であること: 複数の明示的な仕様が含まれ、多くのシャードに分割できるタスク。
            • 回答が非分解可能であること: シャードが明らかにされることで、回答全体が変化するようなタスク（翻訳タスクのように、ターンごとに追加される情報が既存の回答に追加されるだけではないタスク）。

        Implications for Users of Conversational Systems

        • LLMベースのプロダクト利用者は、特にマルチターン設定におけるLLMの信頼性の低さを認識しておくべきであることを伝えている。
          • 時間があれば、やり直す
            • 会話が期待通りに進まなかった場合、同じ情報で新しい会話を始める方が、既存の会話を続けるよりも良い結果が得られる可能性がある。これは、LLMが会話の途中で迷子になり、既存の会話のコンテキストに縛られるためである。また、LLMの生成におけるランダム性も、新しい会話を試す動機となる。
          • やり直す前に情報を統合する
            • LLMは複数ターンに分散した情報の処理が苦手であるため、指示の要件を単一の指示に統合することは、モデルのアプティチュードと信頼性を向上させる効果的な戦略である。会話でモデルが迷子になったと感じたら、「これまでに私が伝えた情報をすべてまとめてください」とLLMに依頼し、その応答を新しい会話に貼り付けてから再度指示を出す、という方法が考えられる。

        Appendix(一部だけ)

        Precise Definition of Sharded Instructions

        • 目的:
          • 単一ターンで完結する複雑な指示を、複数ターンの対話で段階的に明らかにするための「シャード化された指示」を明確に定義する。
          • 「シャード化された指示」が、元の指示と同じ情報内容を保持し、評価に適していることを保証するための基準を設ける。
        • 数学的定義:
          • 単一ターン指示 に含まれる「原子内容単位 (atomic content units, ACU)」を と定義。
          • 指示の主要な意図 と、その意図に基づいてタスクの正解 を計算するために十分な一連の補足情報や条件 から構成される。
          • ここで、は主要な意図、 は補足情報である。
          • 「原子」であるとは、その情報内容の表現が変わっても、導かれる正解は同じであること。つまりを次を意味している。
          • シャード化の目的:
            • 与えられた元の指示 に対して、その原子内容単位 を識別し、元の指示と同じ を持つ短い指示シャードのセット を構築すること
         
        • 有効なシャード化指示の満たすべき5つの特性:
          • P1: 情報の保存 (Information Preservation)
            • シャード化プロセスで、指示を完了するために必要な元の指示の情報が失われていないこと。つまり、 であること。
          • P2: 明確な最初の意図 (Clear Initial Intent)
            • 最初のシャード は、指示全体の高レベルな目標（例えば、「Python関数を書いて」）を示す主要な意図であること（ かつ 。
          • P3: 順序の不感性 (Order Insensitive)
            • 最初のシャードを除き、その他のシャードは文脈から切り離されており（decontextualized）、順序を示唆するような相互参照を含まないこと。これにより、シャードの順序を入れ替えても同じ情報内容を伝えることができる。
          • P4: 最大のシャーディング (Maximal Sharding)
            • 可能であれば、元の指示から最大限多くのシャードを抽出することを目指す。各シャードは単一の特定の情報を提供するようにする。
          • P5: 最小限の変換 (Minimal Transformation)
            • シャード化された指示は、元の指示の言語を可能な限り維持し、単純化、変更、解釈を避けること。P1-P4を満たすための変更以外は最小限にとどめ、シャードは元の指示の原子内容単位と意味的に類似しているようにする。

        Semi-Automatic Sharding Process

         
        セミオートマチックなシャーディングプロセスは、以下の4つのステップで構成されている。
        • ステップ1: Segmentation（セグメンテーション）
          • LLM（GPT-4o）に、元の指示から重複しない最小単位の情報セグメントを抽出させる。指示全体をカバーする必要があるが、非必須部分は省略可能。
          • フィルタリング：この段階で3つ未満のセグメントしか生成されない指示は、以降のプロセスから除外される。
        • ステップ2: Rephrasing（リフレーズ）
          • LLMが、セグメント間の依存関係を解消し、シャードがAppendix Bで定義されるプロパティ（特にP2とP5）に適合するように書き換える。例えば、全体の意図を示すセグメントが最初のシャードになるように順序を変更したり、表現を調整したりする。
        • ステップ3: Verification（検証）
          • 生成されたシャード化された指示が、元の指示の情報を正確に保持しているか（プロパティP1）を検証する。
          • 生成されたシャード化された指示に対して予備的なシミュレーションを実行する。
            • 具体的には、元の指示を使用したFULLシミュレーションと、シャードを連結したCONCATシミュレーション、さらにシャードの順序をシャッフルしたSHUFFLE-CONCATシミュレーションをそれぞれ10回実行し、平均性能（P）を比較する。
          • フィルタリング：P CONCATとP SHUFFLE-CONCATがP FULLの80%を下回る場合、情報ロスや不正確な脱文脈化があったと見なし、その指示は除外される。
        • ステップ4: Inspect and Edit（検査と編集）
          • 著者（人間）がウェブベースのインターフェースを用いて、元の指示と生成されたシャード化された指示のペアをレビューする。必要に応じて、個々のシャードの編集、追加、削除を行い、最終的にその指示を採用するか却下するかを決定する。

        Qualitative Analyses of Simulation Logs

        LLMがマルチターン会話で「迷子になる」際に、具体的にどのような振る舞いをするのか を、実際の会話ログを観察することで明らかにし、その原因を特定。
        • 早すぎる回答試行:
          • 会話の初期段階で情報が不十分なうちに最終的な回答を生成しようとし、そこで誤った仮定を導入してしまう。
        • 回答の膨張
          • 過去の（誤った）回答試行に固執し、新しい情報に合わせて修正する際に不要な内容を付け加え、回答が冗長化・複雑化する。
        • 中間ターンの忘却
          • 会話の冒頭や最終盤の情報に偏って注意を払い、途中での重要な指示や訂正を見落としてしまう。
          • Lost in the middle」現象と同様に、複数ターンの会話においても中間ターンで提示された情報を忘れやすいという「loss-in-middle-turns」現象が発生していることを示唆している。
            • 横軸の「Document Cited Introduced in Turn X」は、引用されたドキュメントが会話のターンXで導入されたことを示している。
            • 縦軸の「Summary From Turn Y」は、その要約が会話のターンYで生成されたことを示している。
            • 各セルのパーセンテージは、ターンYで生成された要約に含まれる引用の中で、ターンXで導入されたドキュメントからの引用が占める割合を表している。
        • 過度に冗長な応答
          • 会話の各ターンで不必要に長い応答を生成することで、ユーザーの指示から注意が逸れ、誤った仮定を導入しやすくなる。
          • 論文では、この過度の冗長性による性能低下の要因として、長い応答にはアシスタントによる不要な仮定や推測が含まれやすく、それが後のターンで混乱を招き、会話を脱線させてしまう可能性を仮説として挙げている。
        Xでポスト