这段时间，团队在实现基础 LLM 对话和流式输出后，针对“大模型无记忆”、“单点对话限制”及“交互模态单一”等痛点，进行了核心功能的重构与完善。

阶段性功能开发概览

在本阶段的实训中，我们团队更为全面的考虑到了真实的应用场景，从会话管理、上下文记忆、多格式文件解析、用户收藏以及语义检索五个维度对问答系统进行了完善。具体开发进展如下：

一、 引入多会话管理与“滑动窗口”记忆机制

• 全生命周期会话管理： 设计并实现了完整的 RESTful API（创建、按用户拉取、搜索、重命名、获取历史记录）。独立的会话名称属性为后续的全局检索打下了数据基础。

• 上下文动态注入（滑动窗口法）： 针对大模型 API 的无状态特性，我们调研了不同的记忆等方案。结合考研用户短期多次追问的场景特点，最终选用了兼顾性能与 Token 成本的滑动窗口截断法。在组装 Prompt 时，后端强制截取最近的几条消息注入上下文，让 AI 拥有了短期连续记忆。

二、 构建文件解析架构（支持 PDF/Word/图片）

单靠纯文本无法满足学习助手的需求。我们开发了强大的 FileProcessor 模块，为系统赋予了“阅读”文档的能力。考虑到目前项目接入的是纯文本模型，且未来有升级多模态（Vision LLM）的计划，我们设计了较为兼容的架构：

• PDF 深度处理（PyMuPDF）： 在纯文本模式下，提取前 20 页文本防止 Token 爆炸；在多模态模式下，支持将页面放大两倍渲染为高清 PNG 并转 Base64，确保模型能看清复杂排版。

• Word 深度榨取（python-docx）： 针对 Word 文档，我们不仅提取纯文本，更通过遍历底层数据，将表格转化为大模型极易理解的 Markdown 语法（|列1|列2|）；同时精准捕捉隐藏的二进制图片流，结合 OCR 技术或多模态接口进行解析。

• 前端优化： 摒弃了将冗长 Markdown 链接放入聊天框的做法。我们在输入框上方新增了“暂存区”，文件上传后展示高清缩略图或专属 Icon，并支持删除。

三、 聊天收藏系统

为了让用户能够积累复习资料，我们上线了带有备注功能的收藏系统。

• 数据库关联设计： 采用精简表结构，BookmarkedChat 仅记录用户 ID、备注及关联的 message_id。通过高效的 JOIN 查询，顺带拉取 ChatMessage 表中的具体内容，避免了数据冗余。

• API 容错处理： 解决并修复了 Pydantic Schema 校验导致的 ResponseValidationError，通过将 content 设为可选字段，确保了修改备注等独立操作的顺利进行。

• 前端布局优化： 在前端实现了收藏列表弹窗与独立滚动条设计，解决了全局滚动条带来的布局错乱问题，并对整体页面框架与 Logo 区域进行了视觉优化。

四、 基于 ChromaDB 的会话级语义检索

当历史对话增多后，传统的“全文检索（如 Lucene）”由于过于死板，无法满足用户模糊记忆下的搜索需求。为此，我们团队引入了向量检索（语义检索）。

• 数据库选择： 确立了 MySQL + ChromaDB 的双库架构。MySQL 保障会话生命周期的绝对稳定，ChromaDB 专职负责将文本转化为高维向量。

• 向量模型选择： 采用了智谱最新的 Embedding-3 模型。在存入数据前，剔除了无用词和非文本消息，确保向量库的纯净。用户搜索时，系统计算相似度并返回 Top-K 结果，即使关键词不完全一致，也能精准定位语义相同的历史解答。

团队下一步计划

1. 文件存储架构平滑迁移： 目前采用的本地文件存储（/uploads）在并发和扩容上面临瓶颈。团队考虑在成本合理的情况下在项目收尾阶段封装存储接口，平滑接入阿里云 OSS 或 MinIO，实现云端加速。

2. 全局搜索与混合检索： 将语义检索的范围从“单会话”扩展至“全局 user_id”。尝试结合轻量级 MySQL 精准查询与 ChromaDB 语义泛化，采用更高效的混合检索机制，并探索使用本地开源 Embedding 模型以降低 API 成本。

3. 学习画像与进阶记忆： 探索“滑动窗口（短期） + RAG（长期） + 标签抽取”的混合架构。通过后台异步请求让大模型总结用户的知识薄弱点并存入数据库，结合可视化图表，为用户生成个性化的量化复习报告。