テクノロジーだけが採用を保証するわけではない：内部AIチャットボットの教訓

AIの採用が業界全体で加速する中、内部アプリケーションのサポートとしてチャットボットを導入することは、論理的な決定のように思えた。しかし、アプリケーション自体が従来のユーザーの期待を挑戦していた。新しいワークフローと、多くのユーザーにとって未知の新興テクノロジーを導入していた。

摩擦を減らし、採用率を向上させるために、チャットボットはアプリケーションとその基盤となるテクノロジーに関する質問に答えるように設計された。目標は、ユーザーが何をしなければならないかだけでなく、システムがどのように動作するのかを理解するのを助けることだった。文脈的な説明を提供することで、学習を促進し、混乱を減らすと考えていた。

最初から、AIエージェントは限定的な解決策として考え出された。ドキュメントのサポートとユーザー支援を提供するように設計された。概念的に、チャットボットは伝統的なFAQドキュメントの代わりとして機能することを意図していた。会話型、検索可能、継続的に利用可能なインターフェースを提供し、静的なコンテンツを超えた機能を備えていた。

エージェントを組織の内部チャット環境に統合するために、構造化メッセージがどのようにレンダリングされるか、会話履歴がどのように保存されるか、システムがスレッド内で参加者をどのように識別するかを理解する必要があった。これにより、ユーザーの質問を処理するために必要な基本的な変数を決定することができた。

モデルを根拠づける：妄想から信頼できるコンテキストへ

大規模な言語モデルは強力だが、コンテキストのアンカーがないと妄想に陥りやすい。対策として、ベクトル埋め込み技術を実装した。

ユーザーガイド、内部ドキュメント、製品ビジョンを数値ベクトル表現に変換した。这些埋め込みは、意味的な意味を捉え、システムが単純なキーワードマッチングではなく概念をマッチングできるようにした。

ユーザーが質問をすると、システムはクエリをベクトル表現に変換し、保存された埋め込みと比較した。最も意味的に関連のあるドキュメントを取得し、モデルのプロンプトに注入した。モデルはそれらの特定のドキュメントに基づいて応答を生成し、関連する情報を要約することが多かった。

このアプローチにより、応答の精度が大幅に改善された。一般的な知識に基づいて回答を生成するのではなく、組織独自のドキュメントをコンテキストとして使用して回答を生成した。

コンテキスト管理の隠れた複雑さ

会話履歴をプロンプトに含めることが重要だった。そうすればボットがフォローアップの質問を解釈し、継続性を維持できるからだ。履歴がないと、インタラクションは断片化され、繰り返されるようになった。ユーザーは質問を段階的に洗練させ、コンテキストがないとボットは「そのオプション」や「前のステップ」などの参照を解釈できない。

しかし、履歴を多く含めると別の問題が生じた：トークン制限。これは、言語モデルが最大コンテキストウィンドウを超える入力を切り捨てることによって発生する。質問や会話が長すぎると、重要な情報が失われる可能性があった。これは明示的なエラーを生じないが、応答の品質が低下したり、取得精度が影響を受けたりした。

これを軽減するために、プロンプトのサイズを制御し、関連するコンテンツを優先し、質問の長さを監視する戦略を実装した。古いメッセージを要約し、会話の最も関連のある部分だけを選択的に含めることを試みた。コンテキストは重要だったが、慎重に管理する必要があった。

機能の拡張と混乱の創出

ドキュメントベースの質問に答えるだけでなく、ボットの機能を拡張するために、バックエンド関数を追加した。これにより、ユーザーはアプリケーションから直接特定の公開情報を取得できるようになった。チャットからアプリ自体にログインせずにデータを取得できるようにすることで、摩擦を減らし、チャットボットを有用なインターフェースとしての地位を強化したかった。

しかし、この拡張により、一部のユーザーは混乱を経験した。ボットがライブデータを取得し始めると、ユーザーはプラットフォーム内で直接実行する必要があるアクションを実行するようボットに求めるようになった。ボットはそのようなアクションを実行するように設計されていなかったが、情報提供と操作実行の違いは常に明確ではなかった。

ライブデータの統合により、新しい技術的な考慮が必要になった。質問が埋め込みベースの取得を通じて行われるべきか、バックエンド呼び出しをトリガーするべきかを決定するロジックを慎重に設計する必要があった。また、技術的な例外を優雅に処理し、ユーザーに生のシステムエラーを表示しないように応答を調整する必要もあった。

多言語対応は自動的ではない

テスト中に、ボットは英語で一貫して他の言語よりも優れて実行されることがわかった。主な理由は構造的なものだった。埋め込みを生成するために使用されたドキュメントのほとんどは英語で書かれており、選択した埋め込みモデルは英語の意味的類似性に最適化されていた。

これは、クロスリンガルな取得や言語間の意味的比較をサポートしなかった。結果として、非英語のクエリは関連性の低いドキュメントを取得することが多く、応答が弱くなった。

これは、多言語対応が自動的ではないという重要な洞察を示唆していた。

期待がスコープを超えて拡大するとき

使用コストを制御するために、ユーザーがアスクできる質問の日次制限を実装した。ただし、質問のスコープを明示的に制限しなかった。ユーザーは自由に何でも問いただすことができた。

このオープン性により、予期せぬ使用パターンが生じた。ユーザーの一部は、アプリケーションとは無関係な個人的な目的や探索的目的でボットとやり取りし始めた。時間の経過とともに、期待はボットの意図された役割を超えて拡大し、ユーザーがボットから何を期待しているかと、実際にサポートできることとの間でギャップが生じた。

この不一致により、ボットの有用性が徐々に低下し、使用率が低下した。最終的に、ボットは廃止され、アプリケーション自体をより直感的で使いやすいものにするために再設計する努力が行われた。

教訓：インタラクションデザイン

エンジニアリング的観点から見ると、システムは妥当に機能していた。ドキュメントの取得、会話履歴の統合、埋め込みによる妄想の軽減、バックエンド呼び出し、プロンプトサイズの管理など、機能していた。アーキテクチャは意図したとおりに動作していた。

しかし、意図的なインタラクションデザインが欠けていた。

ボットは会話を明確に形成しなかった。ボットは一貫してそのスコープを強化しなかった。ボットはユーザーに何ができるか、できないかを示す構造化された例を提供しなかった。ボットは質問に答えたが、期待を設定しなかった。

私たちは、会話AIシステムは強力なモデルと構造化されたデータだけでなく、慎重に設計された期待が必要であることを学んだ。ユーザーは、エージェントの役割、境界、強みについての明確さが必要だ。システムは、プロンプトの例を提供し、制限を明確にし、スコープ外の質問を一貫してリダイレクトする必要がある。

この意図的な枠組みがないと、技術的に健全な実装であっても、価値を維持するのに苦労する可能性がある。ユーザーは機能を過大評価したり、期待が満たされない場合は関与を停止したりするかもしれない。

会話AIを構築することは技術的な課題だけではない、それはインタラクションデザインの課題でもある

強力なコンテキスト、正確な取得、頑健なアーキテクチャは必要だが、十分ではない。システムの有効性は、役割を定義し、境界を伝え、ユーザーの期待を形成する方法によっても等しく依存する。

テクノロジーだけが採用を保証するわけではない。明確なインタラクションデザインが必要だ。