ローカルLLM活用術：要約・資料検索・返信下書きを小さく試す

ローカルLLMを導入したら、まず『実際の作業を1つ、短い入力で再現できるか』を見ます。大きなモデルを動かすこと自体をゴールにすると、必要以上に時間や機材を使ってしまいます。要約、資料の該当箇所探し、返信の下書きは確認しやすい練習です。ここでは架空の資料を使います。掲載した例は人が答えを確認できる練習問題で、特定モデルでの成功率や時短効果を測定した結果ではありません。

1. 要約は、原文にないことを足さない練習から

確認できる答えは『開始14時』『案内文の下書き担当は佐藤』『会場は未定』『提出期限は記載なし』です。曜日、具体的な日付、会場名を作っていたら不合格にします。読みやすさより先に事実を照合してください。モデルが不足を勝手に補う場合は、『決まっていないことを決定事項に含めない』と条件を具体化します。新しい会話でも同じ条件で試し、長い履歴のおかげで一度だけ答えられた状態と区別します。

2. 返信は、送信せず下書きだけ

次は架空の相手への確認文を作ります。『会場と提出期限を確認したい。先ほどの連絡文にない内容は追加せず、丁寧な質問文を2文で』と頼みます。確認点が2つ入っているか、決まっていない予定を勝手に約束していないかを見ます。実在の取引先のメールは、機密や個人情報を除いたうえで所属先の許可を確認する必要があります。下書きのコピーは自分で行い、メール送信権限を与える必要はありません。

3. 資料が増えたらRAGを使う

RAGは、資料の関連部分を探してから、その部分を参考に回答させる方法です。資料をモデルの重みに覚え込ませる追加学習とは異なります。GPT4AllのLocalDocsは、資料を取り込んで質問する窓口です。AnythingLLMにも資料とモデルをつなぐ設定があります。回答用のLLMに加え、資料を検索用の表現へ変換する埋め込みモデルの設定も必要になります。回答モデルだけをローカルにしても、埋め込みや外部連携がクラウドなら通信が生じます。

見つからないときの切り分け

資料がまだ取り込まれていない、画像PDFで文字を抽出できない、参照範囲が違う、といった場合はモデルを大きくしても解決しません。まず短いテキストで資料検索が動くか確認します。回答に根拠がないときは、検索で該当部分を取得できていないのか、取得した内容を誤読したのかを分けます。元資料の更新後に索引が更新されているかも確認してください。古い索引を参照する状態を、最新の回答だと受け取らないようにします。

速度と品質は、同じ課題で記録する

アプリの版、モデル名とタグ、形式、入力、設定、応答にかかった時間、手直しした点を残します。初回はモデルの読み込み時間も含まれるため、準備と回答生成を混ぜて比較しないでください。モデルサイズを上げる前に、短文・低い入力長で用途を満たすかを確認します。端末が極端に重い、内容の捏造が続く、根拠を追えない場合は、その用途では利用を止める判断も必要です。