Slackのスレッドから構造化ナレッジへ：SnykにおけるRAGの導入
著者
0 分で読めます
Snykのミッションは、組織が迅速に開発しながら安全性を確保できるよう支援することです。社内においては、日々生み出される豊富な組織内ナレッジを、各チームがすぐに活用できるようにすることを意味します。その重要な情報源の一つがSlackです。
Slackは、最新情報や技術的な議論、価値あるQ&Aの中心的なハブとして機能しています。しかし、頻繁に利用する方ならご存じのとおり、会話形式であるがゆえに、重要な情報はスレッドやチャンネル、無数のメッセージにすぐ埋もれてしまいます。
そこで活用するのが、検索拡張生成（RAG）です。RAGは、大規模言語モデル（LLM）に、元の学習データには含まれていない特定の最新情報を提供することで、その能力を強化します。私たちの目標は、Slackに蓄積された豊富な知見を活用し、よりスマートな社内Q&Aツールを実現することでした。
データにまつわる課題を理解する
この取り組みは、複雑なアルゴリズムではなく、Slackに蓄積された雑多で現実的なデータを深く理解することから始まりました。Slackのメッセージはきれいに整理されているわけではありません。カジュアルな会話や絵文字、ユーザーを示す<@U123ABC>やチャンネルを示す<#C456DEF>のような分かりにくい識別子が含まれています。このプロセスを通じて、基本となる原則は常に明確でした。「モデルにゴミを入れれば、ゴミしか出てこない」。ソリューションの構築に着手する前に、いくつかの重要な課題が見えてきました。
価値ある情報の特定：会話のノイズの中から関連データを見つけるには、慎重な選別が必要でした。
チャンク分割の戦略：データをどのように分割するかの判断は困難でした。スレッドによって大きな差があり、短時間に投稿が集中するチャンネルもあれば、投稿がまばらなチャンネルもありました。日単位やローリングウィンドウによるチャンク分割など、従来の方法には一貫性や焦点が欠けるという問題がありました。
Slack IDの解読：読みやすさを確保するため、ユーザーIDやチャンネルIDを意味の分かる名前に変換する必要がありました。
Markdownへの変換：当初、スレッドをMarkdownに変換するのは簡単に思えました。しかし、生のMarkdownには絵文字やリアクション、入れ子になった返信が大量に含まれ、LLMを混乱させる可能性がありました。
「なるほど！」の瞬間：中核となるQ&A構造
RAGシステムを構築する本来の目的、つまり従業員の質問に答えることに立ち返ったとき、突破口が見えてきました。あらかじめ定義したチャンクにデータを無理に当てはめるのではなく、明確なQ&Aのやり取りを軸に情報を構造化する方法へと切り替えました。質問が投稿され、回答が寄せられたSlackの各スレッドを、単一の構造化ドキュメントチャンクとして扱いました。
この直感的な方針転換によって、プロセスが効率化されました。
質問の特定：#ask-productのように、質問用に明確に設計されたSlackチャンネルに注目しました。
要約にLLMを活用：GoogleのGemini APIにSlackのスレッドを渡し、「明確な質問と包括的な回答を抽出してください」といったプロンプトを使用しました。これにより、RAGシステムですぐに利用できる高品質で構造化されたデータを生成できました。
検索戦略：効率的に検索できるよう、抽出した質問のみを埋め込みました。ユーザーのクエリと保存済みの質問を比較して検索します。重要なのは、LLMに渡すのは質問そのものではなく、最も類似する保存済み質問の回答（メタデータとして保存）であるという点です。これにより、最も関連性の高いコンテキストをモデルに渡すことができました。
フォールバックの方法：価値あるスレッドのすべてが、分かりやすいQ&A形式とは限りません。そのような場合は、より広い文脈を保つために、スレッドを読みやすいMarkdownの要約に整形しました。
継続的な更新：新しいメッセージが追加されるたびにシステムが要約を動的に再生成し、ナレッジベースを常に最新の状態に保ちます。
ソリューションの導入
Q&A構造を軸に据えたことで、技術的なワークフローが明確になり、効果的に機能するようになりました。
Slack SDK：Slackからメッセージを直接取得します。
Gemini API：スレッドを構造化されたQ&A、または要約したMarkdownに変換します。
Snowflake Cortex Search Service：構造化された出力を保存し、質問から埋め込みを作成します。
RAGアプリケーション：従業員がクエリを入力すると、埋め込みを作成して保存済みの質問と意味的に比較します。関連する回答をメタデータから取得し、文脈に即した正確な応答を生成します。
APIの先へ：エンジニアリングの現場から得た知見
最終的なソリューションを支えたのは、画期的なアルゴリズムではありません。データを深く理解し、創意工夫で問題を解決し、アプローチを反復的に改善したことです。エンジニアリングにおける真の成果は、APIの統合や埋め込みの実装だけではなく、私たちの根本的な課題を解決するためにデータを緻密に構造化したことにありました。
Q&Aを中心とするこの戦略は、RAGの仕組みに自然に適合し、Slack上の混沌とした会話を明快でアクセスしやすいナレッジに変換します。革新的なAIソリューションは、複雑な技術だけではなく、人を中心に据えた洞察から生まれることを示す好例です。
セキュリティインシデントの大半は、防げるミスが原因です。
継続的で状況に即した実践的なトレーニングで、リスクを軽減する方法をご紹介します。