MCoder——KnowHub项目——事后诸葛亮分析报告

MCoder——KnowHub项目

这个作业属于哪个课程	计科23级12班
这个作业要求在哪里	团队作业6——复审与事后分析

一、会议基本信息

会议时间：2025年12月20日
参会人员：王宥程、关健佳、高泽彤、黎火坤、翁广驰、王怡欧
会议目标：回顾项目过程，总结经验教训，制定改进计划

二、设想和目标

1. 软件要解决的核心问题是否清晰？

积极方面：

• 核心目标明确：为本地文档建立"第二大脑"智能问答系统
• 用户定义清晰：四类用户（政策解读、企业法务、普通用户、管理员）均有详细场景分析
• 痛点把握准确：解决了文档碎片化、检索困难、问答无记忆等问题

2. 目标达成情况如何？

功能完成度：

• 核心功能完成：知识库CRUD、PDF解析、RAG问答、流式输出、Prompt设置
• 扩展功能：图片理解、会话记忆、反馈机制
• 调整功能：RBAC权限管理因复杂度推迟至Beta

交付时间：

• 整体按计划完成，27天实际周期vs校正后27天
• 里程碑节点均按时达成，无重大延期

3. 软件质量是否得到提升？

提升表现：

• 代码复用率：核心服务层复用率从30%提升至65%
• 文档完整性：从基础API文档到完整部署指南，覆盖率85%
• 测试覆盖率：关键API测试覆盖率72%

4. 用户反馈与目标距离

Alpha测试反馈（32名测试用户）：

• 满意度：核心问答功能评分4.2/5
• 主要建议：PDF解析精度需提升、界面操作可优化
• 价值认可：90%用户认为"显著提升文档查阅效率"

三、计划

1. 原计划时间是否充裕？

充足部分：

• 需求分析与设计阶段：3天足够，团队讨论充分
• 文档编写阶段：2天时间分配合理

紧张部分：

• Milvus集成：原计划4天 → 实际6天（索引调优耗时）
• 前端流式展示：原计划4天 → 实际5天（状态管理复杂）

2. 原计划工作完成情况

任务类型	计划数	完成数	完成率	主要原因分析
核心功能	8项	8项	100%	优先级明确，资源集中
扩展功能	5项	4项	80%	RBAC因技术复杂度推迟
优化任务	6项	5项	83%	部分性能优化时间不足

3. 任务交付件定义是否清晰？

清晰部分：

• API接口：明确请求/响应格式、状态码、错误处理
• 数据库表：ER图+字段说明+索引策略
• 核心算法：RAG流程伪代码+示例

4. 计划执行中的未预期风险

风险1：Milvus版本兼容性问题

• 现象：本地2.3.0 vs Docker 2.4.0 API差异
• 解决：统一使用Docker部署，增加版本检查脚本

风险2：Ollama嵌入模型显存不足

• 现象：all-MiniLM-L6-v2在8GB内存机器加载失败
• 解决：增加内存检测，提供轻量级备选模型

5. 未来计划修改方向

1. 增加技术调研缓冲：每个技术选型增加0.5-1天调研验证
2. 实施滚动式计划：每3天回顾并调整后续计划
3. 建立风险储备：总工期预留15%的缓冲时间

四、资源

1. 资源是否充足？

充足资源：

• 开发人员：6人均有Python基础，能力匹配
• 开发环境：Git、Docker、测试服务器齐备
• 文档工具：Markdown、Swagger、Draw.io

稀缺资源：

• 测试数据：缺乏大规模真实政策PDF样本

2. 各项任务所需时间评估是否准确？

准确评估：

• 后端API开发：误差±0.5天
• 数据库设计：误差±0.5天
• 单元测试编写：误差±0.5天

低估任务：

• PDF解析优化：原估2天 → 实际3.5天（段落边界处理复杂）
• 流式前端调试：原估1天 → 实际2天（浏览器兼容性问题）

3. 测试与非编程资源评估

测试资源：

• 实际投入：2人专职测试（计划2人）
• 充足性：基本满足，但缺乏自动化测试经验

非编程资源：

• UI设计：严重低估，原估3天 → 实际5天
• 文档编写：适度低估，原估2天 → 实际3天

4. 工作效率是否有提升空间？

提升空间分析：

1. 代码审查效率：初期无规范 → 后期制定checklist，效率提升40%
2. 环境配置：初期每人独立配置 → 后期提供Docker镜像，时间减少70%
3. 会议效率：初期无议程 → 后期使用模板，会议时间减少30%

五、设计/实现

1. 设计中的模糊问题与解决方式

问题1：向量检索相似度阈值设置

• 模糊点：多少相似度视为相关文档？
• 解决：通过100个测试问题统计，确定0.75为阈值
• 方法：A/B测试 + 人工评估

问题2：会话记忆存储策略

• 模糊点：保存多少轮历史？如何清理？
• 解决：采用滑动窗口（最近10轮）+ 按时间自动清理

2. 开发工具与文档一致性

工具应用情况：

• UML：使用PlantUML绘制序列图、类图
• 单元测试：pytest + 覆盖率报告
• TDD：仅在核心服务层部分采用

3. 代码复审与规范执行

复审流程：

1. PR创建 → 2. 自动检查（flake8, mypy） → 3. 至少2人人工复审 → 4. 合并

执行情况：

• 复审覆盖率：核心模块100%，普通模块85%
• 平均复审时间：每个PR约15-30分钟
• 规范执行率：从初期60%提升至后期90%

六、测试/发布

1. 测试计划制定情况

计划完整性：基本完整但可细化

• 覆盖了所有核心功能模块
• 明确了测试类型和分工
• 性能测试用例不够详细

2. 验收测试执行情况

执行方式：

• 内部验收：团队交叉测试，覆盖100%核心功能
• 外部测试：32名用户参与，收集有效反馈127条
• 缺陷跟踪：使用GitHub Issues管理，闭环率92%

3. 测试工具应用与改进计划

当前工具栈：

• 单元测试：pytest + coverage
• API测试：httpx + pytest-asyncio
• 前端测试：人工测试为主
• 性能测试：locust（基础使用）

改进计划：

1. 自动化测试：

   • 目标：核心API自动化测试覆盖率>90%
   • 工具：Playwright（前端E2E）+ pytest（后端）

2. 性能测试深化：

   • 目标：建立性能基线，监控关键指标
   • 工具：locust + 自定义监控脚本

4. 软件效能与压力测试

已测量指标：

• 平均响应时间：非流式3.2s，流式首字节1.1s
• 并发能力：20用户同时问答，响应时间<5s
• 内存使用：处理50页PDF时峰值2.1GB

压力测试发现的问题：

• 问题：50并发时Milvus连接池耗尽
• 解决：调整连接池参数，增加重试机制

5. 发布过程中的意外问题

问题1：Docker镜像构建失败

• 现象：requirements.txt版本冲突
• 解决：锁定版本，使用Pipenv管理

问题2：跨浏览器兼容性问题

• 现象：Safari流式输出异常
• 解决：增加浏览器检测和降级方案

七、团队成员在Alpha阶段的角色和具体贡献

名字	学号	角色	团队贡献分	可验证的贡献
王宥程	3123004714	前端开发+UI设计	12	设计并实现完整前端界面；制定UI规范文档；解决跨浏览器兼容性问题
翁广驰	3123004409	后端核心开发+架构设计	38	设计整体API架构；实现问答服务核心逻辑；编写技术方案文档
关健佳	3121004072	向量存储专家+部署运维	19	部署并优化Milvus向量数据库；设计向量检索策略；编写部署文档
黎火坤	3123004310	LLM集成+记忆模块	19	实现会话记忆功能；设计Prompt工程模板；优化多轮对话逻辑
高泽彤	3123004304	数据库设计+API开发	19	设计数据库Schema；实现知识库CRUD接口；优化查询性能
王怡欧	3223004344	文档处理+测试验证	13	实现PDF解析与分块模块；设计测试用例；执行端到端测试

贡献分计算依据：

• 技术复杂度权重：40%
• 工作量完成度：30%
• 质量与文档：20%
• 团队协作：10%

八、Alpha阶段关键数据总结

指标类别	具体指标	Alpha目标	实际达成	达成率
功能完成	核心功能数	8项	8项	100%
	扩展功能数	5项	4项	80%
时间管理	总工期	27天	27天	100%
质量指标	Bug总数	≤15	7	-
	测试覆盖率	>70%	86%	123%
用户反馈	满意度评分	4.0/5	4.2/5	105%
团队效能	任务完成率	>85%	88%	104%

九、Beta阶段重点改进方向

1. 技术债务清理（优先级：高）

   • 重构PDF解析模块，提高鲁棒性
   • 优化内存管理，防止泄漏

2. 测试体系建立（优先级：高）

   • 实现核心API自动化测试
   • 建立性能测试基线

3. 用户体验优化（优先级：中高）

   • 简化首次配置流程
   • 增加批量操作功能

4. 过程改进（优先级：中）

   • 建立组织过程资产库
   • 完善需求管理流程