ソリューション
企業データに根ざし、運用を前提に構築するAIシステム
私たちは、お客様の文書や記録に基づいて回答し、現場ですでに使われている製品の中で動作し、稼働後も計測・監査・修正ができるAIシステムを設計・構築します。
課題の全体像
説得力のあるAIのデモであれば、ほとんどの組織が数日で作れます。言語モデル、いくつかの文書、チャット画面があれば、もっともらしい回答を見せるには十分です。そのデモと、人が業務で頼れるシステムとの間にある距離こそが、エンジニアリングの領域です。数百万件のコーパスから正しい箇所を見つけ出す検索、すべてのクエリでユーザーに追随する権限、出典を示す回答、そして先週の変更で良くなったのか悪くなったのかを知る手段が求められます。
この領域のシステムには共通の形があります。ナレッジアシスタントは社内コンテンツに基づいて質問に答えます。ドキュメントインテリジェンスは契約書、請求書、保険金請求書類、報告書から構造化データを抽出します。コパイロットは既存の製品に組み込まれ、下書き、要約、次のステップの提案を行います。意思決定支援は、結果に責任を負い続ける人のために根拠を集めます。いずれの場合も、モデルは多数あるコンポーネントの1つであり、システムが機能するかどうかを決めるのは、たいていモデルではありません。
私たちはAIシステムを、確率的なコンポーネントを含むソフトウェアシステムとして扱います。つまり、プロンプトとインデックスのバージョン管理、デリバリーパイプラインでの自動評価、すべてのモデル呼び出しのトレーシング、コストとレイテンシーの明示的なバジェット、どのデータがどのモデルに渡るかの制御を行います。また、決定論的なルール、検索インデックス、データベースクエリのほうがモデルより安価かつ確実に課題を解決できる場合は、早い段階でそうお伝えします。
なぜ難しいのか
エンジニアリング上の課題
検索品質が決める上限
モデルは、渡されていない箇所をもとに正しく答えることはできません。単純な固定長チャンク分割は表や条項を途中で分断し、ベクトル検索だけでは部品番号や約款コードのような厳密な識別子を取りこぼし、古いインデックスは改訂前の文書を返します。品質の低い回答の大半は、モデルではなく検索に原因があります。
検索を経ても維持されるべきアクセス制御
すべてをインデックス化し、何もフィルタリングしないアシスタントは、若手アナリストに取締役会資料を見せてしまいます。ソースシステムが持つ権限をインデックスに引き継ぎ、クエリ時に強制しなければなりません。さらに、文書の機密区分が変わったときや担当者の役割が変わったときにも、権限が正しく保たれる必要があります。
誰も計測できない品質
評価セットがなければ、プロンプトの変更はどれも当て推量になり、リグレッションはどれもユーザーが発見することになります。チームは個別の事例をもとに議論するしかありません。システムには、期待される根拠と回答を伴う厳選された質問セットを用意し、変更のたびに自動で採点する仕組みが必要です。
捏造された回答、根拠のない回答
モデルは、取得したコンテキストが裏付けているかどうかにかかわらず、流暢な文章を生成します。読みやすいからこそ、この失敗は危険です。回答には、実在する箇所にたどり着ける出典、主張がその出典によって裏付けられているかの検査、そして根拠が不十分な場合の定義された挙動が必要です。
プロンプトインジェクションとデータ漏えい
システムが読み込む文書、メール、Webページのいずれにも、モデルに向けた命令が含まれている可能性があります。同じモデルがツールも呼び出せる場合、注入された命令はそのままアクションになります。取得したコンテンツは信頼できない入力として扱い、ツールの権限はモデルではなくユーザーの範囲に限定しなければなりません。
実運用の規模でのコストとレイテンシー
パイロットではわずかな費用だったプロンプトも、1日数万リクエストになれば無視できない費目になります。また、4回のモデル呼び出しを直列につなげば、対話的なレイテンシーバジェットには収まりません。モデルルーティング、キャッシュ、コンテキストの削減、ストリーミングは、請求書が届いてから追加するのではなく、設計段階で組み込む必要があります。
構築の進め方
アーキテクチャ
本番環境のAIシステムでは、取り込み、検索、オーケストレーション、ガードレール、評価を分離し、それぞれを独立して変更・計測できるようにします。モデルはゲートウェイの背後に置き、交換可能なものとして扱います。
- 01
取り込み・インデックス化パイプライン
コネクターが文書ストア、Wiki、チケット管理システム、データベースからコンテンツを取得し、解析とクレンジングを行ったうえで、見出し、条項、表の行といった構造上の境界に沿ってチャンク化します。各チャンクには、出典、バージョン、発効日、アクセス制御のメタデータを持たせます。パイプラインは差分方式のため、文書の編集や削除は全体を再構築することなくインデックスに反映されます。
- 02
ハイブリッド検索とリランキング
クエリはベクトルインデックスとキーワードインデックスの両方に対して実行します。意味検索は言い換えを、語彙検索は厳密な用語を見つけるためです。統合した候補をリランキングモデルで並べ替え、関連性の高い少数だけを生成モデルに渡します。権限フィルターはクエリの後ではなくクエリの内部で適用するため、閲覧制限のあるコンテンツがコンテキストウィンドウに入ることはありません。
- 03
オーケストレーション層
プロンプトの組み立て、モデルの呼び出し、ツールの実行、会話状態の管理を1つのサービスが担います。プロンプトはソース管理下に置くバージョン付きの成果物であり、コードと同じようにリリースします。複数のステップを要するタスクでは、反復回数に上限を設けた明示的なグラフとしてフローをモデル化します。これにより挙動を追跡でき、ループの暴走も起こりません。
- 04
モデルゲートウェイ
すべてのモデル呼び出しは、ルーティング、リトライ、タイムアウト、レート制限、キャッシュ、コスト配賦を扱う単一のゲートウェイを通ります。これにより、分類や抽出は小型のモデルに、推論は大型のモデルに任せることができ、プロバイダーやモデルバージョンの変更も1か所で済みます。データレジデンシーとマスキングのルールを強制する場所でもあります。
- 05
ガードレールとポリシーの適用
入力はインジェクションのパターンと機微なデータについて検査し、出力はユーザーに届く前に、スキーマの妥当性、根拠のない主張、ポリシー違反について検査します。ツール呼び出しは呼び出し元ユーザーの権限で実行し、影響の大きいアクションには確認を求めます。これらの検査は、可能な限り決定論的なコードで実装します。2つ目のモデルは、1つ目のモデルに対する信頼できる番人にはならないためです。
- 06
評価ハーネス
代表的な質問、期待される出典、参照回答からなるデータセットを維持し、プロンプト、検索設定、モデルを変更するたびに採点します。指標は、検索の再現率、根拠への忠実性（groundedness）、回答の正確性、回答を控える挙動を対象とします。ハーネスはデリバリーパイプライン内で実行され、合意したしきい値を超えて劣化したリリースをブロックします。
- 07
オブザーバビリティとフィードバック
すべてのリクエストについて、クエリ、取得したチャンク、プロンプトのバージョン、モデル、トークン数、レイテンシー、結果を含むトレースを記録します。ユーザーからのフィードバックと、サンプリングによる人のレビューをそのトレースに紐づけ、評価セットに還元します。数週間後に特定の回答を説明できるのは、この仕組みがあるからです。
取り込み
- 01
ソース
ドキュメント、データベース、社内API
- 02
パースとチャンク化
構造を保ったままテキストを抽出
- 03
埋め込み
バッチ処理、モデルはバージョン管理
- 04
インデックス化
ACL付きのベクトル・キーワードインデックス
クエリ
- 01
質問
認証済みユーザーとそのアクセス範囲
- 02
検索
ベクトルとキーワードのハイブリッド検索
- 03
リランキング
最も関連性の高いパッセージのみ残す
- 04
生成
引用付きの根拠ある回答
- 05
評価と記録
トレース、スコア、フィードバックを記録
プロジェクトの成果物
- AIが適切な手段である箇所とそうでない箇所を示す提言を含むユースケース評価
- ソース単位のアクセス制御を備えた取り込みパイプラインとインデックス
- 文書化されたAPIの背後で動作する検索・オーケストレーションサービス
- 評価データセットとデリバリーパイプラインでの自動採点
- ガードレール、マスキング、ツール権限のポリシー
- トレーシング、コスト、品質のダッシュボード
- モデルのアップグレード、インデックスの再構築、インシデント対応を網羅した運用ランブック
着手する前に
早い段階で決めておくべきこと
- 検索（RAG）か、ファインチューニングか、両方か
- 回答が、変化する事実や出典の明示が必要な事実に依存する場合は検索を使います。企業ナレッジの大半がこれに該当します。プロンプトでは維持できない一貫した書式、トーン、専門的な分類が必要で、かつ学習に使えるラベル付きの事例がある場合は、ファインチューニングを検討します。両者は補完関係にあります。ファインチューニングしたモデルであっても、今日の時点で何が正しいかを知るには検索が必要です。
- ホスト型のモデルAPIか、セルフホストのモデルか
- ホスト型APIは、インフラを運用することなく最も高性能なモデルを利用でき、プロバイダーのデータ取り扱い条件を受け入れられるワークロードの大半に適しています。オープンウェイトモデルのセルフホストが妥当なのは、データを自社環境の外に出せない場合、GPUキャパシティに見合うだけの処理量がある場合、レイテンシーを厳密に制御する必要がある場合です。ただし現実の運用コストが伴います。キャパシティプランニング、モデルサービング、アップグレードが自社の責任になります。
- システムにどこまで自律性を与えるか
- まずは、システムが提案し、人が承認する形から始めます。個々のアクションを自動実行に移すのは、取り消しが可能で、影響が小さく、評価による裏付けがある場合に限ります。資金を動かす、顧客レコードを変更する、社外に連絡を送るといったアクションについては、エラー率が把握され、責任を負う人がそれを受け入れるまで、人による承認ステップを残すべきです。
- プラットフォームを作るか、単一のアプリケーションを作るか
- 視野に入っているユースケースが1つであれば、そのアプリケーションをしっかり作り、ゲートウェイ、評価、トレーシングは切り離せるコンポーネントとして保ちます。共有プラットフォームが正当化されるのは、2つ目、3つ目のユースケースが取り込み、アクセス制御、ガバナンスを重複して作ることになる段階です。プラットフォームを先に作ると、ユーザーのいないインフラができあがりがちです。
FAQ
よくあるご質問
システムの回答範囲を自社データに限定できますか。
はい。システムは取得したコンテンツに基づいて回答し、そこに答えが含まれていない場合はその旨を伝えるように設計します。回答には出典箇所への引用が付き、根拠への忠実性のチェックが、根拠の範囲を超えた回答を検出します。どのような設計でもリスクを完全に取り除くことはできないため、評価とレビューは運用の一部として継続します。
どのモデルに対応していますか。
アーキテクチャは特定のモデルに依存しません。ゲートウェイがアプリケーションを個々のプロバイダーから切り離すため、商用APIとオープンウェイトモデルのどちらを使うかは、品質、コスト、レイテンシー、データ取り扱いの要件に基づいてタスクごとに判断でき、モデルの変化に応じて見直すこともできます。
機微なデータや規制対象のデータはどのように扱いますか。
取り込み時にデータ分類を適用し、検索時にアクセス制御を強制し、コンテンツをモデルに送る前にマスキングのルールを実行します。データが選択したクラウドリージョンやプライベート環境の中にとどまるようにデプロイを構成することも可能です。私たちは、お客様のコンプライアンス上の義務を支えるようにシステムを設計します。義務の内容そのものは、お客様とそのアドバイザーが定めるものです。
モデルプロバイダーが新しいバージョンをリリースした場合はどうなりますか。
新しいバージョンは、トラフィックを流す前に評価データセットで検証します。スコアが維持されていればゲートウェイの背後で段階的にリリースし、劣化していれば先にプロンプトや検索設定を調整します。比較が完了するまで、従来のバージョンは固定したままにします。