目次を開く
結論
検索、生成、権限、更新、評価を分離し、RAGを継続的に運用する境界を考える。
背景
検索、生成、権限、更新、評価を分離し、RAGを継続的に運用する境界を考える。
設計と検証の論点
構成を検討するときは、次の責任と境界を分けて確認します。
- 前提と対象範囲
- 設計判断
- 検証記録
判断理由
前提と対象範囲と検証記録の関係を軸に、採用案と代替案の責任範囲を比較します。既存の制約を残す理由と、新しい境界で変えられることを分けて記述します。
トレードオフ
設計判断を扱うために増える実装・保守・確認作業と、得られる制御可能性を比較します。障害時の経路と運用担当者の負担を含め、採用しない方がよい条件も示します。
制約
構成だけでは性能や信頼性は決まりません。対象バージョン、入力条件、障害の想定を明示し、変更時には判断の前提を見直します。
関連事例
関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。