05组-选题与需求分析报告
成员擅长技术任务刘华胜AI 、前后端增量式知识图谱构建吴君凯AI、前后端增量式知识图谱构建何君豪前端pdf阅读器前端构建洪顺兴前端pdf阅读器前端构建潘炜豪后端pdf阅读器后端构建杨良烨后端pdf阅读器后端构建刘伟兴后端、文书攥写产品测试及报告攥写。
https://blog.csdn.net/CliPg/article/details/155077326
一、团队集结
1.1 团队成员介绍
| 成员 | 擅长技术 | 任务 |
|---|---|---|
| 刘华胜 | AI 、前后端 | 增量式知识图谱构建 |
| 吴君凯 | AI、前后端 | 增量式知识图谱构建 |
| 何君豪 | 前端 | pdf阅读器前端构建 |
| 洪顺兴 | 前端 | pdf阅读器前端构建 |
| 潘炜豪 | 后端 | pdf阅读器后端构建 |
| 杨良烨 | 后端 | pdf阅读器后端构建 |
| 刘伟兴 | 后端、文书攥写 | 产品测试及报告攥写 |
1.2 团队特色
我们团队由七名成员组成,技术结构完整、分工明确,既覆盖前后端开发能力,又具备 AI 技术积累与文书撰写能力,使得整体协作具备高效性与专业性。
1.3 团队logo



二、开始行动
2.1 背景与价值
2.1.1选题背景
当今大语言模型已深深融入我们的日常生活,但是使用的过程,可能会因为上下文长度有限和知识库未更新,存在出现幻觉的现象。而知识图谱可以将信息化为实体和关系,进行结构性的表示,从而降低幻觉。传统知识图谱构建方法依赖人工标注或规则提取,成本高且难以扩展。利用大语言模型自动化知识抽取和知识图谱的构建成为了更高效的方法。
2.1.2 应用价值、社会价值
利用LLM增量地构建知识图谱,能够把分散、难以检索的文本转化为结构化、可计算、动态的知识,从而让机器能真正理解和利用文档内容。它的应用价值主要体现在显著降低信息整理成本、提升科研和企业知识管理效率,并在依赖专业文档的行业中推动自动化与智能化。它的社会价值体现在提升公众获取知识的便利性,减少信息碎片化,提高公共治理与决策的科学性,同时为更可信、更可解释的智能系统提供知识基础,推动整个社会的信息利用从“阅读文本”向“理解知识”升级。
2.1.3 预期目标
- 实现高精度的实体和关系抽取,控制图谱质量。
- 处理孤立实体问题,确保知识图谱的连通性。
- 支持实体消歧,通过名称和标签的加权嵌入避免混淆
- 实现知识图谱的实际应用
2.2 个人贡献分的计算
1. 任务完成度贡献(40%)
每个成员在一个迭代中负责的任务会被记录在项目管理工具中,最终根据以下因素计入贡献:
- 是否按时按质完成
- 是否产生可交付成果(代码、文档、测试、原型等)
- 任务的重要性(核心模块 vs 辅助任务)
换句话说,任务完成度不仅反映工作量,也反映任务价值,避免出现“做了一堆低价值事情但贡献很高”的误区。
2. 过程参与度贡献(30%)
《构建之法》明确指出:一个好工程师的价值不只是写代码,过程参与本身就是贡献。为了鼓励所有成员遵循流程、参与工程,我们把以下行为计为贡献:
- 按时参加例会(站会、迭代会)
- 主动提交设计文档、测试报告、会议纪要
- 按流程提交 Git Commit,保持代码可读性
- 参与 Code Review 并给出有效意见
- 协助解决他人遇到的工程问题
这些行为能够使团队整体运作顺畅,而不是各自为战。
3. 团队协作贡献(30%)
决定一个工程师价值的不是他一个人写了多少代码,而是他是否让整个团队变得更强。
因此我们设置团队协作贡献,由所有成员匿名互评,包括:
- 是否有责任心、能被信任完成任务
- 是否及时同步进度、不拖延、不甩锅
- 沟通是否顺畅、是否积极解决冲突
- 是否对团队气氛和效率产生正面影响
为了避免互评流于主观,我们采用“去极值平均法”(去掉最高分和最低分),保持客观性。
最终贡献分计算方式
贡献分按权重综合计算:
贡献总分=0.4×任务完成度+0.3×过程参与度+0.3×团队协作度
三、点滴记录
3.1思维导图和燃尽图
3.1.1思维导图

3.1.2燃尽图
| 项目阶段 | 时间节点 | 计划剩余任务量(任务点) | 实际剩余任务量(默认按计划推进,可按需调整) | 关键里程碑标注 |
|---|---|---|---|---|
| 项目启动前 | 第 0 周(基准) | 80 | 80 | - |
| 第一周结束 | 第 1 周末 | 65 | 65 | 需求文档 / 接口规范定稿,开发环境就绪 |
| 第二周结束 | 第 2 周末 | 50 | 50 | 双端基础版本可用(导入 / 阅读 / 收藏 / 历史) |
| 第三周结束 | 第 3 周末 | 38 | 38 | 翻译功能 + AI 基础问答(无 PoG)完成 |
| 第四周结束 | 第 4 周末 | 28 | 28 | 知识图谱增量构建(iText2KG)完成 |
| 第五周结束 | 第 5 周末 | 18 | 18 | 增强 AI 问答(RAG+PoG)完成,响应≤3 秒 |
3.2
(1)文档蒸馏与实体关系的提取模块
-
负责人:刘华胜、吴君凯
-
描述:基于 iText2KG 模型,对 PDF 文档进行文本蒸馏、原子事实拆分,提取实体与关系,为知识图谱构建提供原始数据。
-
该部分面临的问题:文本拆分粒度不合理(过细导致关系断裂,过粗导致信息冗余);实体提取准确率低(多义词、专业术语识别不足);不同 PDF 格式(纯文本、扫描件)适配性差。
-
解决的问题:实现文本按语义合理拆分,提升实体与关系提取准确率,支持多格式 PDF 的蒸馏处理。
-
应用设计:采用管道模式串联 “文本拆分→原子事实提取→实体关系识别” 流程,结合策略模式适配不同 PDF 格式的蒸馏策略,解决文本处理与实体提取的效率和准确率问题。
-
附:
活动图

(2)增量式构建知识图谱模块
- 负责人:刘华胜、吴君凯
- 描述:基于文档蒸馏模块输出的实体关系,增量式合并实体、更新关系,构建并维护知识图谱,避免数据冗余。
- 该部分面临的问题:实体重复存储(同一实体因名称变体多次入库);图谱随文档增多持续膨胀(无淘汰机制);实体关系更新不及时(新增文档的关系未同步)。
- 解决的问题:实现实体相似度匹配与增量合并,控制图谱规模,保证实体关系的实时更新。
- 应用设计:采用观察者模式监控新实体关系的产生,结合状态模式管理实体合并逻辑(未匹配→待合并→已合并),解决实体重复与图谱膨胀问题。
- 附:
活动图

(3) PDF 阅读器基础功能模块
-
负责人:何君豪、洪顺兴、杨良烨
-
描述:实现 PDF 阅读器的基础交互功能,包括文件打开、历史记录管理、收藏管理,保障用户基本阅读流程。
-
该部分面临的问题:多格式文件打开兼容性差(如加密 PDF、特殊编码);历史记录加载卡顿(多文件场景);收藏功能操作繁琐(无快捷入口)
-
解决的问题:支持多格式 PDF 打开,优化历史记录性能,简化收藏操作,实现双端界面统一。
-
应用设计:采用组件化设计拆分基础功能为独立 Widget(如文件选择组件、历史记录组件、收藏组件),结合状态模式管理界面状态(未打开→加载中→阅读中→收藏中),解决功能耦合与跨平台适配问题。通过SQLite 事务机制保证收藏 / 历史记录操作的原子性。
-
附:
时序图

用例图
类图
活动图
实体关系图
状态图
(4)PDF 阅读器基于知识图谱的对话增强功能模块
- 负责人:刘伟兴、潘炜豪、杨良烨
- 描述:基于构建的知识图谱,集成 RAG 与 PoG 技术,实现对 PDF 文档的智能问答增强,支持复杂问题分解与多知识源融合回答。
- 该部分面临的问题:问答与知识图谱关联度低(仅检索文本,未结合图谱关系);复杂问题分解能力不足(如多步骤问题无法拆解);多模块(RAG、PoG、知识图谱)协同效率低。
- 解决的问题:实现问答与知识图谱实体关系的深度融合,提升复杂问题回答准确率,优化多模块协同流程。
- 应用设计:采用管道模式串联 “问题解析→PoG 分解→知识图谱检索→RAG 文本检索→答案生成” 流程,结合策略模式适配不同类型问题的回答策略(事实型、推理型),解决问答准确率与模块协同问题。
- 附:
类图
3.3 团队进度(每周追加)
| 第 N 周 | 新增代码(行) | 累计代码(行) | 本周小组学习总耗时 (小时) | 累计小组学习总耗时(小时) | 重要进度 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 5 | 5 | 1. 全员熟悉技术栈核心特性:PyQt5 信号 - 槽机制、自研 Socket 框架多线程 / 热加载原理、RAG 基础流程(文档解析→向量存储);2. 完成需求细化文档编写,明确 PDF 格式支持范围(PDF/A、普通文本 PDF)、知识图谱存储方案(SQLite 基础存储 + Neo4j 备选);3. 统一双端开发环境(Windows Python 3.10+Pyvenv+PyQt5、Linux XDE 桌面 + 同版本依赖),确保现有 GitHub 仓库(ling)代码可正常运行 |
| 2 | 1000 | 1500 | 12 | 17 | 1. 前端组:通过 PyQt5 布局练习,掌握 Fluent 风格控件(按钮、弹窗、侧边栏)用法,完成阅读页面原型开发(整合阅读区、左侧收藏 / 历史记录栏);2. 后端组:完成 PDF 导入核心功能(基于 PyPDF2 库扩展,支持多文件批量导入),开发收藏 / 历史记录增删改查接口(SQLite 表设计:文件 ID、路径、收藏状态、访问时间);3. 测试组:学习软件测试基础方法,编写基础功能测试用例(导入成功率、收藏同步延迟) |
| 3 | 1200 | 2700 | 15 | 32 | 1. AI 组:学习 LangChain 翻译接口集成方法,完成实时翻译功能开发(支持选中文本弹窗翻译、全文翻译),搭建 RAG 基础框架(使用 Chroma 向量库存储文档文本嵌入,检索阈值初设 0.7);2. 前端组:通过 Qt 事件处理练习,掌握交互控件逻辑,完成 AI 对话面板开发(输入框、问答历史滚动显示、翻译结果弹窗);3. 后端组:优化文本提取接口(解决 PDF 中图片内嵌文本无法识别问题),累计完成基础功能模块代码联调 |
| 4 | 1500 | 4200 | 18 | 50 | 1. AI 组:深入学习 iText2KG 的 ATOM pipeline 原理(原子事实分解、5 元组提取、并行合并),完成核心模块集成(将 PDF 文本拆分为≤400token 的原子事实,提取(实体1, 关系, 实体2, t_start, t_end));2. 后端组:设计知识图谱存储表结构(实体表:ID、名称、类型;关系表:ID、实体 1ID、实体 2ID、关系类型、时间戳),实现图谱增量更新接口(避免重复实体存储,合并相同关系的时间戳);3. 全员学习知识图谱基础概念(实体 / 关系定义、Neo4j 基础操作),累计解决 3 类技术卡点(原子事实拆分粒度、向量库与 SQLite 数据同步) |
| 5 | 1800 | 6000 | 20 | 70 | 1. AI 组:研究 PoG 的任务分解与路径探索逻辑,完成 RAG+PoG 整合(用户问题→PoG 分解为子目标→知识图谱定位相关实体→RAG 检索文档→生成答案),调试关键参数;2. 后端组:优化自研 Socket 框架的多线程性能(解决 AI 计算阻塞 UI 问题,实现问答请求异步处理),完成 AI 模块与存储模块数据联调;3. 前端组:学习知识图谱可视化基础(使用 PyQtGraph 绘制简单实体关系图),扩展 AI 对话面板功能(显示问答关联的实体节点);4. 累计完成增强版 AI 问答功能测试,关键指标达标(复杂问题分解成功率≥80%,响应时间≤3 秒) |
3.4 心得体会
1. UML 设计工具的选择、理由与评价
选择的工具:StarUML(主力)+ 畅图(辅助)
- 选择理由:
- StarUML 支持完整的 UML 图类型(含用例图、类图等 5 类必做图),且支持 PyQt5 代码反向生成,可快速校验类图与实际代码的一致性,适配阅读器模块化开发需求;
- 畅图支持 “自然语言转 UML”,对于知识图谱构建、AI 对话流程等复杂模块,可快速生成活动图 / 状态图初稿,降低设计门槛;
- 两款工具均支持多人协作(StarUML 通过 Git 同步,畅图支持在线共享),适配团队分工设计,且免费版功能足够覆盖本次项目需求。
- 使用评价:
- 优势:StarUML 的类图设计逻辑严谨,能清晰呈现 PyQt5 组件的继承与关联关系,代码反向生成功能大幅提升设计校验效率;畅图的操作直观,活动图、时序图的绘制速度快,15 分钟即可完成复杂流程设计。
- 不足:StarUML 免费版导出文件有水印,需手动裁剪;畅图的复杂类图(多继承、多关联)绘制功能较弱,知识图谱模块的类图需手动调整布局。
2. 本次任务遇到的困难及解决方法
困难 1:AI 模块 RAG 检索结果与知识图谱实体 “脱节”,导致问答准确率低(第 5 周)
困难描述
第 5 周集成 RAG+PoG 时发现:AI 问答仅能从文档文本中检索内容,无法关联知识图谱中的实体关系(如用户提问 “文档中提到的‘RAG 技术’的应用场景”,AI 仅返回文本片段,未结合图谱中 “RAG - 应用场景 - 文献阅读” 的关联关系),导致问答信息不完整,准确率仅 65%,未达预期的 80%。
做过的尝试
- 首次尝试:调整 RAG 检索阈值(从 0.7 降至 0.5),希望扩大检索范围以覆盖实体相关文本,但结果导致冗余信息增多(如返回无关的 “PDF 导入步骤” 文本),准确率进一步下降至 58%;
- 二次尝试:在 RAG 检索前增加 “实体提取步骤”—— 先从用户问题中提取关键词(如 “RAG 技术”),再根据关键词查询知识图谱获取关联实体 ID,将实体 ID 作为检索条件传入 RAG,但因未处理 “一词多义” 问题(如 “RAG” 在文档中曾指代 “文档检索” 和 “向量存储”),检索结果仍存在偏差;
- 三次尝试:参考 iText2KG 的 “实体 - 文本关联” 逻辑,在知识图谱中为每个实体存储 “关联文本片段 ID”,当 RAG 检索到文本片段后,自动通过片段 ID 关联图谱实体,再将实体关系补充到问答结果中(如检索到 “RAG 提升问答准确率” 的文本后,关联图谱中 “RAG - 效果 - 准确率提升” 的关系)。
是否解决
是。优化后 AI 问答准确率有所提升,且能同时返回文本片段与图谱实体关系,回答更完整(如用户提问时,AI 会补充 “根据知识图谱,RAG 技术在文献阅读场景中可减少模型幻觉”)。
有何收获
- 技术层面:理解了 “多模块数据关联” 的核心 ——AI 问答不仅需要文本检索,还需结合知识图谱的结构化数据,需在模块设计初期预留 “数据关联接口”(如本次优化后,在 RAG 模块与知识图谱模块间新增了 “片段 ID - 实体 ID” 映射表);
- 协作层面:AI 组与后端组需同步数据结构设计(如后端组需提前在知识图谱表中新增 “文本片段 ID” 字段),避免后期因数据不兼容导致的返工,验证了 “前期 UML 图同步设计” 的重要性。
困难 2:前端 PyQt5 界面在 Linux(XDE 桌面)下控件适配异常(第 2 周)
困难描述
第 2 周完成前端基础版本后,在 Windows 系统下界面显示正常(Fluent 风格的侧边栏宽度、按钮间距符合预期),但在 Linux XDE 桌面下出现两个问题:① 左侧收藏栏宽度压缩至原尺寸的 1/2,文字显示不全;② 翻译弹窗位置偏移(始终显示在屏幕左上角,无法跟随鼠标选中位置),影响用户体验。
做过的尝试
- 首次尝试:检查 PyQt5 布局代码,发现使用了 “固定宽度”(如
self.sidebar.setFixedWidth(200)),推测 Linux 与 Windows 的像素渲染差异导致适配问题,将固定宽度改为 “相对宽度”(self.sidebar.setMinimumWidth(200)+self.sidebar.setMaximumWidth(250)),但收藏栏宽度仍不稳定(时而 200px,时而 220px); - 二次尝试:查阅 Qt 官方文档,发现 PyQt5 的
QWidget在不同桌面环境下的 “默认样式表” 存在差异(XDE 桌面默认字体大小为 10pt,Windows 为 9pt),导致控件尺寸计算偏差,遂在代码中统一设置全局样式表(QApplication.setStyleSheet("QSideBar{font-size:9pt; min-width:200px;}")),解决了收藏栏宽度问题,但弹窗位置偏移仍未解决; - 三次尝试:跟踪翻译弹窗的位置计算逻辑,发现原代码使用
QCursor.pos()获取鼠标位置(Windows 下返回屏幕绝对坐标),但 Linux XDE 桌面下QCursor.pos()返回的是 “当前窗口相对坐标”,导致弹窗定位错误,修改代码为 “获取屏幕绝对坐标 + 窗口偏移量”(global_pos = self.mapToGlobal(QCursor.pos())),弹窗位置恢复正常。
是否解决
是。优化后 Linux XDE 桌面下的界面与 Windows 保持一致,控件无错位、文字无遮挡,跨平台适配达标。
有何收获
- 技术细节:跨平台开发需关注 “系统底层差异”(如坐标计算、样式表默认值),不能直接复用单系统的代码逻辑,需针对性处理兼容性问题;
- 调试方法:遇到适配问题时,优先查阅官方文档(而非仅依赖搜索引擎),Qt 文档中明确标注了
QCursor.pos()在不同系统下的行为差异,比零散的博客信息更可靠; - 团队分工:前端组后续开发中新增 “双端同步测试” 环节(每次修改界面代码后,需在 Windows 和 Linux 下各测试 1 次),避免后期集中修复适配问题的高额成本。
困难 3:知识图谱增量更新时出现 “实体重复存储” 问题(第 4 周)
困难描述
第 4 周集成 iText2KG 后,多次导入同一主题的 PDF(如 2 篇关于 “RAG 技术” 的文献),知识图谱中出现重复实体(如 “RAG 技术” 被存储为 2 个不同 ID 的实体,分别关联不同文献),导致后续 AI 检索时出现 “同一实体多结果” 的混乱。
做过的尝试
- 首次尝试:在实体入库前增加 “名称匹配校验”(如判断 “RAG 技术” 是否已存在于实体表),但因存在 “同义词” 问题(如另一篇文献称 “检索增强生成技术”),无法识别同义实体,仍有重复;
- 二次尝试:参考 iText2KG 的 “原子事实合并” 逻辑,为每个实体增加 “标准化标签”(如将 “检索增强生成技术” 映射为标准名称 “RAG 技术”),但手动维护标签映射表效率低(7 人团队需逐一标注同义词);
- 三次尝试:引入 “实体相似度匹配”(使用余弦相似度计算新实体与现有实体名称的相似度,阈值设为 0.8),当新实体名称与现有实体相似度≥0.8 时,判定为同一实体,仅更新其 “关联文献 ID” 和 “时间戳”,不新增实体;同时对低相似度的同义词(如 “RAG” 与 “检索增强生成”,相似度 0.6),由 AI 组手动审核后补充至映射表。
是否解决
是。优化后实体重复率从 35% 降至 5% 以下,知识图谱数据一致性达标,且未显著增加入库耗时(单篇 PDF 实体处理时间仍≤10 秒)。
有何收获
- 技术层面:理解了 “增量构建” 的核心是 “去重逻辑 + 动态适配”,不能仅依赖单一的名称匹配,需结合相似度算法与人工审核,平衡自动化与准确性;
- 项目管理层面:提前预判潜在问题的重要性 —— 若第 4 周未发现实体重复问题,第 5 周 AI 问答时会出现严重的信息混乱,后期修复需删除大量重复数据,验证了 “每周测试复盘” 的必要性(每周五团队同步测试结果,及时发现卡点)。
3.5 成员周贡献
| 第 N 周 | 学号 | 姓名 | 完成的核心任务 | 耗时 (小时) | 贡献分 |
|---|---|---|---|---|---|
| 1 | 022304111 | 刘华胜 | 1. 牵头编写《需求细化文档》,明确 PDF 格式支持范围与知识图谱存储方案;2. 制定前后端接口规范(如 PDF 导入请求参数、AI 问答返回格式) | 8 | 1.5 |
| 1 | 102301426 | 潘炜豪 | 1. 学习 PyQt5 信号 - 槽机制,完成阅读页面原型草图设计;2. 调研 Microsoft Fluent 风格控件库,整理前端适配要点;3. 协助统一 Windows/Linux 双端开发环境(安装 PyQt5 依赖) | 6 | 1 |
| 1 | 102301427 | 刘伟兴 | 1. 分析 Socket 框架源码,梳理多线程与热加载核心逻辑;2. 设计 SQLite 基础表结构(文件信息表、历史记录表);3. 验证后端服务在 Linux 系统下的启动稳定性 | 6 | 1 |
| 1 | 102301121 | 吴君凯 | 1. 学习 RAG 基础流程(文档解析→向量存储→检索匹配),对比 Chroma/FAISS 向量库差异;2. 调研 iText2KG 项目 ATOM pipeline 原理,整理技术集成难点;3. 编写 AI 模块技术预研报告 | 7 | 1.2 |
| 1 | 102301420 | 何君豪 | 1. 学习 LangChain 翻译接口调用方法,完成基础翻译功能 Demo;2. 收集学术 PDF 样本(5 篇计算机领域文献),用于后续测试;3. 协助陈明宇整理 RAG 技术文档 | 5 | 0.8 |
| 1 | 102301417 | 杨良烨 | 1. 学习 PyPDF2 库用法,完成单篇 PDF 文本提取 Demo;2. 测试自研 Socket 框架的热加载功能,记录异常日志;3. 协助郑隆熙设计 SQLite 表结构索引 | 5 | 0.8 |
| 1 | 102301335 | 洪顺兴 | 1. 学习 Qt Designer 工具,完成左侧收藏 / 历史记录栏 UI 原型;2. 整理 Fluent 风格配色方案(主色、辅助色);3. 协助刘华胜验证 Windows 端界面渲染效果 | 5 | 0.8 |
| 2 | 102301417 | 杨良烨 | 1. 编写基础功能测试用例(导入成功率、收藏同步延迟、页面渲染稳定性);2. 组织周进度复盘会,跟踪各组任务卡点(如后端 PDF 导入接口开发);3. 更新项目计划文档,调整第 3 周任务优先级 | 9 | 1.5 |
| 2 | 102301426 | 潘炜豪 | 1. 基于 PyQt5 实现 Fluent 风格阅读页面(整合阅读区、翻译入口、对话入口);2. 开发收藏按钮交互逻辑(点击收藏 / 取消收藏,同步更新 SQLite);3. 修复 Windows 端控件对齐问题(按钮间距、文本换行) | 12 | 2 |
| 2 | 102301420 | 何君豪 | 1. 完成 PDF 批量导入接口开发(支持多文件选择,返回导入成功 / 失败列表);2. 优化历史记录查询接口(按访问时间倒序,支持分页);3. 联调前端 - 后端数据交互(收藏状态同步、历史记录加载) | 12 | 2 |
| 2 | 022304111 | 刘华胜 | 1. 学习知识图谱基础概念(实体 / 关系定义),设计 Neo4j 备选存储方案;2. 协助前端组调试翻译入口接口,定义翻译请求参数格式;3. 整理 iText2KG 集成所需依赖库(如 spaCy、networkx) | 8 | 1.2 |
| 2 | 102301121 | 吴君凯 | 1. 优化 LangChain 翻译接口,支持选中文本片段翻译(返回原文 + 译文);2. 测试不同 PDF 文本提取效果(纯文本 PDF、图片内嵌文本 PDF);3. 编写 AI 翻译模块测试用例 | 7 | 1 |
| 2 | 102301427 | 刘伟兴 | 1. 完善 SQLite 索引(文件 ID、访问时间),提升历史记录查询速度;2. 开发文件删除接口(删除本地文件 + 同步删除数据库记录);3. 测试 Linux 端 PDF 导入功能,修复路径识别异常问题 | 10 | 1.5 |
| 2 | 102301335 | 洪顺兴 | 1. 实现左侧历史记录栏滚动加载逻辑(避免一次性加载过多数据卡顿);2. 开发收藏筛选功能(按收藏时间 / 文件名搜索);3. 适配 Linux XDE 桌面界面(调整字体大小、控件间距) | 10 | 1.5 |
| 3 | 102301417 | 杨良烨 | 1. 执行翻译功能测试(选中文本翻译准确率、全文翻译耗时);2. 组织 AI 基础问答模块联调会(前端 - 后端 - AI 组协同);3. 编写第 3 周进度报告,梳理待解决问题(如图片 PDF 文本提取) | 10 | 1.5 |
| 3 | 102301335 | 洪顺兴 | 1. 开发 AI 对话面板(输入框、问答历史滚动显示、清空历史按钮);2. 实现翻译结果弹窗(支持复制译文、关闭弹窗);3. 联调 AI 问答接口,处理返回数据渲染(文本分行、关键词高亮) | 13 | 2 |
| 3 | 102301427 | 刘伟兴 | 1. 开发图片 PDF 文本提取接口(集成 pytesseract-OCR,支持中英文识别);2. 优化 Socket 框架多线程处理(避免 AI 请求阻塞 UI);3. 联调文本提取→AI 模块数据流转(传递文本片段 + 文件 ID) | 13 | 2 |
| 3 | 022304111 | 刘华胜 | 1. 搭建 Chroma 向量库,完成 PDF 文本嵌入存储(按段落拆分,嵌入维度 768);2. 开发 RAG 基础检索逻辑(设置检索阈值 0.7,返回 Top3 相关文本);3. 联调后端 - AI 数据交互,处理向量存储异常 | 15 | 2.5 |
| 3 | 102301121 | 吴君凯 | 1. 完善 AI 基础问答功能(接收用户问题→调用 RAG 检索→生成回答);2. 测试不同检索阈值效果(0.6/0.7/0.8),确定最优值;3. 编写 RAG 模块技术文档,记录参数配置方法 | 12 | 2 |
| 3 | 102301426 | 潘炜豪 | 1. 修复 OCR 文本提取乱码问题(调整编码格式为 UTF-8);2. 开发文本片段缓存接口(减少重复提取耗时);3. 测试双端 AI 请求响应时间,记录性能数据 | 11 | 1.8 |
| 3 | 102301420 | 何君豪 | 1. 优化 AI 对话面板交互(支持按 Enter 键提交问题、问答历史时间戳显示);2. 修复 Linux 端翻译弹窗位置偏移问题;3. 协助测试组执行 UI 交互测试,记录操作异常 | 11 | 1.8 |
| 4 | 102301417 | 杨良烨 | 1. 设计知识图谱功能测试方案(实体提取准确率、增量更新效果);2. 组织 iText2KG 集成复盘会,解决实体重复存储卡点;3. 更新项目风险清单,标注 AI 模块性能优化优先级 | 12 | 2 |
| 4 | 102301420 | 何君豪 | 1. 开发知识图谱简易可视化界面(使用 PyQtGraph 绘制实体关系图);2. 实现图谱节点点击功能(显示实体关联的文献片段);3. 适配双端图谱界面渲染(调整节点大小、连线样式) | 14 | 2.2 |
| 4 | 102301426 | 潘炜豪 | 1. 设计知识图谱 SQLite 表结构(实体表:ID / 名称 / 类型;关系表:ID / 实体 1ID / 实体 2ID / 关系类型);2. 开发图谱增量更新接口(判断实体是否存在,避免重复存储);3. 联调 AI 组 - iText2KG 数据交互(接收 5 元组数据→入库) | 15 | 2.5 |
| 4 | 102301121 | 吴君凯 | 1. 集成 iText2KG 核心模块,实现 PDF 文本→原子事实拆分(≤400token / 事实);2. 开发 5 元组提取逻辑(实体 1 - 关系 - 实体 2-t_start-t_end);3. 解决原子事实合并异常(处理跨段落事实关联) | 18 | 3 |
| 4 | 022304111 | 刘华胜 | 1. 开发实体相似度匹配功能(余弦相似度算法,阈值 0.8);2. 测试图谱增量更新效果(导入 2 篇同主题 PDF,验证实体去重);3. 整理 iText2KG 集成问题日志,提出优化方案 | 15 | 2.5 |
| 4 | 102301335 | 洪顺兴 | 1. 优化图谱入库性能(批量插入实体 / 关系,减少数据库 IO);2. 开发图谱数据导出接口(支持导出为 CSV,用于分析);3. 测试 Linux 端图谱入库耗时,优化 SQL 语句 | 13 | 2 |
| 4 | 102301427 | 刘伟兴 | 1. 优化图谱可视化交互(支持缩放、平移、节点筛选);2. 修复 Windows 端图谱界面卡顿问题(减少节点渲染数量);3. 协助测试组执行图谱功能测试,记录实体提取错误案例 | 13 | 2 |
| 5 | 102301417 | 杨良烨 | 1. 设计增强 AI 问答测试方案(复杂问题分解成功率、响应时间);2. 组织全模块联调会(前端 - 后端 - AI - 图谱协同);3. 编写第 5 周验收报告,确认核心指标达标情况(准确率≥80%,响应≤3 秒) | 13 | 2.2 |
| 5 | 102301121 | 吴君凯 | 1. 升级 AI 对话面板,支持显示问答关联的图谱实体节点;2. 实现问答历史导出功能(支持导出为 TXT,包含问题 + 回答 + 关联实体);3. 联调图谱可视化与 AI 问答交互(点击实体节点→自动生成相关问题) | 15 | 2.5 |
| 5 | 102301420 | 何君豪 | 1. 优化 Socket 框架异步处理逻辑(AI 请求独立线程,不阻塞 UI);2. 开发 AI 问答缓存接口(缓存高频问题答案,减少重复计算);3. 测试双端 AI 性能(同时发起 5 个问答请求,验证稳定性) | 16 | 2.8 |
| 5 | 022304111 | 刘华胜 | 1. 集成 PoG 核心逻辑,实现用户问题→子目标分解(探索深度设为 4);2. 开发 RAG+PoG 整合流程(子目标→图谱定位实体→RAG 检索→生成答案);3. 调试 PoG 参数(temperature=0.3),提升问题分解准确率 | 20 | 3.5 |
| 5 | 102301426 | 潘炜豪 | 1. 优化 AI 问答生成逻辑(结合图谱实体关系 + 文档文本,补充回答完整性);2. 执行增强 AI 问答测试(10 个复杂问题,验证准确率与响应时间);3. 编写 PoG 集成技术文档,记录参数调试经验 | 17 | 3 |
| 5 | 102301427 | 刘伟兴 | 1. 修复 AI 缓存接口数据一致性问题(答案更新时同步刷新缓存);2. 优化双端资源占用(减少 Socket 连接数,降低内存消耗);3. 协助测试组执行性能测试,记录 CPU / 内存占用数据 | 14 | 2.2 |
| 5 | 102301335 | 洪顺兴 | 1. 优化问答历史显示(关键词高亮关联的图谱实体名称);2. 修复 Linux 端 AI 对话面板滚动异常问题;3. 整理前端界面优化清单,为第 6 周细节打磨做准备 | 14 | 2.2 |
四、视频介绍
https://www.bilibili.com/video/BV1YEU5B7EPb/
更多推荐


所有评论(0)