AI901-Concept#95-2
注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。
前提
ある SaaS 企業が、顧客向けサポート チャットを Azure AI Foundry で構築しています。応答スタイルを企業の brand voice (丁寧 / 簡潔 / 専門用語を平易に言い換える) に統一する必要があり、参照ナレッジは社内ドキュメントから随時取得する必要があります。
解決策
応答スタイル統一と社内ドキュメント参照の両方を達成するため、社内ドキュメント全文を fine-tuning データセットとしてベース モデルに焼き込み、prompt engineering / RAG は一切使用しません。
この解決策は目的を満たしますか?
解説
【判定: いいえ】の理由
本提案は要件 (最新性 + 最新知識参照) と適合せず、コスト面でも不利です。fine-tuning は重みに知識を焼く操作で、ドキュメント更新があるたびに再訓練が必要となり、毎日 / 毎週の更新ループは現実的でありません。Microsoft 公式は「事実情報は RAG、スタイルは fine-tuning」と明確に分けており、本シナリオはまさに RAG の典型ユース ケースです。さらに「prompt engineering / RAG を使わない」という選択は、低コストの手段を捨てて高コストの手段に固執する設計判断で、運用と費用の両面で誤りです。
【「はい」が違う理由】
fine-tuning 単独では最新性確保が困難で、コスト効率も悪く、要件に対する設計として失格です。SaaS 規模の運用にも適さないため、「目的を満たす」と判定するのは妥当ではありません。 fine-tuning の運用コストは SaaS 業界での持続性も損ねるため不適切です。
本提案は要件 (最新性 + 最新知識参照) と適合せず、コスト面でも不利です。fine-tuning は重みに知識を焼く操作で、ドキュメント更新があるたびに再訓練が必要となり、毎日 / 毎週の更新ループは現実的でありません。Microsoft 公式は「事実情報は RAG、スタイルは fine-tuning」と明確に分けており、本シナリオはまさに RAG の典型ユース ケースです。さらに「prompt engineering / RAG を使わない」という選択は、低コストの手段を捨てて高コストの手段に固執する設計判断で、運用と費用の両面で誤りです。
【「はい」が違う理由】
fine-tuning 単独では最新性確保が困難で、コスト効率も悪く、要件に対する設計として失格です。SaaS 規模の運用にも適さないため、「目的を満たす」と判定するのは妥当ではありません。 fine-tuning の運用コストは SaaS 業界での持続性も損ねるため不適切です。
コメント