在前一篇博客中我介绍了计科智伴知识库底座的构建思路确立了双库协同的技术格局。本篇博客进行了智能互动与练习模块的设计与实现。其核心可以概括为以教学闭环中的学习—练习—诊断—反馈四个环节为牵引构建一组以底座能力为支撑、以用户画像为驱动的对话与练习接口。一、 模块定位从知识库到教学体验的中间层。知识库底座解决了AI 能不能调到正确知识的问题用户画像解决了AI 知不知道用户是谁的问题但它们之间需要一个工作流层把用户当前的状态翻译成对底座的具体调用再把底座的返回结果翻译成对用户有意义的输出。智能互动与练习模块就是这一层。按需求文档它对外暴露 5 个接口接口方法教学闭环中的环节/api/ai/chatPOST学习讲解、答疑/api/ai/chat/multimodalPOST学习识图答疑/api/exercises/nextGET练习自适应出题/api/exercises/submitPOST诊断 反馈批改、错因/api/exercises/targetedGET练习薄弱点专项二、 核心设计三条贯穿模块的设计原则我确立了三条设计原则以此决定了后续每个接口的实现细节原则一所有 AI 调用必须经过 RAG 与画像的双重约束。原则二对话与练习共享同一套底座接口原则三所有写操作必须回流到画像三、 关键技术环节详解1. 智能问答/api/ai/chatRAG 驱动的多轮对话文本问答接口在工程上的核心不在于调用 LLM而在于如何把用户当前问题 历史上下文 检索到的知识片段 用户画像组装成一个高质量的 Prompt整个调用链拆为三个 ServiceRetrievalService负责检索、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_k5后来改成根据 query 长度动态调整短问题20 字取 3长问题50 字取 8。原因是短问题语义聚焦多了反而稀释长问题往往涉及多个概念需要更多上下文。多轮对话的窗口管理。历史对话存于 Redis 的 Listkey 为chat:history:{userId}:{sessionId}每轮 push 一对消息。Prompt 中只取最近 10 轮20 条。窗口取多少是个权衡——窗口越长上下文越完整但 token 成本与被早期对话带偏的风险也越高。10 轮是反复测试后的经验值。会话 idle 超过 30 分钟则 Key 过期相当于自然进入新话题。SSE 而非一次性返回。学生体验对延迟极度敏感等待 3 秒空白屏幕和 0.3 秒后开始流式打字主观感受差异巨大。后端使用 Spring 的SseEmitterLLM 端走 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的核心字段字段类型说明subjectvarchar学科knowledge_pointsjsonb涉及知识点数组与 Neo4j Topic.name 严格对齐difficultyint1~5 难度等级typevarchar单选/多选/填空/简答/编程contenttext题干支持 Markdown LaTeXanswertext标准答案explanationtext标准解析knowledge_points与 Neo4j 中 Topic 节点的name严格对齐这一点尤为关键它是后续诊断阶段能跨库联动的前提。选题逻辑分三步第一步加权采样选定知识点。从画像读取knowledge_mastery以(1 - mastery)作为该知识点的采样权重。掌握度越低被选中的概率越高。这比简单遍历薄弱点更平滑也避免了用户在同一个薄弱点上反复刷题。第二步难度自适应。根据该知识点的当前掌握度映射难度区间——掌握度 0.4 出 difficulty 1~20.4~0.7 出 2~3 0.7 出 3~4。让学生始终处在略有挑战但不至于挫败的区间。第三步去重。Redis 维护done:exercise:{userId}集合TTL 7 天。每次选题前 SISMEMBER 判断命中则重选最多重试 5 次。这保证短期不重复但又不会因为题库小而陷入死循环。4. 答案批改/api/exercises/submitAI 判分 画像回流提交接口是整个模块业务最重的一个因为它要同时完成批改、画像回写、错题归档、反馈生成四件事。批改分流。不同题型批改策略不同。客观题单选、多选、判断走字符串比较零成本零延迟填空题先精确匹配失败后才走 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, threshold0.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 块中显式关闭即可nginxproxy_buffering off; proxy_cache off; proxy_set_header Connection ; proxy_http_version 1.1;坑二多模态接口的成本失控。接通后第一天进行密集测试未做图像压缩单日消耗约为预算的 50%。事后复盘VLM 计费按图像 token原图与长边 1280 压缩后的图在视觉问答任务上准确率几乎一致但成本差近 3 倍。任何调用第三方 API 的接口必须在上线前完成成本估算并加入预处理优化这一点对学生项目尤其重要。坑三知识点别名导致跨库联查失败。题库录入时的标签是快速排序但图谱中部分节点早期写为快排跨库联查时匹配不上。最终在KnowledgePointNormalizer中维护一份别名映射表快排、快速排序、QuickSort 全部归一到Topic(快速排序)。这是一个底层数据治理问题根因是模块间字段约定不严提醒我任何跨库的字段对齐都应当作为契约写进文档而非依赖默契。五、 阶段成果数据本模块开发完成后对照需求文档自检指标需求实际完成接口数55文本问答平均首字延迟 1s约 0.6s文本问答 RAG 召回相关切片 ≥ 3 条Top-K 自适应 3~8 条多模态识别置信度印刷体≥ 0.7平均 0.87AI 批改与人工抽检一致率≥ 80%88%自适应选题画像驱动是是加权采样 难度自适应专项练习路径编排基于薄弱点基于薄弱点 前置图谱六、 总结与下一步本周已经把学—练—诊—反馈的最小闭环跑通学生可以发起对话、上传图片、自适应刷题、获得 AI 批改与延伸讲解、进入专项练习。但这只是闭环的骨架版本真正的智能体验还需要诊断 Agent 的细粒度错因分析、规划 Agent 的学习路径生成共同支撑。下一阶段我会继续推进两件事一是将诊断 Agent 接入提交接口二是基于本模块沉淀的练习数据与规划 Agent 协同。