DevRev: AI ナレッジ管理に必要なのはガベージコレクタかもしれない
はじめに
AI 活用の話題では、モデルの性能やプロンプトの書き方に注目が集まりがちです。もちろん、それらは重要ですが、実際の業務で AI を使う場合、もう少し手前に大きな問題があります。
それは、AI に何を食わせるのかという問題です。
社内ドキュメント、問い合わせ履歴、チケット、仕様書、FAQ、議事録などを AI につなげれば、AI は多くの情報を参照できるようになります。しかし、参照できる情報が増えたからといって、回答品質がそのまま上がるとは限りません。
たとえば、古い仕様書が残っているかもしれません。あるいは過去の暫定対応が、現在の正式な手順のように見えるかもしれません。社内向けの情報が、顧客向けの回答に混ざるかもしれません。似た内容の記事が複数あり、どれが現在の正しい情報なのか分からなくなることもあります。
AI にも Garbage In, Garbage Out の問題があります。Garbage In, Garbage Out とは、入力される情報の品質が低ければ、出力される結果の品質も低くなるという考え方です。AI が賢くなっても、参照する情報が古ければ、古い情報をもとにそれらしい回答を返してしまいます。
この問題を考えたとき、私はガベージコレクタを連想しました。本記事では、DevRev を AI ナレッジのガベージコレクタ的な実行基盤として見たときの強みについて考察していこうと思います。
DevRev とは
DevRev は、サポート、開発、顧客情報をつなぎ、AI agents と人間が同じ業務情報を扱えるようにする SaaS です。Knowledge Base や Article により、AI が参照するナレッジを所有者、状態、公開範囲、関連情報を持つ管理対象として扱えます。
対象読者
- DevRev の強みをエンジニア向けに説明したい方
- AI に食わせるナレッジの管理に課題を感じている方
- RAG や AI agents を業務で使う際の情報管理に関心がある方
- ガベージコレクタやメモリ管理の比喩で SaaS の価値を理解したい方
参考
- DevRev
- Knowledge Base Management for Self-Service
- Computer by DevRev overview
- Explore DevRev's new article creation and article analytics dashboard
- Java Garbage Collection Basics
- C++ reference: Dynamic memory management
メモリ管理の責務はどこにあるのか
C や C++ に長く触れてきたエンジニアであれば、メモリ管理の難しさを知っていると思います。
メモリを確保したら、不要になった時点で解放する必要があります。解放を忘れればメモリリークにつながります。逆に、まだ使われているメモリを解放すれば、不正なメモリアクセスにつながります。つまり、データには寿命があります。 寿命を正しく扱えなければ、プログラムは不安定になります。
一方、Java や C# などの実行環境では、ガベージコレクタ (GC) が不要になったオブジェクトの回収を担います。 GC は、プログラムから到達できなくなったオブジェクトを検出し、そのメモリを回収します。
もちろん、GC があるからといって、メモリを完全に意識しなくてよいわけではありません。大きなオブジェクトを長く保持すれば、メモリ使用量は増えます。参照を持ち続ければ、本来不要なオブジェクトも回収されません。GC は魔法ではありません。
それでも、GC の存在によって、メモリ管理の責務の一部はアプリケーションコードから実行環境へ移りました。開発者がすべてを手作業で扱うのではなく、実行環境が寿命管理の一部を担うようになりました。
そして現在 AI に食わせるナレッジにおいても、似たことが起きているように見えます。
AI に食わせるナレッジにも寿命がある
業務で使うナレッジにも寿命があります。
作成された時点では正しかった記事も、製品仕様が変われば古くなります。公開当時は有効だった FAQ も、料金プランやサポート方針が変われば、現在の回答根拠としては使いにくくなります。過去の問い合わせ対応は貴重な情報ですが、そのまま現在の標準回答として扱えるとは限りません。
ここで問題になるのは、古い情報が存在すること自体ではありません。
過去の情報には、監査や調査のための価値があります。過去の経緯を確認するために必要な場合もあります。問題は、現在の回答に使うべきではない情報が、AI の回答根拠として残り続けることです。
メモリ管理では、不要になったオブジェクトが残り続けると、利用可能なメモリが減っていきます。同様に AI ナレッジ管理においては、現在の回答に使うべきではない情報が残り続けると、AI が参照する情報源にノイズが混ざります。結果として、回答品質や信頼性が下がりやすくなります。
さらに、AI ナレッジの扱いは、メモリ管理よりも少し複雑です。
GC が主に見るのは到達可能性です。つまり、あるオブジェクトにプログラムから到達できるかどうかです。しかしながら、AI ナレッジでは、到達できるかどうかだけでは足りません。その情報が現在も正しいのか・顧客に見せてよいのか・誰が責任を持っているのか・ほかの情報と矛盾していないのかといった観点が重要です。
AI 活用では、このナレッジの寿命管理が重要になります。
DevRev を AI ナレッジの実行基盤として見る
ここで DevRev の話に戻ります。
DevRev は、AI に食わせるナレッジを単なるテキストの集合として扱うのではなく、業務上の文脈を持つ情報として扱うための SaaS です。Knowledge Base や Article といった形でナレッジを管理し、AI による回答や検索のための情報源として利用できます。
重要なのは、ナレッジをただ保存するだけではない点です。たとえば Article には、所有者、状態、公開範囲、関連する製品情報などの管理情報を持たせられます。これにより、AI が参照する情報を、単なるドキュメントではなく、寿命を持つ管理対象として扱いやすくなります。
AI に何を見せるのか・どの情報を現在の回答根拠として扱うのか・どの情報は社内向けであり、顧客向けには見せないのか・誰がそのナレッジの更新責任を持つのか……これらは、AI 導入時に避けて通れない問題です。
外部サービスとの連携だけであれば、さまざまな方法があります。ワークフロー自動化ツールや API 連携を使えば、多くの情報を AI に渡せますが、接続できることと、AI が安心して使える状態にすることは別の問題でしょう。 DevRev の価値は、この接続後の問題にあります。
AI が参照する情報を、所有者、状態、公開範囲、関連情報を持つ管理対象として扱う。これにより、ナレッジを人間の記憶や個別運用だけに依存させず、プロダクト上で扱えるようになります。その意味で、DevRev は AI ナレッジのガベージコレクタそのものというより、ガベージコレクション的な寿命管理を可能にする実行基盤に近いと考えています。
DevRev は魔法の GC ではない
ただし、この比喩には注意も必要です。
DevRev を導入すれば、AI がすべてのナレッジの正しさを自動で判定してくれる、という話ではありません。古い記事を自動で見つけ、常に正しい情報だけを残してくれるわけでもありません。
これは、GC がある言語でも設計が重要であることに似ています。GC は不要になったオブジェクトの回収を助けます。しかし、どのようなデータ構造にするか・どの範囲で参照を持つか・どの程度のメモリ使用量を許容するかといった点は、依然として開発者が考える必要があります。
AI ナレッジ管理でも同じです。どの情報を正式なナレッジとして扱うのか・誰が内容を確認するのか・どの範囲のユーザーに公開するのか・古くなった情報をどのように退役させるのか……これらの判断には、人間の責任が残ります。
DevRev の役割は、人間の責任をなくすことではありません。責任を持つべき情報を見える場所に置き、状態や所有者や公開範囲を管理できる形にすることです。属人的な運用に頼っていたナレッジ管理を、AI が参照できる形で扱えるようにすることです。
そのため、DevRev を AI が勝手に正しい情報だけを選ぶ製品として説明するのは適切ではありません。むしろ、AI に食わせる情報の寿命管理を行うための基盤として説明する方が、製品の強みを伝えやすいと感じています。
まとめ
AI 活用では、モデルやプロンプトだけでなく、AI に食わせるナレッジの状態も回答品質に影響します。DevRev は、ナレッジを所有者、状態、公開範囲、関連情報を持つ管理対象として扱えるため、AI が参照する情報の寿命管理に向いています。 これは、GC がメモリ管理の責務の一部を実行環境へ移したことに似ています。ただし、DevRev は魔法の GC ではなく、人間が判断すべき内容を扱いやすい場所に置くための基盤と捉えるのが適切でしょう。本記事が、AI に食わせる情報の管理に悩んでいる方の参考になれば幸いです。
