当前系统的功能验证仅依赖于单一测试用例，缺乏系统性的量化评估，难以全面评估模型在实际应用场景下的泛化能力与检索准确度。下一步，我打算构建一个小型的测试集，并引入更为客观的的量化评估指标体系。同时，为突破现有检索性能瓶颈，计划进一步调研并融合前沿的RAG技术范式（如混合检索、重排机制或 Self-RAG 等），对现有的 RAG 架构进行更深入的调优。

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

目前，我们的搜索逻辑被限制在“当前会话”内。在接下来的改进中，考虑扩大搜索域，只需要将 ChromaDB的元数据过滤条件从session_id升级为当前用户的user_id。此外，也考虑用轻量级的MySQL搞定会话标题的精准查询，用重量级的ChromaDB + 大模型解决复杂对话内容的语义检索。此外，考虑到虽然大模型具备零运维、长文本兼容和强大的语义泛化优势，而本地小模型在处理短文本聊天记录时具有

目前，我们的搜索逻辑被限制在“当前会话”内。在接下来的改进中，考虑扩大搜索域，只需要将 ChromaDB的元数据过滤条件从session_id升级为当前用户的user_id。此外，也考虑用轻量级的MySQL搞定会话标题的精准查询，用重量级的ChromaDB + 大模型解决复杂对话内容的语义检索。此外，考虑到虽然大模型具备零运维、长文本兼容和强大的语义泛化优势，而本地小模型在处理短文本聊天记录时具有

3.向量数据库选型：针对RAG智能答疑的核心需求，我们在pgvector与ChromaDB之间做了最终选型：pgvector的优势是可与PostgreSQL深度融合，避免多库数据不一致的问题，但其检索逻辑需要在应用层做大量代码开发，维护成本高，不适合纯语义检索场景;综合考量后，我们团队最终选择手动维护表结构：在表结构发生变更时，通过数据库可视化工具手动修改表结构，同步更新后端对应的模型代码，虽然牺

在项目收尾阶段，我们计划接入阿里云 OSS一类的存储对象，将上传的文件经云端加速，进一步提升系统性能，但为了存储方案可以在本地与云端流畅切换，我们或许需要对于文件上传相关接口代码进行改进与优化，实现对不同文件存储方法的兼容性。虽然现阶段跑得通，但如果真的部署上线，会导致数据量过大磁盘无法承受，难以支撑多位用户同时上传图片，容易卡死，数据容易丢失，无法进行分布式的部署。改进后的前端界面如下所示，虽然

1. 全局知识点与聊天记录检索考研是一个长期复习的过程，用户经常会遇到“我记得上个月问过一道关于二叉树的题，但找不到了”的场景。我们目前已经实现了会话的分类和改名，下一步我将引入Elasticsearch 或基于数据库的全文检索机制，允许用户通过关键词，瞬间定位到历史会话中的某一个具体知识点解答。让 AI 助手真正成为用户的“个人专属知识库”。2. 进阶版混合记忆机制。

侧重桌面端展示，负责刷题、代码编辑器、可视化图表的渲染。。专门用于处理 AI 任务，如 LangChain 链路、大模型 HTTP 交互、OCR 图片解析以及 Python 代码的 AST 语法树分析。它，能高效应对大模型 API 调用的高并发与高延迟问题；为整个项目提供了极速、规范且高度契合 AI 场景的底层架构支撑。APIkey的获取：项目初期使用了智谱大模型中的免费apikey，我们暂时通过