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）录取分数线（cutoff）的重复性查询所淹没。目前的解决方案依赖于人工干预或缺乏语义理解且无法访问经过验证的机构数据的通用聊天机器人。目前存在一个关键的技术差距，即如何提供满足以下要求的答案：

1. 有据可依： 严格基于官方学院文档，而非模型的幻觉。
2. 具备社区意识： 能够区分不同的预留类别和录取分数类型（分数 vs 排名）。
3. 易于获取： 在学生已使用的平台（WhatsApp）上可用，无需安装新的应用程序。
4. 具备上下文感知： 能够处理后续问题（例如，“那 ECE 专业呢？”）而无需用户重新陈述完整的上下文。

方法论与系统架构
Coligo 是一个基于检索增强生成（RAG）系统的两部分 Docker Compose 堆栈（FastAPI 服务和 PostgreSQL 数据库）。其系统架构如下：

• 摄取流水线： 通过 pypdf 处理官方学院 PDF（合并录取程序、学术信息和录取分数线）。提取文本并将其分割为重叠的分块（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 进行连接。它实现了 Webhook 签名验证（X-Hub-Signature-256）并根据发送者身份路由消息：学生查询进入 RAG 流水线，而管理员查询则被路由用于命令处理（尽管命令执行目前受到限制）。
• 部署： 该堆栈使用 Docker Compose 进行容器化，并针对容器化环境中的 DNS 解析问题进行了特定配置（固定外部解析器）。

核心贡献
论文明确区分了工作原型与最初规划的架构，强调了以下已实现的贡献：

1. 容器化的 TNEA 流水线： 一个部署在 WhatsApp 上的工作 RAG 系统，它依赖于官方 PDF 摄取而非模型记忆。
2. 特定领域的系统提示词： 经过工程设计的提示词，旨在处理 TNEA 特有的逻辑，包括录取分数计算公式（数学/2 + 物理/4 + 化学/4）以及对社区差异化响应的需求。
3. 具有韧性的对话记忆： 一种基于会话范围的记忆设计，如果数据库历史访问失败，它会优雅地降级为无状态回答，而不是崩溃。
4. 可复现的部署： 一个记录完整的 Docker Compose 设置，包含带有 pgvector 的 PostgreSQL 和 FastAPI，并包含了针对容器 DNS 解析问题的修复方案。
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 路由，以实现所提议架构的全貌。