ナレッジベースデータ取り込み

このページは機械翻訳により提供されています。翻訳内容と英語版に相違がある場合は、英語版が優先されます。

データを正しく取り込むことで、そのデータを確実に取得できるかどうかが決まります。 スコープが適切に設定されたナレッジベースでも、コンテンツの取り込みが不適切であれば、スコープが不適切なナレッジベースと同じように取得の品質が低下します。 このページでは、取得品質を左右する取り込みに関する判断について説明します。

2つの取り込みパス

ナレッジベースにコンテンツを追加する方法は2つあります:

  • Workato GOデータソース: Workato GOインターフェイスで利用できる事前構築済みコネクター。 Workato GOデータソースは、Google Drive、Confluence、SharePoint、Notionなどの一般的なコンテンツソースに接続し、権限を考慮してコンテンツを取り込みます。 ソースシステム内のドキュメントにアクセスできないユーザーは、Genieを通じてそのドキュメントのフラグメントを取得できません。

次の場合はWorkato GOデータソースを使用します:

  • コンテンツにソースシステム内でアクセス制限がある

  • コンテンツソースに対応する事前構築済みコネクターが存在する

  • カスタム取り込みロジックを構築せずに、権限を考慮した取得が必要である

  • ナレッジベースレシピ: Workatoレシピエディターで構築するカスタムレシピ。 ナレッジベースレシピは、Workato GOデータソースでサポートされていないソースを含む任意のソースからコンテンツを取得し、Enterprise Context by Workatoコネクターを使用してナレッジベースに書き込みます。このコネクターでは、ナレッジベース内のドキュメントのアップサート、削除、一覧表示、検索を実行できます。 ナレッジベースレシピは権限を考慮しません。 取り込まれたすべてのコンテンツは、Genieとやり取りするすべてのユーザーがアクセスできます。

次の場合はナレッジベースレシピを使用します:

  • コンテンツソースに対応するWorkato GOデータソースが存在しない
  • コンテンツがすべてのユーザーに適しており、権限を考慮する必要がない
  • 変換、フィルタリング、形式変換など、事前構築済みコネクターではサポートされないカスタム取り込みロジックが必要である

両方のオプションを利用でき、コンテンツにアクセス制限がある場合は、常にWorkato GOデータソースを使用します。 後でWorkato GOデータソースに切り替えても、レシピを通じて取り込まれたコンテンツが遡って権限を考慮するようになるわけではありません。

コンテンツを論理的にチャンク化する

取り込み前のコンテンツのチャンク化は、スコープの次に取得品質を左右する最大の要因です。 チャンク化とは、コンテンツをナレッジベースに保存され、フラグメントとして取得される個別の単位に分割するプロセスです。

ナレッジベースの取得メカニズムは、意味的に最も類似したドキュメントではなく、意味的に最も類似したフラグメントを返します。 取得品質は、ドキュメントに答えが含まれているかどうかではなく、フラグメント自体に答えが含まれているかどうかに依存します。

ドキュメント全体の取り込みに関する問題

20ページの人事ポリシードキュメントを1つのナレッジベースエントリとして取り込むと、年次有給休暇の付与に関する質問に対する取得で、ドキュメント全体が一致するフラグメントとして返される場合があります。 有用な情報はドキュメント内にありますが、フラグメントが大きすぎて一般的すぎるため、取得メカニズムがそれを特定できません。

論理的なチャンク化の利点

同じドキュメントを個別のセクションに分割すると、年次有給休暇の付与に関する質問に対して、セクション固有の取得が可能になります。 年次有給休暇の付与、病気休暇ポリシー、育児休暇の資格に関するエントリを作成します。 これらのフラグメントは具体的で、関連性があり、引用可能です。

論理的なチャンク化とは、任意のサイズ境界ではなく、セクション、サブセクション、個別のポリシー項目、個別のFAQエントリなどの自然な境界でコンテンツを分割することです。 5つのセクションがあるポリシードキュメントは、5つのナレッジベースエントリになります。 30個の質問があるFAQは、30個のエントリになります。 100個の商品があるCSVファイルは、100個のエントリになります。

コンテンツタイプ別のチャンク化ガイドライン

コンテンツタイプチャンク化アプローチ
ポリシードキュメントセクションまたはサブセクションごとに1つのエントリ。 長いセクションは、論理的な段落の区切りでさらに分割します。
FAQコンテンツ質問と回答のペアごとに1つのエントリ。 複数のFAQを1つのエントリにまとめないでください。
クローズ済みチケットチケットごとに1つのエントリ。タイトル、説明、解決メモを含めます。
CSVまたは表形式データ行ごとに1つのエントリ。未加工のCSV行ではなく、JSONまたはYAMLの構造化ドキュメントとして形式設定します。
会議メモまたは通話サマリー会議または通話ごとに1つのエントリ。主要トピックと結果を明確にラベル付けします。
製品ドキュメント製品ごとではなく、機能またはケイパビリティごとに1つのエントリ。

ソースURL

ナレッジベースに取り込まれるすべてのエントリには、元のソースドキュメントのURLを含める必要があります。 GenieはこのURLを使用して、ユーザーに情報を提示するときにソースを引用します。

ソースURLには2つの目的があります:

  • 信頼と検証可能性: Genieからポリシーに関する回答を受け取ったユーザーは、リンクをクリックして元のドキュメントで回答を検証できます。 これにより、Genieの応答に対する信頼が高まり、人間の専門家へのエスカレーションが減少します。
  • デバッグ: 取得で誤った結果が生成された場合、ナレッジベースエントリ内のソースURLにより、誤ったフラグメントがどのドキュメントから来たのかを簡単に特定し、更新または削除できます。

すべてのナレッジベースエントリに、専用フィールドとしてソースURLを含めます。 ソースURLをテキストコンテンツに埋め込まないでください。 Genieはフラグメントを取得するときに、その応答内でURLを参照できます: According to the Annual Leave Policy (link).

データ形式と品質

ナレッジベース内のコンテンツの品質は、取得品質に直接影響します。 形式が不適切、ノイズが多い、または古いコンテンツは、ナレッジベースのスコープ設定やチャンク化がどれほど適切でも、低品質な結果を生み出します。

  • 構造化コンテンツにはMarkdownを使用する: プレーンテキストでも問題ありませんが、Markdownを使用すると取得されたフラグメントの構造が改善されます。 ヘッダーによりセクション境界が明確になります。 太字テキストは重要な用語を強調します。 リストは列挙可能な項目を整理して表示します。 Markdownで形式設定されたナレッジベースエントリは、プレーンテキストの塊よりも、取得メカニズムとLLMのどちらにとっても処理しやすくなります。

  • 取り込み前に構造化データをJSONまたはYAMLに変換する: 未加工のCSV行、未加工のSQL出力、未加工の表形式データは、ベクトルストレージには理想的ではありません。 取り込み前に、各行またはレコードを、ラベル付きフィールドを持つ構造化ドキュメント形式に変換します。 annual_leave_days: 20, eligibility: all permanent employees, accrual_rate: 1.67 days per monthは、未加工のCSV行よりも取得しやすくなります。

  • 取り込み前にコンテンツをクリーンアップする: HTMLタグ、形式設定のアーティファクト、ナビゲーション要素、およびすべてのドキュメントに表示されるが取得には役立たない定型テキストを削除します。 Webスクレイピングやドキュメントエクスポートから取得したコンテンツには、多くの場合、残したままにすると取得品質を低下させる大きなノイズが含まれています。

  • 古いコンテンツを削除する: ポリシーの現在のバージョンと古いバージョンの両方を含むナレッジベースでは、互いに矛盾する取得結果が生成されます。 取り込み前に、コンテンツソースに古いバージョンがすでに含まれていないかを確認し、それらのバージョンを除外します。 デルタ取り込みのために、削除済みまたは置き換え済みのコンテンツを検出して削除するロジックを実装します。

フルロードとデルタロード

コンテンツの取り込みは1回限りのイベントではありません。 ナレッジベースを最新の状態に保つには、継続的なプロセスが必要です。 取り込みモードにはフルロードとデルタロードの2つがあり、プロダクションのナレッジベースには両方が必要です。

フルロード

フルロードは、ソースからすべてのコンテンツを最初から取り込みます。 ベースラインコンテンツを確立するために、ナレッジベースを最初に作成するときに1回実行します。

フルロードのガイドライン:

  • 一括インポートではなく、特定のフィルターを適用する: Google Drive全体やConfluenceスペース全体を取り込まないでください。 このナレッジベースに関連するコンテンツを識別する特定のフォルダ、ラベル、またはタグを定義します。 Google Driveのフルロードでは、ドライブ全体ではなく、HR Policiesなどの正確なフォルダを指定する必要があります。
  • 除外ロジックを適用する: 画像のみのPDF、動画ファイル、取得を目的としていないテンプレートファイルなど、サポートされていない、または有用でないファイルタイプを除外します。 取得すべきでない場合は、下書き、アーカイブ済み、または内部専用であることを示す名前やラベルが付いたドキュメントを除外します。
  • フルロードレシピを1回実行する: 明確にマークします。 FULL LOAD - Run Once - HR Policies KBのようなレシピ名にすると、将来のビルダーが誤って再実行して重複エントリを作成することを防げます。
  • 出力を検証する: フルロードを実行し、取り込まれたエントリのサンプルを確認して、チャンク化、形式設定、ソースURLが正しいことを確認します。 デルタロードを設定する前に、問題を修正します。

デルタロード

デルタロードは、前回の実行以降に変更されたコンテンツのみを取り込みます。 ソースコンテンツの変化に合わせてナレッジベースを最新の状態に保つために、スケジュールに従って実行します。

デルタロードのガイドライン:

  • コンテンツの変動性に基づいて頻度を設定する: 四半期ごとに変更されるポリシーは、毎月更新できます。 毎週変更される製品ドキュメントは、毎日更新する必要があります。 取り込み頻度は、コンテンツが変更される頻度と、古いコンテンツがユーザー向けの問題を引き起こすまでの速さに合わせます。
  • 削除されたコンテンツを検出して処理する: ドキュメントがソースシステムから削除された場合は、ナレッジベース内の対応するエントリを削除します。 新しいコンテンツを追加するだけで削除されたコンテンツを削除しないデルタロードでは、時間の経過とともに古いエントリが蓄積されます。 現在のソースドキュメントリストをナレッジベースエントリと比較し、存在しなくなったドキュメントのエントリを削除することで、削除検出を実装します。
  • 更新されたコンテンツを正しく処理する: ドキュメントが更新された場合、古いナレッジベースエントリは、更新後のコンテンツを反映したエントリに置き換える必要があります。 同じドキュメントの複数のバージョンを個別のエントリとして蓄積しないようにします。

現在の取り込み制限

取り込みプロセスを設計する前に、次のプラットフォーム制限を理解してください:

制限詳細
最大ファイルサイズファイルあたり16MB。 16MBを超えるファイルは取り込み前に分割するか、関連するセクションのみを取り込みます。
サポートされているファイルタイプPDF、PPTX、XLSX、DOCX。 画像、動画、音声ファイルを含むその他のファイルタイプはサポートされていません。
テキストコンテンツのみ取り込み時に抽出されるのは、ドキュメントのテキストコンテンツのみです。 ドキュメント内の画像は抽出もインデックス化もされません。 ポリシードキュメントに、テキストではなく画像や図に重要な情報が含まれている場合、その情報は取得に利用できません。
画像はサポートされていませんJPGやPNGなどの画像ファイルは、ナレッジベースドキュメントとして取り込むことはできません。 ユースケースにとってビジュアルコンテンツが重要な場合は、取り込み前にそのビジュアルをテキスト説明に変換します。

これらの制限は、特定のコンテンツタイプに対する取り込み方法に影響します。 表が形式設定されたテキストではなく画像として含まれているポリシードキュメントでは、取り込み前に手動変換ステップが必要です。 製品画像を含む製品カタログでは、画像ベースの情報をテキストとして取得する必要があります。

取り込みを追跡する

各ナレッジベースに取り込まれた内容を記録するData tableを維持します。 各行には次を含める必要があります:

  • ConfluenceページIDやGoogle DriveファイルIDなどのソースドキュメント識別子
  • ソースドキュメント名
  • 取り込み先のナレッジベース
  • 取り込み日
  • 作成されたエントリ数
  • ステータスフィールド: active、deleted、またはsuperseded

このレコードには2つの目的があります。 すべてのエントリを読まなくても、ナレッジベースの内容を監査できるようになります。 また、現在のソースドキュメントリストを取り込みレコードと比較して、ソースから削除されたドキュメントを特定することで、デルタロードの削除検出に必要な参照データも提供します。

Last updated: