ドイツのコンプライアンス企業向けに、法務AIの研究アシスタントを€2,700で作った話

Reddit r/artificial / 2026/4/15

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

要点

  • 著者は、ドイツのGDPRコンプライアンス企業向けに構築した本番用RAG「法務AI研究アシスタント」について述べており、回答生成では、(例:連邦最高裁>下級裁判所、公式ガイドライン>ブログ)といった権威の階層を尊重する必要があると強調している。
  • 彼らは、3つの選択可能なリトリーバル(検索)モード――標準のフラットRAG、カテゴリー優先(トップダウンでの権威競合の解決)、レイヤードカテゴリー(権威ティア間での代表性を保証)――を実装し、意味的に似ているにもかかわらず下位の権威に属する情報源が支配的にならないようにしている。
  • 独自の法務文書チャンク化(分割)パイプラインにより、階層的な条文構造、相互参照、脚注が保持され、LLMに渡す前に、チャンク化した内容を圧縮したキャッシュ済み「チートシート」に組み立てる。
  • システムは二重の埋め込み(エンベッディング)をサポートしており、本番ではAWS Bedrock Titanを使用しつつ、ローカルのフォールバックとしてOllamaも利用する。さらに、管理パネルからモデルをホットスワップでき、プロバイダ/モデルごとのキャッシュ済み埋め込みにはスレッドセーフなロッキングで保護をかけている。
  • 信頼性を高めるため、アシスタントはプロンプトに豊富なメタデータを注入し、正規表現ベースの言語検出で二言語出力を強制する(言語のドリフトを抑止)。また、「引用工学」に多くの工夫を投資し、曖昧な/誤った引用を防ぐためのプロンプト規則を整備している。

先ほどの投稿「法務事務所向けにRAGシステムを作って€2,700稼いだ — 実際に技術的にうまくいったことは何か」で、かなり良い反響(エンゲージメント)があったので、同じようなものを作っている人向けに、実際のアーキテクチャをもう少し掘り下げたいと思いました。

ドイツのGDPRコンプライアンス会社向けにRAGシステムを納品しました。プロダクションでの法務向けRAGの分解記事をあまり見かけなかったこと、そして一般的なRAGチュートリアルではカバーされていない問題に直面したことから、フルスタックを共有します。

課題:法務調査は、単に「関連する文章を見つける」だけではありません。情報源にはそれぞれ法的な重み(格付け)があります。最高裁の判断は下級裁判所の意見よりも強い。公式の規制ガイドラインはブログ記事よりも優先される。システムはこの階層(ヒエラルキー)を理解し、回答生成の際にそれを使う必要があります。

解決方法:

  • クエリごとに選択できる3つの検索(リトリーバル)戦略。Flat(標準的なRAGで、すべての情報源を同等に扱う)、Category Priority(情報源を権威ティア別にグループ化し、LLMが上から順に競合を解決する)、Layered Category(各カテゴリごとに独立して検索することで、1つのカテゴリが類似度スコアを独占しても、すべての権威レベルが必ず表現されるようにする)。カテゴリ優先のアプローチを使わない場合、問い合わせに対して意味的により似ているという理由だけで、システムが下位の権威ソースから回答を作ってしまうことがありました。
  • 法務文書向けのカスタム・チャンク(分割)パイプライン。入れ子になった条項構造、セクション間の相互参照、他の文書を参照する脚注。階層の深さとセクション間の関係を保持するチャンクャーを作りました。チャンクはLLMに渡す前に、圧縮した「チートシート(要約メモ)」として組み立てられます。これらは決定論的なハッシングでキャッシュされるため、繰り返しパターンは再生成をスキップできます。
  • デュアル埋め込み(embedding)対応。プロダクションではAWS BedrockのTitan、フォールバックとしてローカルのOllama。管理パネルからアプリ再起動なしで差し替え可能です。埋め込みはプロバイダとモデルの組み合わせごとにキャッシュされ、スレッドセーフなロッキングにより、モデル切り替えが何かを壊さないようにしています。
  • メタデータ注入レイヤー。ベクトル検索の後、取得した各チャンクに対して、DBからメタデータを完全な形でバッチクエリ1回で付与します。地域、カテゴリ、フレームワーク、日付、タグ、そしてその文書に紐づくすべてのユーザー注釈です。これらはチャンクの内容と一緒にプロンプトへ載せます。
  • バイリンガル対応と厳格な言語強制。クエリ内で正規表現ベースの検出によりドイツ語か英語かを判定します。プロンプトは検出された言語での出力を強制し、フランス語やその他の言語へ逸れることを明示的にブロックします。実際、ソース文書が複数言語である場合、想像以上にこの問題は起こります。
  • ソース引用(シテーション)設計。プロンプトエンジニアリング時間のたぶん40%はここに費やしました。プロンプトには、テスト中に見つけた“手抜き引用”パターンごとに明示的な「絶対にXをしない」指示を入れています。「専門文献によると」というような文書名のない表現は不可。正確な文書タイトル、正確な裁判所名、正確な条文番号を引用する必要があります。法務用途では、曖昧な帰属(attribution)は役に立ちません。
  • SSEによるストリーミングと、任意の簡略化(simplification)パス。回答はSSEでストリーミングされます。2つ目のLLMパスで完了したストリームを横取りし、全文の法的分析を平易な言葉に書き換えたうえで、簡略化版を別トークンとしてストリーミングします。レイテンシは増えますが、弁護士ではない人に対して複雑なGDPR上の義務を平易に説明できるようになります。

構成:FastAPIバックエンド、生成はAWS BedrockでClaude、埋め込みはBedrock Titanで、ローカルのフォールバックとしてOllama。ベクトル検索はFAISS、文書メタデータとコメントはPostgreSQL。ツール自体のGDPRコンプライアンスのため、EUリージョンにデプロイしました。

完成までに€2,700。現在は、毎月の継続的なメンテナンスについての相談が増えています。最大の学び:ドメイン特化型RAGは、80%がプロンプトエンジニアリング、20%がメタデータ・アーキテクチャと検索です。LLMに、権威階層を尊重し、ソースを適切に引用する“法務の専門家”のように振る舞わせることが、本当の仕事でした。

同じようなものを作ろうとしている人、またはプロフェッショナルサービス向けRAGに踏み込もうとしている人の質問には喜んで答えます。

submitted by /u/Fabulous-Pea-5366
[link] [comments]