LLM向けナレッジベースの作り方|文書整備・更新・権限設計
記事概要:LLM向けナレッジベースの構築を、情報源の選別、文書の正規化、分割とメタデータ、オーナーと更新周期、版管理、アクセス権、廃止までの工程で解説します。PDFやWeb、FAQ、応対履歴を投入前に整える実務が分かります。
本記事の目次
LLM ナレッジベースは、文書を保管する箱ではなく、生成AIが検索し、回答根拠として安全に利用できる状態へ整えた情報基盤です。PDFや応対履歴を一括投入する前に、正しさ、適用条件、更新責任、閲覧権限を文書単位で決めます。
情報源を正解として使えるか選別する
候補は公開FAQ、製品マニュアル、規程、Webページ、PDF、応対履歴です。ただし応対履歴は個別事情や担当者の誤案内を含むため、そのまま正解文書にしません。頻出質問の抽出に使い、正式資料と照合して回答を作ります。各情報源に、所有部門、承認者、対象商品、適用開始・終了日、公開区分、原本URLを付けます。原本が複数ある場合は優先順位を定め、矛盾時にどちらを参照するか明文化します。

検索できる文書へ正規化する
スキャンPDFはOCRし、ヘッダー、フッター、ページ番号、重複メニューを除きます。表は行列関係が失われない形式へ、画像内の注意事項は代替テキストへ変換します。一つの回答単位に結論、条件、例外、手順が収まるよう見出しで分割し、短すぎて意味が切れないか、長すぎて別用件が混ざらないかを確認します。略語、旧商品名、表記揺れは同義語として登録し、原文自体を不自然に詰め込みません。
| 工程 | 成果物 | 確認ポイント |
| 棚卸し | 情報源台帳 | 正解性、原本、所有者 |
| 正規化 | 検索用本文 | OCR、表、重複、回答単位 |
| 付与 | メタデータ・権限 | 商品、版、発効日、公開区分 |
| 公開 | 承認済み版・索引 | 反映時間、旧版無効化 |
| 改善 | 評価結果・変更履歴 | 検索成功、忠実性、期限切れ |
メタデータと権限を設計する
少なくとも文書ID、タイトル、商品、版、発効日、地域、言語、対象顧客、機密区分、オーナーを持たせます。検索時にはユーザー属性と文書権限を照合し、取得できない文書をLLMへ渡さない構成にします。社内用と顧客公開用で似た回答がある場合も、同じ索引へ無条件に混在させません。管理者権限、編集権限、承認権限、閲覧権限を分離し、エクスポートやAPI経由の取得も監査対象にします。
更新と版管理を業務フローにする
記事ごとに定期確認日を設けるだけでは、料金改定や障害時の即時更新に間に合いません。商品・法務・運用部門の変更申請をナレッジ更新へ接続し、下書き、レビュー、承認、公開、索引反映、旧版無効化を一つのチケットで追います。公開後は代表質問を自動テストし、正しい版が引用されるか確認します。廃止文書は削除して履歴を失うのではなく、終了理由と後継文書を残し、検索対象から外します。
Udeskの大規模言語モデル対応ナレッジベースを導入した中国の大手ガス会社では、部門をまたいだナレッジ共有と再利用を進めるため、ナレッジの作成から運用までの管理フローを整備しました。Udeskの公開事例によると、その結果、ナレッジ更新に要する時間は24時間未満まで短縮され、カスタマーサービスボットによる問い合わせ対応のカバー率も40%から80%へ向上しています。ナレッジベースでは文書を蓄積するだけでなく、業務変更をどのように更新へ反映し、利用可能な状態まで早く届けるかを運用として設計することが、回答品質を維持するうえでも欠かせません。
品質を継続的に測る
文書数ではなく、正解文書が上位に出る検索成功率、根拠に忠実な回答率、回答拒否の適切さ、期限切れ文書数、更新リードタイムを見ます。未回答や有人転送が多い質問を、新規記事で解くのか、既存記事の条件不足で解くのか分類します。LLMや埋め込みモデル、分割方式を変える際は、同じ質問セットで前後比較します。利用ログに個人情報が含まれる場合は、分析用データのマスキングと保存期間も決めます。
移行前の品質ゲート
既存文書を移す際は、重複、期限切れ、参照不能、画像依存、所有者不明、公開区分不明の六つを機械・人手で検査します。品質ゲートを通らない文書は本番索引へ入れず、隔離領域で修正します。移行件数を優先すると、旧版を大量に検索可能にして後で直すことになり、AI回答への影響調査が難しくなります。受入試験では代表質問から正しい文書IDと版が検索されるか、権限の異なる三役程度で同じ質問結果が変わるか、更新・失効が規定時間内に反映されるかを確認します。バックアップから復元した場合も、失効済み文書が再び有効にならないか試します。公開後の文書台帳と検索索引の件数差を日次監視すると、同期漏れを早期に検知できます。
運用会議の役割
月次会議では未回答上位、誤引用、期限切れ、更新遅延、権限エラーを確認します。ナレッジ担当は文書、AI担当は検索・生成、業務担当は正解、セキュリティ担当は公開範囲を受け持ちます。すべてをAIチームへ集めず、内容責任を原部門へ残すことで、商品改定や法務変更を早く反映できます。

文書単位の必須項目
| 確認項目 | 合格条件 |
| 責任 | 内容オーナー、承認者、問い合わせ先が登録されている |
| 適用 | 商品、地域、顧客区分、発効・終了日、言語が明確である |
| 根拠 | 原本URLと版が追跡でき、引用箇所が回答に必要な条件を含む |
| 廃止 | 後継文書と終了理由を残し、旧版が検索対象から外れている |
| 利用 | 検索・引用・有人採用のログを文書IDへ集約し、継続的な改善判断へ戻せる |
検証から本番運用をUdeskでつなぐ
LLM向けナレッジを回答業務で使う企業には、文書の作成・権限・更新と、AI回答や有人応対の利用結果を往復させる運用が必要です。UdeskのLLMナレッジベースはAIチャットボット、ボイスボット、オペレーター支援、問い合わせ管理と連携できるため、同じ承認済み知識をチャネルごとに複製せず活用できます。
FAQ
Q.応対履歴をそのままLLMへ登録できますか?
A.推奨できません。個別事情、個人情報、誤案内を除き、正式資料で検証したうえでナレッジ化します。
Q.文書は細かく分割するほどよいですか?
A.違います。条件や例外が別片に切れると誤答を招きます。一つの回答に必要な意味が保たれる単位にします。
Q.更新責任者はAI担当者ですか?
A.内容を決める商品・法務・業務部門がオーナーとなり、AI担当は形式、索引、評価を管理する分担が現実的です。
》》Udesk ナレッジベースの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください
本記事はUdeskのオリジナルであり、転載する際は出典を明記してください:https://www.udesk.jp/blog/news/guide/6542/
カスタマーサポートAIソリューションカスタマーサポートシステムナレッジベースシステム

Customer Service& Support Blog



