Coligo: A Retrieval-Augmented Generation Assistant for WhatsApp-Based TNEA Engineering Admission Counselling

技術要約：Coligo – WhatsAppベースのTNEA工学入学事務手続き支援のための検索拡張生成（RAG）アシスタント

問題提起
タミル・ナード州の工学入学事務手続き（TNEA）は、入学手続き、学科別の授業料、およびコミュニティ別（OC, BC, BCM, MBC, SC, SCA, ST）のカットオフ・ランクに関する繰り返しの問い合わせによって、大学のフロントオフィスにボトルネックを生じさせています。現在のソリューションは、手動によるスタッフの介入や、意味理解や検証済み機関データへのアクセスを欠いた一般的なチャットボットに依存しています。以下の条件を満たす回答を提供することに、決定的なギャップが存在します：

1. グラウンデッド（根拠に基づいていること）： モデルのハルシネーション（幻覚）ではなく、公式の大学文書に厳格に基づいていること。
2. コミュニティ対応： 異なる予約カテゴリーとカットオフの種類（マーク数 vs ランク）を区別できること。
3. アクセシビリティ： 新しいアプリのインストールを必要とせず、学生がすでに利用しているプラットフォーム（WhatsApp）上で利用可能であること。
4. コンテキスト対応： （例：「ECEについてはどうですか？」のように）フルコンテキストを再提示することなく、フォローアップの質問を処理できること。

手法およびシステムアーキテクチャ
Coligoは、2つのコンポーネントからなるDocker Composeスタック（FastAPIサービスとPostgreSQLデータベース）として設計された、検索拡張生成（RAG）システムです。システムアーキテクチャは以下の通りです：

• インジェスチョン（取り込み）パイプライン： 公式の大学PDF（入学手続き、アカデミクス、カットオフを統合したもの）は、pypdfを介して処理されます。テキストは抽出され、境界を越えてコンテキストを保持するために、オーバーラップを持つチャンク（512単語、50単語のオーバーラップ）に分割されます。チャンクは、再取り込み時の重複する埋め込みを防ぐために、ハッシュ化（SHA-256）されます。
• ベクトルストレージ： チャンクはGoogleのtext-embedding-004モデル（768次元）を使用して埋め込まれ、pgvectorで拡張されたPostgreSQLデータベースに保存されます。これにより、コサイン距離を用いた意味的類似性検索が可能になります。
• 検索および生成：
  • クエリ書き換え： フォローアップの質問を処理するために、システムはセッションベースのメモリ（WhatsAppの電話番号またはセッションIDによってキー付け）を使用します。クエリがコンテキスト依存（例：「ECEについてはどうですか？」）である場合、検索用のスタンドアロンな形式にするために、別のLLM呼び出しを使用してクエリを書き換えます。ただし、最終的な回答生成には元のクエリが保持されます。
  • RAGパイプライン： システムは関連する上位5つのチャンク（RAG_TOP_K=5）を検索します。これらは、ドメインルールを強制する厳格なシステムプロンプトと共に結合されます。このプロンプトは、カットオフのマーク数とランクの区別、特定の予約カテゴリーに対する回答、およびコンテキストが不十分な場合の回答拒否を規定しています。
  • 生成： Google Gemini（LLM）は、検索されたコンテキストのみに基づいて最終的な回答を生成します。
• WhatsApp統合： システムはWhatsApp Cloud APIを介して接続されます。署名検証（X-Hub-Signature-256）を実装し、送信者のアイデンティティに基づいてメッセージをルーティングします。学生からのクエリはRAGパイプラインへ送られ、管理者からのクエリはコマンド処理のためにルーティングされます（ただし、コマンド実行は現在限定的です）。
• デプロイメント： スタックはDocker Composeを使用してコンテナ化されており、コンテナ化された環境におけるDNS解決の問題に対処するための特定の設定（外部リゾルバーの固定）が含まれています。

主な貢献
本論文は、動作するプロトタイプと当初計画されていたアーキテクチャを明確に区別し、実装された以下の貢献を強調しています：

1. コンテナ化されたTNEAパイプライン： モデルのメモリではなく、公式のPDF取り込みに依存する、WhatsApp上にデプロイされた動作するRAGシステム。
2. ドメイン特化型システムプロンプト： TNEA特有のロジック（カットオフ計算式：Math/2 + Physics/4 + Chemistry/4、およびコミュニティ別の回答の必要性）を扱うためにエンジニアリングされたプロンプト。
3. 回復力のある会話メモリ： データベースの履歴アクセスが失敗した場合でも、クラッシュすることなくステートレスな回答へと優雅にフォールバックする、セッションスコープのメモリ設計。
4. 再現可能なデプロイメント： pgvectorを備えたPostgreSQLとFastAPIを含む、コンテナ内のDNS解決の修正を含む文書化されたDocker Composeセットアップ。
5. 透明性のある報告： Redisキャッシュ、Celeryワーカー、マルチプロバイダーLLMルーティング、管理者コマンド実行などの、どのアーキテクティブコンポーネントが（プロトタイプとして）まだ実装されていないかを明示的にコードで検証し、プロトタイプを完全な生産システムと誤認することを防いでいる点。

結果および検証
著者らは、クリーンな状態からスタックを再構築し、Sri Krishna College of Engineering and Technology (SKCET) の9ページの5,048単語のPDFに対して取り込みコードを実行することで、システムを検証しました。

• インジェスチョン： パイプラインはPDFを11個のオーバーラップするチャンクに正常に処理しました。最初のチャンクは512単語、最後のチャンクは428単語であり、チャンキングのロジックが意図通りに機能していることを確認しました。
• デプロイメント： Docker Composeスタックは正常に起動し、ヘルスチェック（/healthおよび/health/detailed）はHTTP 200を返し、データベースの接続性を確認しました。
• 検証における制限： 検証環境に構成されたGEMINI_API_KEYが存在しないため、ライブのレイテンシ、検索精度、および回答の根拠となる指標は数値的に測定されていません。「検索および生成」フェーズは、ライブ実行ではなくコードレビューを通じて検証されました。
• 管理者ルーティング： システムは管理者コマンド（例：/ingest、/stats）を正しく検出しログに記録しますが、これらのコマンドの実際の実行はまだ実装されていません。

意義および主張
本論文は、Coligoを完成した商業製品としてではなく、汎用的なLLMチャットボットと硬直したキーワードベースのシステムの間の溝を埋める、検証済みのプロトタイプとして位置付けています。その主な意義は以下の通りです：

1. エンジニアリングにおける誠実さ： 著者らは、設計されたアーキテクチャ（Redis、Celery、マルチLLMルーティングを含む）と現在の実装との間の「ギャップ」を明示的に文書化しています。彼らは、プロトタイプとターゲットアーキテクチャを区別すること自体が一つの貢献であり、これによりステークホルダーが現在の状態を最終設計と誤解しないようにしていると主張しています。
2. 実践的なアクセシビリティ： WhatsAppを利用することで、システムは学生や保護者にとってのアプリインストールの障壁を取り除き、馴染みのあるプラットフォームで彼らと接点を持っています。
3. 根拠に基づいた信頼性： システムは流暢さよりも事実の正確性を優先しており、ソース文書に特定のコミュニティベースのデータが含まれていない場合は回答を拒否するように明示的にプログラムされています。これにより、入学カットオフのハルシネーションのリスクを低減しています。

本論文は、コアとなるインジェスチョンおよび検索パイプラインは機能しており検証されているものの、提案されたアーキテクチャの全容を実現するためには、管理者コマンドの実行、信頼度スコアリング、ヒューマン・イン・ザ・ループによるエスカレーション、およびマルチLLMルーティングの実装に関する今後の作業が必要であると結論付けています。