「とりあえず ChatGPT に社内ドキュメントを食わせて、社内 Bot を作ってみました」というご相談が増えています。多くの場合、動きはするのに 数週間で誰も使わなくなる 状態に陥ります。Deer が実プロジェクトで繰り返し見ている、典型的な5つの失敗と回避策を共有します。
ミス 1: ドキュメント全体を embedding に放り込む
PDF / Word / Notion を丸ごとベクトル化し、ユーザーの質問とコサイン類似度で検索する — これだけだと、「タイトルしか引っかからない」「同じ章の冒頭ばかり返ってくる」現象が頻発します。
回避策: 「セクション単位」「Q&A 単位」など、意味のある区切りでチャンクを切る。長文ドキュメントは要約版を別途生成して混ぜる。
ミス 2: 「分からない」と返さない
LLM の素直さは利点でもあり、欠点でもあります。情報源に答えがなくても、もっともらしい文を作ってしまう (ハルシネーション) のは、社内 Bot では致命的です。
回避策: Retrieval の類似度スコアに閾値を設け、低スコアの質問は「該当する社内文書が見つかりません」と返す。さらに system prompt で「根拠が引用できないなら『分かりません』と答える」と明示する。
ミス 3: 出典を出さない
「これって本当?」と聞き返したくなる回答を返すと、Bot への信頼は一気に崩れます。
回避策: 回答の末尾に必ず「参照: ○○マニュアル 第3章」のような出典を載せる。クリックで原文に飛べると尚良い。
ミス 4: ナレッジが古びる仕組みがない
社内マニュアルは生き物です。半年前の規定で答え続けると、現場では「Bot は嘘をつく」という烙印が押されます。
回避策: Slack / Notion / Confluence からの定期的な再 embedding スケジューラ。新規文書追加時の差分 indexing。「最終更新日」を回答に出す。
ミス 5: 「誰が、いつ、なぜ使うか」を決めずに作る
技術的に完成しても、業務フローに組み込まれない Bot は使われません。「経理が請求書ルールを確認するとき、まず Bot に聞いてから経理長に確認する」のような、人の動線設計 が欠けているケースが大半です。
回避策: 構築前に「ペルソナ × シーン」を3つ書き出す。それぞれに対する典型質問を5つずつ集める。出来上がった Bot がその15問に正しく答えられるかを最初の評価基準にする。
まとめ
技術選定より、設計が9割です。Deer の RAG チャットボット構築サービスでは、初期ヒアリングのほとんどを「誰がいつ何を聞くか」の整理に費やします。