本博客对应工作时间为2026.5.6-2026.5.10。目前项目已经达到中期阶段项目的骨架以及基础功能已经基本完成接下来就是将原先完成的诸多后端接口集成到前端并成为对应的功能即可。本周的工作相对较少主要包含将原始的AI解析题目功能集成到具体的题目成为一个方便实用的插件。具体的功能包括首轮知识库检索解析、多轮追问和个性化回答基于现有题目、用户追问记录和对应的知识库信息实现个性化的新题目生成并加入用户个性题库。集成相似度检索算法进入交通标志识别功能实现模型识别单标志推荐识别多候选标志结合题目解析插件实现注意到我们在先前的问答助手中已经实现了“智能解析”模式考虑到了偏题目问答的情况它的逻辑是这样的如果输入只有文本我们从纯文本知识库进行检索相关片段作为知识库输入给文本模型如果输入的包含图片多模态输入则优先将输入的图片和现有的图库进行多维相似度匹配并排序推荐如果相似度高于阈值就采用top-1结果的元数据调用文本模型进行整合回答低于阈值就调用视觉模型对输入的图像进行解析。注意到由于实际驾考题目里面一个题目最多只有一个题目因此这一套对于题目解析同样适用我们只需要对接口略作修改能够适应前端的实际需求即可。在正式进入接口修改之前我们先对数据的持久化方式做了一些变更原先的问答记录都存放在mysql中不同模式都混在一起。这里如果我们是在题目插件里面调用接口我们需要对同一道题目进行多轮问答那么不同题目、不同用户的对话内容都需要进行隔离。这样mysql的方式不利于快速的查找。深思熟虑之后我选择改用mongo存储题目插件里面产生的问答信息现有的接口不再修改而是写出来新的接口。我们将自己思考的结构给到LLM由他参考并进行修改其中首轮问答产生的默认解析所传递的结构如下{ user_id: 123, question_id: 题目唯一id, question_data: { question: 题干, type: single_choose, options: [A、..., B、...], key: B, analysis: 原有硬编码解析, label: [标签], subject: 1, img: null }, top_k: 4 }后续的多轮问答部分对应调用的json结构{ mode: 专业解析, user_id: 123, question_id: mongo_object_id_or_frontend_unique_id, question: { ...: 题目结构 }, query: 我为什么选错了 }这样就完成了对应的实现解析和多轮问答的后端逻辑对应实际使用的数据库结构如下这样我们首先按照用户名称进行编号用户内部按照题目编号进行区分对于同一个用户的同一道题分为两部分第一个是初始的默认解析可支持重新生成包含了调用的知识库等附带信息第二个是针对题目的多轮问答追问回复对话是一个序列信息每个元素表示一轮问答的结果。后端完成后我们让LLM生成对应的功能的接口文档说明清楚有哪些接口调用的方式和结构格式、可选参数等这样我们在本地的Android Studio里面使用的时候也可以让本地的LLM“看到”后端实际服务器的写法生成的md文档大致如下我们利用filezilla将服务器上面的Md文件传输到本地并且调用 本地的LLM在Android Studio中进行前端的修改让LLM根据接口文档的内容补充功能效果预览个性化题目生成插件这一部分是一块相对新颖且有意思的功能属于是本组的原创功能之前从未在其他任何APP或者网站上看到过。我们的总体思路就是从一个单个的题目出发生成与之比较在知识点上相似的题目。我们的核心输入是原始的题目信息题干、选项、答案和解析搜集获得的知识库条目信息用户的问答记录原始的题目信息限定了生成结果的核心主题不能随意生成风格上必须与既定的题目信息自洽如科目一只能生成单选和判断题但是科目四还可以另外生成多选题知识库条目信息保证了考察知识点的科学性和合理性不能天马星空而是有确定的可信知识来源的用户的问答记录展现了个性化的成分模型将优先针对用户的疑问生成切合实际薄弱点的个性化结果。三者三位一体在不同方面约束输出的结果尽可能将黑盒输出的不稳定性降到最低。我们首先将自己的需求给到LLM让它进行细化变为规范的表述得到的需求文档如下实际功能需求主要包括个性化新题目生成包含题干、选项、解析和参考答案等确认/否决添加到个性化题库获取当前所有的个性化题目删除个性化题库中的某些题目接着我们将需求文档作为提示词传入让LLM检查当前系统是否有了类似的功能如果没有就开始细化初始的默认的数据存储形式非常零散一个用户一个题目的做成单独的一个文档缺乏整合性和层次度。我们再次要求他改成按照用户聚类内部按照题号区分的优化版逻辑最终生成个性化题目的所用提示词如下sections [ 你是驾驶员考试题库命题专家。请基于原题、知识库检索结果和用户追问方向生成新的相似练习题。, 只支持纯文字题不要生成图片题、视频题或需要看图才能作答的题。, f必须生成 {count} 道题输出必须是严格 JSON 数组不要添加任何解释文字。, fsubject 必须固定为 {subject}。, 允许题型 、.join(allowed_types), 可用标签只能从下列标签选择优先 1 个最多 2 个\n 、.join(labels), 考察内容优先级知识库检索结果 用户提问方向 原题。不要简单复述原题。, 每道题必须包含 question、type、options、key、analysis、label、subject。, single_choose 和 judge 的 key 是单个大写字母multi_choose 的 key 是多个大写字母按字母顺序拼接。, 【原始题目信息】\n _question_payload_to_prompt(question_payload), ]测试无误后生成对应的接口文档供前端调用我们按照之前类似的思路前端看到这个md说明并且部署相应的个性化生成接口功能随后我们再对现有的界面进行优化增加了交互模式信息生成过程有转圈提示等最终效果展示交通标志检索添加相似度检索逻辑这一部分是对队友做的交通标志检测的优化yolo模型虽然识别很准但是一旦出错可用性就会迅速归0。这种非黑即白的模式显然无法完全适用于实际。考虑到之前在智能解析模块做过图像相似度检索的算法或许可以在原有的纯yolo模型识别的基础上再进一步添加基于图像相似度的检索逻辑这样即使yolo模型识别错误只要返回的相似的图像数量足够多仍然能够基本能找到对应的真实的结果即使top-1不一定就是真实的结果但是只要前几名是包含真实对应的结果的仍然可用这一操作可以极大提升功能的容错率理论上只要我们图库扩充的足够完备那么总是可以匹配到对应的真实结果的通过元数据就可以获取信息了。相似度检索的算法作用就是将原有的超大范围的查找不方便人工压窄变为少量的几个候选的结果支持人工的匹配。这就已经能够达到真实需求的功能了这里的主要思路就是原始的yolo检测可以拆解为两部分虽然实际上这两部分似乎是模型内部一起完成的但是结果上可以分离第一步是定位出所有标志在图中的位置第二步是对于每个识别出来的位置切分出来的子图独立判断这个标志是什么。显然我们可以将第二步进行替换替换为基于图像的相似度视觉语义的推荐系统类型的版本。我们直接将切出来的子图作为相似度检索模块的输入即可输出匹配程度最高的若干个标准图以及对应的元数据标准图包含的图像名称只要这个top-k里面能够包含真实的对应图像就是成功我们对需求的表述如下生成相应的接口说明文档、给到前端让它基于这个文档生成修改集成双向判断识别结果后的结果最终又修复了图片显示异常等问题得到下面的预览效果
2026春SDU软件创新实训第10周工作总结
本博客对应工作时间为2026.5.6-2026.5.10。目前项目已经达到中期阶段项目的骨架以及基础功能已经基本完成接下来就是将原先完成的诸多后端接口集成到前端并成为对应的功能即可。本周的工作相对较少主要包含将原始的AI解析题目功能集成到具体的题目成为一个方便实用的插件。具体的功能包括首轮知识库检索解析、多轮追问和个性化回答基于现有题目、用户追问记录和对应的知识库信息实现个性化的新题目生成并加入用户个性题库。集成相似度检索算法进入交通标志识别功能实现模型识别单标志推荐识别多候选标志结合题目解析插件实现注意到我们在先前的问答助手中已经实现了“智能解析”模式考虑到了偏题目问答的情况它的逻辑是这样的如果输入只有文本我们从纯文本知识库进行检索相关片段作为知识库输入给文本模型如果输入的包含图片多模态输入则优先将输入的图片和现有的图库进行多维相似度匹配并排序推荐如果相似度高于阈值就采用top-1结果的元数据调用文本模型进行整合回答低于阈值就调用视觉模型对输入的图像进行解析。注意到由于实际驾考题目里面一个题目最多只有一个题目因此这一套对于题目解析同样适用我们只需要对接口略作修改能够适应前端的实际需求即可。在正式进入接口修改之前我们先对数据的持久化方式做了一些变更原先的问答记录都存放在mysql中不同模式都混在一起。这里如果我们是在题目插件里面调用接口我们需要对同一道题目进行多轮问答那么不同题目、不同用户的对话内容都需要进行隔离。这样mysql的方式不利于快速的查找。深思熟虑之后我选择改用mongo存储题目插件里面产生的问答信息现有的接口不再修改而是写出来新的接口。我们将自己思考的结构给到LLM由他参考并进行修改其中首轮问答产生的默认解析所传递的结构如下{ user_id: 123, question_id: 题目唯一id, question_data: { question: 题干, type: single_choose, options: [A、..., B、...], key: B, analysis: 原有硬编码解析, label: [标签], subject: 1, img: null }, top_k: 4 }后续的多轮问答部分对应调用的json结构{ mode: 专业解析, user_id: 123, question_id: mongo_object_id_or_frontend_unique_id, question: { ...: 题目结构 }, query: 我为什么选错了 }这样就完成了对应的实现解析和多轮问答的后端逻辑对应实际使用的数据库结构如下这样我们首先按照用户名称进行编号用户内部按照题目编号进行区分对于同一个用户的同一道题分为两部分第一个是初始的默认解析可支持重新生成包含了调用的知识库等附带信息第二个是针对题目的多轮问答追问回复对话是一个序列信息每个元素表示一轮问答的结果。后端完成后我们让LLM生成对应的功能的接口文档说明清楚有哪些接口调用的方式和结构格式、可选参数等这样我们在本地的Android Studio里面使用的时候也可以让本地的LLM“看到”后端实际服务器的写法生成的md文档大致如下我们利用filezilla将服务器上面的Md文件传输到本地并且调用 本地的LLM在Android Studio中进行前端的修改让LLM根据接口文档的内容补充功能效果预览个性化题目生成插件这一部分是一块相对新颖且有意思的功能属于是本组的原创功能之前从未在其他任何APP或者网站上看到过。我们的总体思路就是从一个单个的题目出发生成与之比较在知识点上相似的题目。我们的核心输入是原始的题目信息题干、选项、答案和解析搜集获得的知识库条目信息用户的问答记录原始的题目信息限定了生成结果的核心主题不能随意生成风格上必须与既定的题目信息自洽如科目一只能生成单选和判断题但是科目四还可以另外生成多选题知识库条目信息保证了考察知识点的科学性和合理性不能天马星空而是有确定的可信知识来源的用户的问答记录展现了个性化的成分模型将优先针对用户的疑问生成切合实际薄弱点的个性化结果。三者三位一体在不同方面约束输出的结果尽可能将黑盒输出的不稳定性降到最低。我们首先将自己的需求给到LLM让它进行细化变为规范的表述得到的需求文档如下实际功能需求主要包括个性化新题目生成包含题干、选项、解析和参考答案等确认/否决添加到个性化题库获取当前所有的个性化题目删除个性化题库中的某些题目接着我们将需求文档作为提示词传入让LLM检查当前系统是否有了类似的功能如果没有就开始细化初始的默认的数据存储形式非常零散一个用户一个题目的做成单独的一个文档缺乏整合性和层次度。我们再次要求他改成按照用户聚类内部按照题号区分的优化版逻辑最终生成个性化题目的所用提示词如下sections [ 你是驾驶员考试题库命题专家。请基于原题、知识库检索结果和用户追问方向生成新的相似练习题。, 只支持纯文字题不要生成图片题、视频题或需要看图才能作答的题。, f必须生成 {count} 道题输出必须是严格 JSON 数组不要添加任何解释文字。, fsubject 必须固定为 {subject}。, 允许题型 、.join(allowed_types), 可用标签只能从下列标签选择优先 1 个最多 2 个\n 、.join(labels), 考察内容优先级知识库检索结果 用户提问方向 原题。不要简单复述原题。, 每道题必须包含 question、type、options、key、analysis、label、subject。, single_choose 和 judge 的 key 是单个大写字母multi_choose 的 key 是多个大写字母按字母顺序拼接。, 【原始题目信息】\n _question_payload_to_prompt(question_payload), ]测试无误后生成对应的接口文档供前端调用我们按照之前类似的思路前端看到这个md说明并且部署相应的个性化生成接口功能随后我们再对现有的界面进行优化增加了交互模式信息生成过程有转圈提示等最终效果展示交通标志检索添加相似度检索逻辑这一部分是对队友做的交通标志检测的优化yolo模型虽然识别很准但是一旦出错可用性就会迅速归0。这种非黑即白的模式显然无法完全适用于实际。考虑到之前在智能解析模块做过图像相似度检索的算法或许可以在原有的纯yolo模型识别的基础上再进一步添加基于图像相似度的检索逻辑这样即使yolo模型识别错误只要返回的相似的图像数量足够多仍然能够基本能找到对应的真实的结果即使top-1不一定就是真实的结果但是只要前几名是包含真实对应的结果的仍然可用这一操作可以极大提升功能的容错率理论上只要我们图库扩充的足够完备那么总是可以匹配到对应的真实结果的通过元数据就可以获取信息了。相似度检索的算法作用就是将原有的超大范围的查找不方便人工压窄变为少量的几个候选的结果支持人工的匹配。这就已经能够达到真实需求的功能了这里的主要思路就是原始的yolo检测可以拆解为两部分虽然实际上这两部分似乎是模型内部一起完成的但是结果上可以分离第一步是定位出所有标志在图中的位置第二步是对于每个识别出来的位置切分出来的子图独立判断这个标志是什么。显然我们可以将第二步进行替换替换为基于图像的相似度视觉语义的推荐系统类型的版本。我们直接将切出来的子图作为相似度检索模块的输入即可输出匹配程度最高的若干个标准图以及对应的元数据标准图包含的图像名称只要这个top-k里面能够包含真实的对应图像就是成功我们对需求的表述如下生成相应的接口说明文档、给到前端让它基于这个文档生成修改集成双向判断识别结果后的结果最终又修复了图片显示异常等问题得到下面的预览效果
