山东大学软件学院项目实训-创新实训-计科智伴（二）——只能互动与练习

在前一篇博客中，我介绍了"计科智伴"知识库底座的构建思路，确立了"双库协同"的技术格局。

本篇博客进行了智能互动与练习模块的设计与实现。其核心可以概括为：以教学闭环中的"学习—练习—诊断—反馈"四个环节为牵引，构建一组以底座能力为支撑、以用户画像为驱动的对话与练习接口。

一、 模块定位：从"知识库"到"教学体验"的中间层。

知识库底座解决了"AI 能不能调到正确知识"的问题，用户画像解决了"AI 知不知道用户是谁"的问题，但它们之间需要一个工作流层，把"用户当前的状态"翻译成"对底座的具体调用"，再把"底座的返回结果"翻译成"对用户有意义的输出"。

智能互动与练习模块就是这一层。按需求文档，它对外暴露 5 个接口：

二、 核心设计：三条贯穿模块的设计原则

我确立了三条设计原则以此决定了后续每个接口的实现细节

原则一：所有 AI 调用必须经过 RAG 与画像的双重约束。

原则二：对话与练习共享同一套底座接口

原则三：所有写操作必须回流到画像

三、 关键技术环节详解

1. 智能问答/api/ai/chat：RAG 驱动的多轮对话

文本问答接口在工程上的核心，不在于调用 LLM，而在于如何把"用户当前问题 + 历史上下文 + 检索到的知识片段 + 用户画像"组装成一个高质量的 Prompt

整个调用链拆为三个 Service：RetrievalService负责检索、PromptBuilder负责组装、ChatService负责调用 LLM 与流式返回。流程如下：

用户提问 ↓ RetrievalService.hybridSearch(query, subject) → pgvector 返回 Top-K 切片 ↓ PromptBuilder.build(query, history, chunks, profile) ↓ ChatService.streamChat(prompt) → SSE 流式返回 ↓ 异步：写入对话历史（Redis List）

有几个值得展开的设计点：

学科过滤的必要性。hybrid_search接口本身支持 subject 参数。我会从用户画像中读出当前学习的科目，将检索范围限定在该科目内。

Top-K 自适应。初版固定 top_k=5，后来改成根据 query 长度动态调整：短问题（<20 字）取 3，长问题（>50 字）取 8。原因是短问题语义聚焦，多了反而稀释；长问题往往涉及多个概念，需要更多上下文。

多轮对话的窗口管理。历史对话存于 Redis 的 List，key 为chat:history:{userId}:{sessionId}，每轮 push 一对消息。Prompt 中只取最近 10 轮（20 条）。窗口取多少是个权衡——窗口越长上下文越完整，但 token 成本与"被早期对话带偏"的风险也越高。10 轮是反复测试后的经验值。会话 idle 超过 30 分钟则 Key 过期，相当于自然进入新话题。

SSE 而非一次性返回。学生体验对延迟极度敏感，等待 3 秒空白屏幕和 0.3 秒后开始流式打字，主观感受差异巨大。后端使用 Spring 的SseEmitter，LLM 端走 OpenAI 兼容协议，每接收一个 chunk 即emitter.send()。

2. 多模态问答/api/ai/chat/multimodal：从图片到结构化 JSON

多模态接口承接的典型场景是：学生拍下一道题、传一张笔记截图、上传一张手绘的递归调用图，希望 AI 能"看图答题"。这一接口的工程难点不在于调用视觉语言模型，而在于预处理与输出结构化。

预处理流水线。学生上传的图片质量参差不齐，直接送入 VLM 既贵又不准。我在 MinIO 上传前加了四步处理：格式校验（jpg/png/webp）、按 EXIF 自动旋转、长边压缩到 1280px、文件名规范化。其中长边压缩这一步直接将单次调用成本降低约 60%——VLM 按图像 token 计费，原图 1024×1024 与压缩后的差异在准确率上几乎不可感知，但成本差近 3 倍。

结构化输出而非自然语言。这是一个易被忽略但收益很大的设计决策。我在 Prompt 中明确要求模型按以下 JSON 结构返回：

json

{ "recognized_text": "题目原文（公式用 LaTeX）", "subject": "学科分类", "knowledge_points": ["涉及的知识点"], "answer": "解答过程", "confidence": 0.0~1.0 }

结构化输出带来三个直接好处：前端可分块渲染（题目用 KaTeX 渲染公式、知识点变成可点击标签跳转知识库）；knowledge_points字段可用于回写到wrong_question或更新画像；confidence字段允许前端在低置信度时给出"识别可能不准，请检查"的提示。

实测下来，印刷体题目 confidence 普遍在 0.85 以上，手写体在 0.5~0.7 区间。这个区间的提示机制不可省略——否则模型会"幻觉式"地给出看似自信的错答。

3. 自适应出题/api/exercises/next：让画像驱动选题

练习题接口的核心问题不是"怎么从题库取一道题"，而是"取哪一道"。有了画像后，可以做到真正的自适应

题库表exercise的核心字段：

knowledge_points与 Neo4j 中 Topic 节点的name严格对齐这一点尤为关键，它是后续诊断阶段能跨库联动的前提。

选题逻辑分三步：

第一步，加权采样选定知识点。从画像读取knowledge_mastery，以(1 - mastery)作为该知识点的采样权重。掌握度越低，被选中的概率越高。这比简单遍历薄弱点更平滑，也避免了用户在同一个薄弱点上反复刷题。

第二步，难度自适应。根据该知识点的当前掌握度映射难度区间——掌握度 < 0.4 出 difficulty 1~2，0.4~0.7 出 2~3，> 0.7 出 3~4。让学生始终处在"略有挑战但不至于挫败"的区间。

第三步，去重。Redis 维护done:exercise:{userId}集合，TTL 7 天。每次选题前 SISMEMBER 判断，命中则重选，最多重试 5 次。这保证短期不重复但又不会因为题库小而陷入死循环。

4. 答案批改/api/exercises/submit：AI 判分 + 画像回流

提交接口是整个模块业务最重的一个，因为它要同时完成批改、画像回写、错题归档、反馈生成四件事。

批改分流。不同题型批改策略不同。客观题（单选、多选、判断）走字符串比较，零成本零延迟；填空题先精确匹配，失败后才走 AI 判断同义表达（如"栈"≡"堆栈"）；简答题与编程题完全交给 LLM 判分。

LLM 判分的 Prompt 设计经历了一次重要调整。初版 Prompt 措辞较温和（"请评价学生答案"），结果模型几乎逢答必对，分数失真严重。后来改为：

请严格按照标准答案的核心要点判断。每遗漏一个关键要点扣相应分数，错误表述按程度扣分。返回 JSON：{ correct, score, feedback }

并将 temperature 设为 0.1。两项调整后，AI 判分与人工抽检的一致率从约 60% 提升到 88% 左右。这印证了一个我反复体会的事实——LLM 的输出质量，几乎完全由 Prompt 的明确程度决定。

画像回流。这是体现"原则三"的关键步骤。答错时：调用底座的update_topic_mastery接口，对涉及的每个知识点扣 0.05；将题目写入wrong_question表；清除userProfile缓存。答对时：掌握度 +0.05，掌握度首次突破 0.8 时给前端推一条"恭喜掌握 XX"的反馈消息。

反馈增强。传统在线练习答错后只展示标准解析，但我们的优势是知识库底座完整。我在反馈环节追加了一步——以错题涉及的知识点为 query，调用hybrid_search检索 Top-3 切片，作为"延伸阅读"附在反馈下方。学生答错的瞬间能直接看到对应章节的精华讲解，这是单纯有题库或单纯有知识库都做不到的——它依赖前一阶段构建的双库协同底座。

5. 专项练习/api/exercises/targeted：用图谱编排路径

专项练习的产品形态是"针对薄弱点连续刷一组题"，看似简单，但怎么编排这组题决定了产品价值。

最直观的方案是把所有薄弱点列出来，每个出两道题。但这种方案在实际推演中很快暴露问题：若学生"动态规划"薄弱、根源是"递归"未掌握，直接刷 DP 题只会反复挫败。真正的薄弱不是末端节点，而是它依赖的某个前置节点未达标。

这是 Neo4j 图谱真正派上用场的地方。编排逻辑如下：

1. get_weak_topics(subject, threshold=0.5) → 拿到所有薄弱点 W 2. 对每个 t ∈ W: 沿 PREREQUISITE_OF 反向遍历前置节点 P 若 p ∈ P 且 mastery(p) < 0.5 → p 才是真正的"病根" 3. 按"前置 → 末端"的顺序组织题目序列 4. 每个节点配 1~3 道题，难度由低到高

举一个真实跑出来的例子：用户在"动态规划"上掌握度 0.3，前置链中"递归"为 0.2、"分治"为 0.8。生成的序列为：

递归（基础 ×2） → 递归（进阶 ×1） → 动态规划（入门 ×2） → 动态规划（应用 ×2）

这种"由因及果"的路径编排，本质上是把图谱的关系推理能力转化为产品体验。若没有PREREQUISITE_OF关系，这一逻辑只能退化为简单的题目堆叠，所谓"专项"也就名不副实。前一阶段在图谱中手工标注那 40+ 对前置关系的工作，在此处获得了直接回报。

四、 部署与联调中的三个坑

模块开发完后联调阶段遇到了几个有代表性的问题，记录如下。

坑一：SSE 在 Nginx 反向代理后被缓冲。本地开发时流式输出表现正常，部署到测试服务器后变为"等待数秒后一次性返回完整文本"。排查发现 Nginx 默认开启了proxy_buffering。在对应 location 块中显式关闭即可：

nginx

proxy_buffering off; proxy_cache off; proxy_set_header Connection ""; proxy_http_version 1.1;

坑二：多模态接口的成本失控。接通后第一天进行密集测试，未做图像压缩，单日消耗约为预算的 50%。事后复盘，VLM 计费按图像 token，原图与长边 1280 压缩后的图在视觉问答任务上准确率几乎一致，但成本差近 3 倍。任何调用第三方 API 的接口，必须在上线前完成成本估算并加入预处理优化，这一点对学生项目尤其重要。

坑三：知识点别名导致跨库联查失败。题库录入时的标签是"快速排序"，但图谱中部分节点早期写为"快排"，跨库联查时匹配不上。最终在KnowledgePointNormalizer中维护一份别名映射表（"快排"、"快速排序"、"QuickSort" 全部归一到Topic("快速排序")）。这是一个底层数据治理问题，根因是模块间字段约定不严，提醒我任何跨库的字段对齐都应当作为契约写进文档，而非依赖默契。

五、 阶段成果数据

本模块开发完成后，对照需求文档自检：

六、 总结与下一步

本周已经把"学—练—诊—反馈"的最小闭环跑通：学生可以发起对话、上传图片、自适应刷题、获得 AI 批改与延伸讲解、进入专项练习。但这只是闭环的"骨架版本"，真正的智能体验还需要诊断 Agent 的细粒度错因分析、规划 Agent 的学习路径生成共同支撑。

下一阶段我会继续推进两件事：一是将诊断 Agent 接入提交接口，二是基于本模块沉淀的练习数据，与规划 Agent 协同。