企業独自の文書を活用するAI（RAG）、ハンガリー語にも対応

ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、企業の文書から検証可能な回答を得る方法はRAGです。システムがまず関連する箇所を探し出し、モデルがそれをもとに、出典を示してハンガリー語でも回答します。

要点： モデルを自社のデータで学習させる必要はありません。RAGは質問の時点で関連する箇所をモデルに渡し、回答には出典が示されます。品質は、文書がどれだけ整理されているか、検索がどれだけ正確か、そして継続的な測定にかかっています。ハンガリー語でも機能しますが、自社のハンガリー語の質問で測定する必要があります。

RAGとは何で、この用語はどこから来たのですか？

RAGはretrieval-augmented generationの略で、日本語ではおおむね「検索拡張生成」です。この用語は、Patrick Lewisらが2020年に発表した論文に由来し、そのタイトルは「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」です。著者らは、事前学習済みの言語モデルのいわゆるパラメトリックメモリを、ノンパラメトリックメモリ、すなわちニューラル検索器でアクセスするWikipediaの密なベクトルインデックスと組み合わせました。

今日では、この用語はより広く、システムが質問ごとにまず文書コレクションの中から必要な箇所を探し出し、言語モデルがそれをもとに回答を組み立てるソリューションを指します。その過程でモデル自身の知識は変わりません。企業の資料は、質問の時点でモデルに渡されます。ここからRAGの実務上の3つの利点が生まれます。知識をすぐに更新できること、回答に出典を示せること、そして検索の際に、質問者が閲覧できるものだけに絞り込めることです。

どのように機能しますか？6つのステップ

収集： 情報源を1か所にまとめます。文書管理システム、Wiki、チケット管理システム、メールの選んだ部分などです。
分割： 長い文書を、数段落程度の小さな部分（チャンク）に分けます。たとえばOpenAIの検索サービスは、デフォルトで最大800トークンのチャンクを、400トークンの重なりを持たせて作成します。
埋め込み（エンベディング）： 埋め込みモデルが、各チャンクを数値の並び、すなわちベクトルに変換します。OpenAIの説明によれば、ベクトル間の距離が小さいことは内容の関連性が高いことを、距離が大きいことは関連性が低いことを示します。
検索： 同じモデルが質問をベクトルに変換し、システムはそれに最も近いチャンクを探します。AnthropicはContextual Retrievalの解説の中で、意味による検索を、文字どおりのキーワード検索であるBM25で補っています。BM25のほうが、識別子などの正確な表現をよく見つけられるためです。そのうえで、再ランキング（reranker）のステップが、最も関連性の高いチャンクだけをモデルに渡します。
絞り込みと組み立て： 見つかったチャンクのうち、質問者も閲覧できるものだけを残し、それを質問とともにモデルに渡します。
出典付きの回答： モデルは受け取った箇所をもとに回答し、その記述をどこから得たのかを示します。Anthropicのcitations機能は、PDFではページ番号を、プレーンテキストでは文字位置を示します。OpenAIのファイル検索は、回答の中にソースファイルを参照する注記を付けます。

分割でよくある問題は、チャンクが文脈を失ってしまうことで、Anthropicも同じ解説の中でこの点に注意を促しています。「期限は受領日から起算します」という一文だけでは、どの契約のどの期限のことなのかがわかりません。そのため、各チャンクに文書のタイトル、章の見出し、日付を加え、検索とモデルの両方がその前後関係を把握できるようにすることをお勧めします。

RAGか、ファインチューニングか？

ファインチューニング（fine-tuning）とは、タスク固有のデータでモデルを追加学習させることです。OpenAIの精度に関するガイドによれば、RAGはタスクに必要な専門分野の文脈を与えるもので、モデルの知識が古い場合や、タスクに企業独自の情報が必要な場合に用います。一方、ファインチューニングは、モデルの出力に一貫性がない場合や、形式やトーンが適切でない場合に役立ちます。ガイドによれば、2つの手法は互いに補い合い、併用することもできます。

観点	RAG	ファインチューニング
用途	質問の時点で企業の知識をモデルに渡す	モデルの振る舞い、形式、トーンをそろえる
最新の知識	文書を更新したあと、インデックスを更新すれば反映される	新たな学習が必要
出典の明示	回答で、見つかった箇所を示せる	モデルの重みに取り込まれた知識には出典が付かない
権限	文書ごとに絞り込める	学習済みの知識はすべてのユーザーに共通
文書の撤回	文書をインデックスから外す	その影響は新たな学習によってのみ消える
適している場面	企業の文書では、ほぼ常にこれが出発点	形式やトーンの一貫性が問題の場合に、RAGと併用

そのため、企業の文書にはRAGが自然な出発点です。「モデルを学習させる必要があるか」という問いは、多くの場合、実際には「モデルが企業の知識をどのように得るか」という意味であり、その答えがRAGです。

ハンガリー語でも使えますか？言語対応と複数言語が混在する資料

回答するモデル

大手プロバイダーのモデルはハンガリー語もよく理解し、上手に書くことができますが、公開されている言語性能の測定結果がハンガリー語を含むとは限りません。Anthropicの多言語対応のページは、英語以外の14言語の測定結果を公開しており、その中にハンガリー語は含まれていません（2026年10月17日確認）。ただし同じページでは、Claudeが表に挙げた言語以外の多くの言語でも使えることを強調し、アプリケーションにとって重要な言語でテストすること、そして回答の言語をシステムプロンプトで指定することを勧めています。当社の経験も同じです。当社のトップページにあるClaudeを基盤とするAIアシスタントは、ハンガリー語とほか13の言語で会話しますが、新しい使い方はすべてハンガリー語の質問で測定しています。

埋め込みモデル

検索の品質は、回答するモデルと少なくとも同じくらい、埋め込みモデルにかかっています。大手プロバイダーでは（2026年10月17日確認）：

ドキュメントによれば、GoogleのGemini Embedding 2モデルは100を超える言語で機能します。
Anthropicは独自の埋め込みモデルを提供しておらず、Voyage AIのモデルを紹介しています。そのうちvoyage-4は、汎用の検索と多言語の検索に最適化されています。
OpenAIの埋め込みに関するガイドはtext-embedding-3モデルを紹介していますが、対応言語は列挙していません。

そのため、埋め込みモデルは、プロバイダーの一般的な測定結果ではなく、企業独自のハンガリー語の質問と文書のペアで選びます。

ハンガリー語特有の事情

語形変化： 「szerződés」「szerződésben」「szerződéseinkről」（契約、契約の中で、当社の契約について）は同じものについての語ですが、文字どおりのキーワード検索では、語幹処理（ステミング）なしには一致とみなされません。意味による検索がこの点を補い、ハイブリッド検索は両者を組み合わせます。
専門用語と社内の名称： 企業の略語、製品コード、社内での呼び名は、モデルの一般的な知識には含まれていません。短い用語集を用意するだけで、検索は大きく改善します。
複数言語が混在する資料： 質問がハンガリー語で、マニュアルが英語の場合は、多言語対応の埋め込みモデルが必要で、回答の言語を固定する必要があります。引用する出典は原文の言語のままです。
ふだんの言い回し： 誤字、アクセント記号なしで入力された質問、口語表現も、テスト用の質問に含める必要があります。

どのような文書をもとに動作できますか？

情報源	注意点
テキストベースのPDF	処理しやすく、出典の明示でページ番号も示せる
スキャンしたPDF	まず文字認識（OCR）が必要。Anthropicのドキュメントによれば、抽出可能なテキストのないスキャンPDFからは引用を示せない
WordとExcel	AnthropicはDOCXファイルとXLSXファイルをテキストに変換することを勧めており、OpenAIのファイル検索はDOCXを直接受け付ける。表の構造を保つ必要がある
Wikiとイントラネット	現行版を基準とし、古いページはアーカイブに移す
チケット、ヘルプデスク	個人データや古くなった解決策が多く含まれるため、絞り込みが必要
メール	選んで整理した範囲に限る。個人データと権限の面で、最も扱いに注意が必要な情報源

文書ごとの権限

RAGで最も注意が必要な点は、質問者が元のシステムでも開けない箇所を、システムが渡してはならないということです。当社はこれをモデルに任せず、検索に組み込みます：

各チャンクは、元の文書の権限情報をメタデータとして保持します。
絞り込みは検索の前または検索中に行います（たとえばOpenAIの検索サービスは、意味による検索の前にファイル属性で絞り込む機能を提供しています）。そのため、質問者が閲覧できないものは、そもそもモデルに届きません。
権限の変更は、手作業で管理するのではなく、元のシステムから同期します。
誰が何を質問し、どの文書から回答を得たのかをログに記録します。

インデックスを最新に保つ

RAGの品質は、インデックスの鮮度で決まります。当社が注意している点は次のとおりです：

変更の検知： 新しい文書と変更された文書を、システムが自動的に処理します。
削除： 元の場所で削除された文書は、インデックスからも削除されます。OpenAIのドキュメントによれば、削除は段階的に反映されるため、削除したファイルがしばらくの間、検索結果に表示されることがあります。
バージョン： 現行版と撤回された版を区別し、メタデータに日付を記録します。
情報源の管理者： 各情報源には責任者がいて、内容が古くなったときに知らせます。
有効期限： 一時的な資料には有効期限のルールを設けます。たとえばOpenAIのベクトルストアには、有効期限を設定できます。

誤った回答を減らす：出典、「わかりません」、測定

言語モデルは、資料を与えられていても誤ることがあります。Anthropicの誤った回答を減らすためのガイドは、モデルに「わかりません」と答えることを明示的に許可すること、文字どおりの引用に基づかせること、すべての主張について裏付けとなる引用を探させ、見つからなければその主張を撤回させること、そして与えられた文書だけをもとに作業させることを勧めています。ガイドはさらに、これらの手法は誤った回答を減らしますが完全にはなくせないため、重要な情報は確認する必要があると付け加えています。当社はこれらを土台にしています：

出典の明示： すべての回答に、どの文書のどの部分に基づくのかが表示されます。
「わかりません」と引き継ぎ： 答えが資料の中にない場合、システムはそのことを伝え、質問を担当者に引き継ぎます。
与えられた資料だけから： モデルは、企業について一般的な知識を使いません。
評価セット： 期待される回答と正しい出典を付けた実際の質問です。検索が正しい箇所を見つけたかどうかと、回答がその箇所に忠実かどうかを別々に測定します。OpenAIの評価に関するガイドによれば、テストデータには典型的なケース、極端なケース、意図的に誤解を招くケースも含める必要があり、評価は変更のたびに実行し直す必要があります。
フィードバック： ユーザーは誤った回答を報告でき、ログから新しいテストケースが生まれます。

データ保護：文書はどこに保存されますか？

RAGシステムでは、企業の資料は3つの場所を通ります：

元のシステム： 文書はこれまでどおりの場所、つまり文書管理システム、Wiki、メールシステムにとどまります。
インデックス： チャンクとベクトルは検索用データベースに保存されます。これは企業自身の環境でも、プロバイダーのもとでも運用できます。たとえばOpenAIのファイル検索では、データ管理に関するドキュメントと検索のガイドによれば、アップロードされたファイルは、削除されるかベクトルストアの有効期限が切れるまで保存されます。
モデルの呼び出し： モデルに届くのは、質問のために選ばれたチャンクだけです。このときはプロバイダーのデータ取り扱い条件が適用されます。それらの条件が学習、保存期間、処理場所について何を定めているかは、企業のシステムを人工知能とどのようにつなげばよいですか？の記事にまとめています。

文書に個人データが含まれる場合、その処理にはGDPRが適用され、処理者であるプロバイダーとは、一般データ保護規則第28条に基づく契約を結ぶ必要があります。法的な問題（透明性、データの移転、影響評価）については、AI ActとGDPR：企業のチャットボットでは何に注意すべきですか？の記事でご説明しています。これは情報提供であり、法的助言ではありません。

RAGプロジェクトのステップ

目標と質問の範囲： 誰が、何について質問し、何を良い回答とみなすのか。
情報源の棚卸しと整理： 重複、矛盾するバージョン、古くなったバージョンを除外します。
権限モデル： 誰がどの文書から回答を得てよいのか。
評価セット： 期待される回答と出典を付けた、実際のハンガリー語の質問。
プロトタイプ： 測定に基づいて、分割、埋め込みモデル、検索を調整します。
接続： 画面、出典の明示、担当者への引き継ぎ、ログ記録。
試験運用： 限られたユーザーで運用し、フィードバックを集めます。
運用： インデックスの更新、継続的な測定、モデル切り替えの測定。

典型的な失敗

文書管理システムを「そのまま」使う： 同じ規程に3つのバージョンがあれば、システムはそのどれからでも引用する可能性があります。
権限をあとから考える： 最初のデモではすべてが見えてしまいますが、本番環境ではそれが個人データ侵害になり得ます。
出典のない回答： ユーザーは確認できず、信頼もしません。
作られた質問によるテスト： デモの質問はうまく動いても、実際のハンガリー語の、誤字を含む質問ではうまくいきません。
一度きりの取り込み： 更新しなければ、ナレッジベースはすぐに古くなります。
文字認識をしていないスキャンPDF： システムには、その内容がまったく見えません。

よくあるご質問

RAGとは何ですか？

RAG（retrieval-augmented generation、検索拡張生成）は、システムが質問ごとにまず企業の文書から関連する箇所を探し出し、言語モデルがそれをもとに出典を示して回答するソリューションです。この用語は、2020年の研究論文に由来します。

自社の文書をもとに、ハンガリー語で回答できますか？

はい。今日の大規模言語モデルはハンガリー語もよく理解し、上手に書くことができ、ハンガリー語の文書も扱えます。当社のトップページにあるAIアシスタントも、ハンガリー語で会話します。プロバイダーが公開している測定結果がハンガリー語を含むとは限らないため、本番稼働の前に、回答するモデルと埋め込みモデルの両方を、企業独自のハンガリー語の質問で測定します。

モデルを自社のデータで学習させる必要がありますか？

一般的には、いいえ。RAGは質問の時点で必要な箇所をモデルに渡すため、知識を更新でき、出典を示すことができ、権限を文書ごとに絞り込めます。ファインチューニングが検討対象になるのは、回答の形式やトーンの一貫性が十分でない場合です。その場合も、RAGに代えてではなく、RAGと併用します。

答えがわからない場合はどうなりますか？

推測で答えを作るのではなく、そのことを伝え、質問を担当者に引き継ぐように構築します。モデルには「わかりません」と答えることを明示的に許可し、与えられた資料だけをもとに作業させます。回答できなかった質問はログから拾い上げ、ナレッジの拡充に活かします。

自社の文書はどこに保存されますか？

これまでどおり元のシステムに保存されます。それに加えて検索用インデックスにも保存され、これは企業自身の環境でも、プロバイダーのもとでも運用できます。モデルには、質問ごとに選ばれた箇所だけが、プロバイダーのデータ取り扱い条件に従って届きます。どの方式が企業に適しているかは、文書の機密性とデータ保護の要件によって異なります。

当社がお手伝いできること

Mesterséges Intelligencia Központ Kft. は、企業独自の文書をもとにハンガリー語でも回答するAIチャットボットを、RAGの手法と出典の明示を用い、OpenAI（ChatGPT）、Anthropic（Claude）、Google（Gemini）の言語モデルを基盤に開発します。初回のご相談は無料です。開発の規模はCOSMICファンクションポイントで測定し、そこからお見積もりとスケジュールを作成します。ご要望に応じて秘密保持契約（NDA）を締結します。引き渡し後は、ナレッジの更新と動作の監視もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。

詳しくはAIチャットボット・AIエージェントとAI統合のページをご覧ください。チャットボットとエージェントのどちらが必要かは、チャットボットか、AIエージェントか？の記事が判断の助けになります。企業の文書をもとに回答するシステムをご計画中でしたら、お問い合わせのページに記載の連絡先までご連絡ください。