既存のドキュメントからAI学習データセットを作成する

過去の問い合わせを使って分類モデルを学習させたいのに、質問と回答があちこちのチケットに分かれている。Beeuniは指定した会話を集め、ラベル付きの学習例に整理し、項目の欠落や重複をチェックできます。判断の難しいラベルを確認すれば、1行に1件のJSONレコードを記し、元のチケットへのリンクを付けたJSONLデータセットが得られます。

ファイル形式を決める前に、モデルに学習させる動作を決める

たとえば、受信した依頼を分類するモデルを作るとします。各例には依頼内容と、承認済みのカテゴリが必要です。ハンドブックに基づいて回答するモデルを作るなら、質問と根拠となる文章、確認済みの回答が必要です。すべての段落を質問に変換しても、回答が正確で役に立つとは限りません。

資料を保管しているサービスに接続するか、エージェントがドキュメントリポジトリにアクセスできるようにします。まずは、名前を指定したコレクションや日付範囲から始めましょう。公開ドキュメントを使う場合は、対象のサイトとセクションを指定します。最初の例をレビューする前に、収集した出典と読み取れなかったページをエージェントに一覧にしてもらいます。

まずは小規模なラベル付けの課題から取り組む

架空のサポートチームが、依頼を分類するモデルを準備しているとします。ラベルは「請求」「アカウントへのアクセス」「製品に関するサポート」「要レビュー」の4種類です。承認済みのサポートコネクタを通じて、エージェントは合意した日付範囲内の解決済みチケットを読み込みます。ラベル付けと出典の追跡に必要なフィールドだけを収集し、連絡先情報や無関係な添付ファイルは除外します。チケットが最初に振り分けられたキューが、正しいラベルとは限りません。請求担当者が、転送されたログインに関する質問に回答していることもあります。

チケットの参照情報、選定ルール、収集時刻と一緒に、元データのコピーをComputerに保存します。レビュー中にチケットが編集されても例が知らないうちに変わらないよう、そのコピーを使って変換処理を実行します。エージェントは抽出と検証のスクリプトを作成して実行し、データセット、スクリプト、レビュー報告書をまとめて返せます。

短いメッセージ、長いやり取り、複数の問題を含む依頼から始めましょう。予測時にモデルが受け取る入力を決めます。モデルが最初の顧客メッセージだけを見るなら、最終的な解決内容を学習入力に含めてはいけません。そうしないと、新しい依頼を受けたときにアプリケーションから得られない情報を使って学習してしまいます。

残りの例をエージェントにラベル付けしてもらう前に、3行目のルールを決めてください。すぐに解決すべき問題を基準に振り分ける方法もあれば、複数の意図が競合する依頼をすべてレビューに回す方法もあります。どちらも妥当な方針ですが、担当者ごとに基準が混在すると、モデルが学習する例に一貫性がなくなります。

意見の食い違いをラベル付けガイドの改善に活用する

小規模な同じバッチを2人のレビュー担当者に独立してラベル付けしてもらいます。元のラベルと最終判断はどちらも残します。意見が分かれた場合は、理由を記録します。たとえば、情報不足、カテゴリの重複、ラベル付けの誤りなどです。エージェントに該当例をレビュー用ファイルにまとめてもらうことはできますが、振り分け方針はワークフローの責任者が決定します。

判断によってラベル付けガイドを変更した場合、そのルールに影響される以前の例も見直します。架空の分類器では、「すぐに解決すべき問題」を基準にすると、解約の依頼は「アカウントへのアクセス」に分類されます。サインインの問題と支払いを組み合わせたほかのメッセージにも、同じ基準を適用する必要があります。意見が分かれた行だけを直しても、以前からの不整合は残ります。

元のメッセージと合成したバリエーションは分けて管理します。1つの依頼を10通りに言い換えても、表現の幅は広がるかもしれませんが、独立した状況が10件増えるわけではありません。バリエーションを生成する場合は、元の例を記録し、意味が変わっていないか確認します。「請求されました」を「請求されます」に変えるだけでも、意図するラベルが変わることがあります。

学習用レコードを作る前にレビュー記録を残す

各例と出典を一緒に保持する中間スキーマを使います。質問と回答のデータセット用に、架空のレビュー記録を示します。データセットに含める質問と回答は、実際の資料を確認したうえで作成してください。

{"id":"sample-001","source":"sample-handbook.txt","section":"Opening hours","question":"When does the desk open?","answer":"The desk opens at 9 a.m.","review_status":"pending","split":"unassigned"}

これは作業用のスキーマであり、学習APIのペイロードではありません。レビュー後、承認されたレコードを学習ツールが求める形式に変換します。そのツールがメッセージや入出力のペアしか受け付けない場合は、出典の参照情報とレビュー判断を別ファイルに保存します。

実行可能なチェックをエージェントに指定する

• 構造: JSONLの各行を解析し、必要なフィールドと値の型がそろっていることを確認します。
• 出典: 各例が、存在する出典とセクションを参照していることを確認します。
• 重複: テキストを正規化して比較し、類似した重複候補は別途レビューします。表現が似ていても、異なる事実を示している場合があります。
• プライバシー: 個人情報や認証情報をスキャンし、検出されたレコードはエクスポート前に確認します。
• 網羅性: カテゴリごとの例の件数を集計し、レビュー済みの資料がほとんどない、またはまったくないカテゴリを一覧にします。

スクリプトを使えば、出典の参照先が存在するかは確認できます。しかし、回答の根拠がその出典にあることまでは証明できません。情報不足や矛盾する記述を含む例も含め、回答を確認してください。生成した候補は、承認済みレコードとは分けておきます。

同じ事例を学習用とテスト用の両方に入れない

評価で何を測るかを決めます。未知のドキュメントに対する性能を測るなら、同じドキュメントに由来する例をすべて同じ分割先にします。複数のファイルが同じ事例を説明している場合は、事例ごとにまとめます。行をランダムに分割すると、評価用の回答に近いコピーが学習データに含まれることがあります。

train.jsonl、validation.jsonl、出典マニフェスト、検証レポートを用意するよう依頼します。レポートにはレコード数、却下されたレコード、重複グループ、分割ルールを記載します。データセットがこれらのチェックに合格したら、Beeuniに接続先の学習用コンピューターでファインチューニング実験を実行してもらえます。

分類器を引き渡す際は、JSONLファイルとともに、ラベルの定義、入力フィールド、判断が難しい依頼の扱い方も含めます。別の開発者が変換を再現できるよう、準備スクリプトと設定も添えます。エクスポート元のソースバッチを記録してください。final.jsonlというファイル名だけでは、前回のエクスポートから何が変わったのかレビュー担当者には分かりません。

元データがスプレッドシートなら、CSVのクリーニングガイドで識別子と欠損値の扱いを確認できます。独自のインターフェースからデータセットの準備を行うには、SDKガイドを参照してください。