一个面向毕设的智能出题系统最核心的价值不是“调一个接口让它吐几道题”而是把知识图谱、大模型生成和错题分析串成一条完整链路。这个项目正好适合做毕业设计它既有前端展示效果又有后端接口还能讲出“知识结构化 大模型生成 个性化推荐”的完整故事。如果你正在做类似题目或者想在答辩时把“AI大模型出题”讲得不像玩具 Demo这篇文章会把整个系统的拆解过程、落地步骤、常见坑点和答辩思路一次讲清楚。我先说结论用 Qwen-Plus 生成题目并不难难的是让生成的题目围绕指定知识点、难度可控、格式稳定并且能从错题数据里反向修正出题策略。这套系统最有价值的模块不是“调用大模型”而是“知识图谱怎么组织知识点”和“错题结果怎么反馈回出题参数”。下面按实际开发顺序拆开讲。1. 先拆清楚这个毕设系统到底要做什么1.1 从“自动出题”到“智能出题”的差异很多开题报告写的都是“自动出题系统”但单纯从题库里随机抽题根本算不上智能。你这个项目的标题里有一个关键词是“接通真实AI大模型”说明你选择的路线是让模型根据知识点现场生成题目而不是从已有题库里查询。这两者的差别很关键题库抽题依赖人工录入题目数量有限容易重复没办法覆盖冷门知识点。大模型生成可以根据知识点、题型、难度、考察目标动态生成理论上可以覆盖任意组合。知识图谱辅助让模型知道“这个知识点和哪些前置知识有关”“这个知识点通常考什么”生成题目时不至于乱出。错题分析通过学生的答题结果定位薄弱知识点再让模型针对这些薄弱点生成更多变式题。这套链路做完整之后你的答辩可以讲三件事知识怎么组织、题目怎么生成、结果怎么反馈。三件事都落到了具体模块上比只做一个“调用大模型接口的工具”要扎实得多。1.2 系统的三个核心模块与数据流从功能上拆系统至少包含三个模块知识图谱模块负责维护知识点、知识点之间的关系、知识点对应的题目示例和考频信息。大模型出题模块负责接收出题请求结合知识图谱中的上下文调用 Qwen-Plus 生成题目。错题分析模块负责记录学生答题结果分析错误题目关联的知识点更新知识图谱中的薄弱标记并影响后续出题的难度和知识点范围。数据流大概是这样的管理员录入科目、章节、知识点构建知识图谱。学生在系统里选择知识点范围触发大模型生成题目。学生提交答案系统判断对错。错题模块记录错误知识点计算薄弱指数。下一次出题时系统优先选择薄弱知识点并降低或调整难度。整个过程不是“生成一次就结束”而是形成闭环。这也是答辩时很加分的点。1.3 为什么用 Qwen-Plus 而不是本地小模型选型时很多人会纠结本地部署一个开源模型不也能生成题目吗为什么非要用 Qwen-Plus我的判断是毕设场景里稳定性和方便程度比“完全离线”更重要。Qwen-Plus 属于较大的商用模型在中文题目生成、上下文理解、文本结构上明显比本地 7B 或 13B 模型稳定。你可以把知识图谱里的知识点描述、例题、错题记录拼到提示词里模型能按你的要求返回结构化 JSON。如果换成本地小模型提示词稍长一点就开始丢格式JSON 经常解析失败你整个晚上都会在处理非法输出而不是在做功能。不过有一点要提醒Qwen-Plus 是通过 API 调用的属于在线大模型。如果你的毕设要求必须本地部署那思路要变。但大多数高校对毕设作品没有“必须离线”的硬性要求在线 API 反而能节约本地算力也让系统更接近真实产品形态。答辩时你可以说“本系统采用了大模型 API 接入的方式能够在不依赖高性能显卡的情况下获得稳定生成效果”这句话在资源有限的实验室环境里是加分项。2. 知识图谱模块把知识点变成可检索的网2.1 知识图谱在出题中的作用没有知识图谱你也能让大模型出题比如写一句“请生成 5 道关于导数的选择题”。但这样生成的题有两个问题知识点覆盖不可控难度不可控而且题目之间没有逻辑关系。知识图谱解决的是“围绕什么出题、题目之间怎么关联”的问题。举个例子在高等数学里“导数”不是一个孤立节点。它前面连着“极限”后面连着“函数的单调性”“极值”“曲线的凹凸性”。如果学生“导数”题目做错了错误原因可能是“不会求导”也可能是“不理解极限”甚至可能是“不会分类讨论”。知识图谱可以把这些关系显式表达出来。出题时你从图谱里取出当前知识点、前置知识点、相关知识点把这些信息写进提示词。模型生成时就有了约束条件不会凭空乱出。2.2 用 Neo4j 建模实体、关系、属性推荐用 Neo4j 作为知识图谱的存储和可视化工具。它是图数据库里最常用的方案有浏览器界面答辩时可以现场展示图谱关系效果非常直观。一个最简的知识图谱模型可以这样设计节点类型知识点、题目、错题记录、学生。关系类型前置关系、关联关系、考察关系、错误关系、掌握关系。属性设计知识点节点包含 id、名称、科目、章节、难度系数、考频、错误率题目节点包含 id、题干、答案、解析、题型、难度、知识点 id。以“导数”为例可以这样建模CREATE (d:KnowledgePoint {id: kp_001, name: 导数, subject: 高等数学, chapter: 第二章, difficulty: 0.6}) CREATE (l:KnowledgePoint {id: kp_002, name: 极限, subject: 高等数学, chapter: 第一章, difficulty: 0.5}) CREATE (m:KnowledgePoint {id: kp_003, name: 函数的单调性, subject: 高等数学, chapter: 第三章, difficulty: 0.7}) CREATE (d)-[:PREREQUISITE]-(l) CREATE (m)-[:DEPENDS_ON]-(d)这里只做示例实际项目里你可以用 Python 的neo4j驱动批量导入。2.3 图谱数据来源与导入思路知识图谱的数据来源是毕设里最容易卡壳的环节。很多同学会问难道要我一条条录入所有知识点吗如果你做的课程范围小比如只做“高中数学函数”这一章那么人工录入 30 到 50 个知识点是可行的。如果你要覆盖整门课程建议按以下顺序处理从课程大纲或教材目录提取章节和知识点名称。用规则脚本把“章节 - 知识点”拆成父子关系。从历年试卷中抽取试题人工或半自动标注每道题对应的知识点。把知识点的前置关系写成一个 CSV 文件再批量导入 Neo4j。CSV 导入示例字段knowledge_id, name, subject, chapter, difficulty, prerequisite_knowledge_ids kp_001, 导数, 高等数学, 第二章, 0.6, kp_002 kp_003, 函数的单调性, 高等数学, 第三章, 0.7, kp_001导入时用LOAD CSV或 Python 脚本都行。我的建议是先用小文件验证不要一上来就导入几百行否则出了问题很难定位是哪一行格式不对。2.4 出题时如何从图谱抽取知识点系统收到出题请求后第一步不是调用大模型而是去 Neo4j 查询要考察的知识点上下文。比如请求是“考察导数难度中等出 3 道选择题”那么查询逻辑可以这样MATCH (kp:KnowledgePoint {id: kp_001}) OPTIONAL MATCH (kp)-[:DEPENDS_ON]-(related) OPTIONAL MATCH (kp)-[:PREREQUISITE]-(pre) RETURN kp, collect(DISTINCT related), collect(DISTINCT pre)拿到当前知识点、关联知识点、前置知识点之后把它们整理成一段文本描述拼到提示词里。这样大模型不再只是看到“导数”两个字而是看到“考察导数前置知识点包括极限关联知识点包括函数的单调性难度系数 0.6”等信息生成结果会更可控。这里有个实战经验首次做知识图谱导入时最容易出问题的是“关系重复”和“同义节点”。比如“导数”和“导函数”可能被当成两个节点导致图谱分裂。我一般会在导入前先做一层名称归一化比如去除空格、统一简称、把“导函数”映射成“导数”。3. 接通 Qwen-Plus 大模型从提示词到题目生成3.1 环境准备与依赖安装在线调用 Qwen-Plus 不需要太高配置普通开发电脑就能跑。你需要准备的是Python 3.9 以上环境建议用虚拟环境避免依赖冲突。一个可用的 DashScope API Key去阿里云百炼控制台申请。安装dashscope或使用 OpenAI 兼容接口的 SDK。Qwen-Plus 支持多种调用方式具体以官方文档为准。安装依赖pip install dashscope如果你习惯用openai库也可以配置兼容端点。这一步要看官方文档不同阶段可能接口地址有变化不要凭感觉写死。3.2 配置 API 客户端与基础调用用 DashScope 的 Python SDK 调用 Qwen-Plus最简代码如下import dashscope from dashscope import Generation dashscope.api_key 你的API_KEY response Generation.call( modelqwen-plus, prompt请生成一道高中数学选择题考察知识点函数的单调性。, ) print(response.output[text])这段代码主要用于验证连通性。跑通之后你要做两件事把prompt换成结构化的出题提示词把响应从纯文本改成可解析的 JSON。3.3 设计一套有效的出题提示词提示词是这个项目的核心也是答辩时最值得展开讲的部分。如果只是写“生成一道题”模型输出的格式、难度、考查点都可能不满足要求。我建议把提示词设计成四个部分角色设定让模型扮演资深学科教师。出题要求说明题型、难度、数量、是否附带解析。知识上下文把知识图谱查到的相关知识点、前置知识点、例题要求拼接进去。输出格式明确要求返回 JSON并给出字段结构。示例提示词模板伪代码你是一位资深高中数学教师擅长根据知识点编写题目。 请根据以下知识点生成选择题 - 主知识点导数 - 前置知识点极限 - 关联知识点函数的单调性 - 难度系数0.6 - 题目数量3 要求 1. 每道题只考察指定知识点不要超纲。 2. 干扰项要有迷惑性错误选项应包含常见错误思路。 3. 给出正确答案和解析。 4. 输出 JSON 数组每个元素包含字段id, type, question, options, answer, analysis, knowledge_point。 只输出 JSON不要输出额外文本。注意最后一句“只输出 JSON不要输出额外文本”。不加这句模型经常会带着“好的这是您需要的题目”这样的废话解析时很头疼。3.4 结构化返回让模型输出 JSON大模型生成题目后不能直接把文本展示给前端因为前端要渲染选项、答案、解析。所以后端要把响应解析成结构化数据。下面是解析响应的通用处理方式import json def parse_generated_questions(response_text): text response_text.strip() # 去掉可能出现的 Markdown 代码块标记 if text.startswith(): lines text.split(\n) lines [line for line in lines if not line.startswith()] text \n.join(lines) try: data json.loads(text) return data except json.JSONDecodeError: # 如果直接解析失败尝试截取中括号部分 start text.find([) end text.rfind(]) 1 if start ! -1 and end start: data json.loads(text[start:end]) return data raise ValueError(大模型返回内容无法解析为 JSON)这段代码解决的是常见问题模型偶尔会在 JSON 外面包一层 Markdown 代码块或者在开头多一行说明。解析失败时不要直接判断“模型出错了”先打印一下原始返回内容。3.5 单条出题先跑通再做批量第一次调通后先做“单知识点、单条题目”的测试。确认如下三个结果都正常再扩大规模返回内容能被解析成 JSON。题干、选项、答案、解析字段完整。题目内容与指定知识点相关。我遇到过的情况是题目生成成功了但解析出来的答案是“无法确定”这就是典型的大模型幻觉。这种题不能直接进前端展示后面要加一道校验逻辑。单条跑通后再处理批量。批量出题不是简单的 for 循环因为循环很容易遇到 API 限流、超时、部分失败等问题。更稳的做法是写一个简单的任务队列import time def generate_batch(requests): results [] for req in requests: try: result generate_one(req) results.append(result) except Exception as e: results.append({error: str(e), request: req}) time.sleep(0.5) # 避免请求过快 return results这里的sleep(0.5)是经验值不是固定配置。实际生产环境要看 API 的限流策略但毕设项目里保持一个安全间隔是比较稳的。4. 错题分析模块让系统具备“自适应”能力4.1 错题数据从哪里来错题分析模块的前置条件是系统里有“答题”功能。如果你的项目还没有前端可以先通过接口模拟学生提交题目 ID 和答案后端判断对错然后记录错题。简单设计一张表student_id, question_id, knowledge_point_id, is_correct, answer, timestamp学生每次作答系统就写入一条记录。错题分析模块从这些记录里聚合数据而不是实时去大模型里查。4.2 错误知识点归因逻辑一道题做错了不能简单认为“这个知识点不会”。更合理的做法是把错误归因到题目对应的主知识点和前置知识点。比如一道“求函数单调区间”的题做错了主知识点是“函数的单调性”但真正原因可能是“导数计算不熟”。这时候系统如果只是标记“函数的单调性薄弱”下次还出单调性题但学生还是错因为前置没解决。我的处理思路是从知识图谱里查题目关联的所有前置知识点按错误次数和最近错误时间加权。权重公式可以很朴素weak_score 0.6 * recent_wrong_count 0.3 * total_wrong_count 0.1 * prerequisite_penalty然后把得分最高的前三个知识点作为“推荐补练知识点”。这个公式不是固定的你可以根据自己的数据集调整系数。重要的是向答辩评委解释清楚为什么这样加权为什么前置知识点要占权重。4.3 基于错题结果调整出题难度与范围错题分析不只要展示“哪些知识点薄弱”还要影响下一次出题。这才是闭环。假设学生的薄弱知识点是“导数计算”系统再次出题时应该优先选择薄弱知识点。初始难度降低一档。在提示词里加入“请给出详细步骤解析”。生成题目后附带一道同知识点变式题。调整逻辑可以放到后端 Service 里def build_out_questions_request(student_id, chapter): weak_points get_weak_points(student_id) questions [] for point in weak_points: difficulty adjust_difficulty(point) req generate_request( knowledge_pointpoint, difficultydifficulty, count_per_point2 ) questions.extend(generate_batch(req)) return questions这里面的adjust_difficulty可以根据学生历史正确率来调整。比如历史正确率低于 40%难度系数设 0.3高于 80%难度系数设 0.7。4.4 给答辩准备的展示用例答辩时建议准备两条测试用例让评审看到闭环效果新学生选择“高等数学第二章”系统根据默认出题策略生成 5 道题。第一次生成后学生故意错 3 道题系统标记薄弱知识点。第二次进入出题页面系统生成的知识点范围里薄弱知识点出现频次变高难度下降。在界面上展示知识图谱中相关节点的错误率变化。这个过程如果只靠口述会显得空洞。最好把图谱节点的高亮效果、错题列表的实时变化截图放进答辩 PPT。5. 从 Demo 到答辩稳定性、日志和演示话术5.1 最小可运行版本的验收标准很多同学会把系统做得很大才去调试结果临近答辩才发现核心链路没跑通。我的建议是先做一个最小闭环后台维护 3 到 5 个知识点。前端只有两个页面出题页、答题页。调用 Qwen-Plus 生成 1 道题。提交答案后系统能记录对错。错题分析页能显示薄弱知识点。这个版本如果能在一天内跑通后面的知识图谱扩展和批量生成才有意义。5.2 批量出题时的超时、重试与缓存调用在线大模型接口最大的不确定性是网络。批量出题时要考虑三个问题超时单次请求设置合理超时时间比如 30 秒。如果超过就放弃本次请求记录日志。重试网络抖动或限流导致失败时可以重试 1 到 2 次。注意重试之间要有间隔。缓存对相同的出题请求做缓存比如相同知识点、相同难度、相同题型的请求直接返回之前生成的结果避免重复调用。缓存可以用 Redis或者简单用 Python 字典加过期时间。答辩时能讲出“缓存策略”说明你考虑过真实场景的成本和性能问题。5.3 常见报错与排查顺序我整理几个最容易遇到的问题按排查优先级排列API Key 无效或权限不对检查环境变量、控制台是否开通服务。报错信息如果是鉴权失败不要改代码先看 Key 是否正确。提示词返回内容不是 JSON先打印原始响应别急着改提示词。如果返回内容是普通文本多半是提示词最后一句话没写清楚如果返回内容是空可能是请求超时或上下文过长。知识图谱查询结果为空先检查 Neo4j 里节点是否创建成功再用 Cypher 手工查询。很多情况下不是代码错了是节点 id 没有对上。批量出题时前几条成功后面全失败大概率是触发了限流。降低请求频率增加重试逻辑。错题分析结果与知识点对不上检查题目生成时是否真的把 knowledge_point_id 写进了数据库。大模型返回的字段可能和你的 id 体系不一致需要做映射。5.4 答辩现场怎么演示才不翻车答辩演示最忌讳当场开发调试。建议按以下方式准备提前录一段视频作为备用。现场网络不好或 API 超时时直接播放视频。演示时先展示知识图谱再生成题目最后展示错题闭环。这个顺序逻辑最顺。现场演示时不要生成太多题两到三道即可。生成太多会拉长等待时间评审容易走神。如果某次生成失败不要慌。直接说“这是在线模型的正常网络波动我们的代码有重试机制我刷新一下再演示”。这句话比沉默更能体现工程素养。6. 总结这套系统真正值得借鉴的地方把一个毕设项目从“会调用 API”提升到“能稳定演示并且有完整闭环”关键不是堆更多功能而是把三条链路打通知识图谱管理知识点、大模型生成题目、错题分析反馈出题策略。我个人更建议先把单条出题跑稳再处理批量生成先手工维护小块知识图谱再去想自动化导入先做简单的前端展示再慢慢加缓存和队列。很多问题看起来是功能没实现实际上是因为前置数据没有整理干净。这套系统如果只当作“自动出题工具”那确实很普通。但一旦把知识图谱和错题分析加进去它就从一个“调接口的 Demo”变成了“有数据闭环的智能学习系统”。答辩时你能讲清楚“为什么这样设计”“数据怎么流转”“失败了怎么办”比“我调用了大模型”要有说服力得多。项目源码如果你已经整理好答辩前最好把目录结构、README、启动命令都补全。评审打开项目如果发现连依赖都没写清楚会严重影响整体印象。把启动流程写成三行命令能跑起来就已经超过大部分同类作品。