AI901-Concept#47-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある企業が長文の社内ドキュメント (1 件あたり約 30,000 文字) を Azure OpenAI で要約するアプリケーションを Microsoft Foundry SDK で構築しています。モデルのコンテキスト ウィンドウとトークン経済性を踏まえた設計が必要です。
解決策
コンテキスト ウィンドウが 4K トークンしかない古い GPT-3.5 モデルを選択し、30,000 文字のドキュメントを全文プロンプトとして 1 回で投入して要約を生成します。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
4K トークン (約 1.5 万文字程度) のコンテキスト ウィンドウでは、30,000 文字のドキュメントを 1 回で送信できず、API 側で truncation エラーになるか、入力が途中で打ち切られて要約が不完全になります。コンテキスト ウィンドウを超える文書を扱う場合は、map-reduce 形式の分割要約、または長 context モデル (GPT-4o 等) への切り替え、または RAG で関連部分のみを抽出する設計が必要です。古いモデルを安易に流用するのは設計ミスで、Foundry のモデル選定でコスト と context size を両方検討すべきです。
【「はい」が違う理由】
コンテキスト ウィンドウ超過は技術的にエラーまたは情報欠落を引き起こし、要約品質を保証できません。本番アプリでは安定性も担保できず、「目的を満たす」と判定する根拠はありません。
4K トークン (約 1.5 万文字程度) のコンテキスト ウィンドウでは、30,000 文字のドキュメントを 1 回で送信できず、API 側で truncation エラーになるか、入力が途中で打ち切られて要約が不完全になります。コンテキスト ウィンドウを超える文書を扱う場合は、map-reduce 形式の分割要約、または長 context モデル (GPT-4o 等) への切り替え、または RAG で関連部分のみを抽出する設計が必要です。古いモデルを安易に流用するのは設計ミスで、Foundry のモデル選定でコスト と context size を両方検討すべきです。
【「はい」が違う理由】
コンテキスト ウィンドウ超過は技術的にエラーまたは情報欠落を引き起こし、要約品質を保証できません。本番アプリでは安定性も担保できず、「目的を満たす」と判定する根拠はありません。

コメント