AI赋能教育行业的项目复盘智能题库生成系统的架构演进与踩坑记录一、问题定义与项目初衷从人工出题到AI辅助在线教育平台的核心资产之一是题库。在一个合作项目中运营团队每月需要手工编撰约3000道题目覆盖K12数学、英语和语文三个学科。每道题从命题、审核到录入系统平均耗时45分钟。一个10人的内容团队几乎全年无休。人力成本按每人月薪1.2万元计算仅出题一项年支出约144万。需求很明确能否用大模型辅助出题把人从重复劳动中解放出来初期预期并不激进——先做到辅助生成、人工审核将单题耗时压缩到15分钟以内。后续再考虑全自动流水线。但落地过程远比想象复杂。模型幻觉、难度失控、格式不一致等问题接连出现。这个项目迭代了近8个月经历了三次架构重写。以下是完整的复盘。二、核心架构三层流水线的设计原理系统经历了三个阶段的架构演进。V1直连模式废弃——直接调用GPT-4传入请生成一道关于二次函数的单选题这样的prompt返回结果写入Excel。问题格式完全不受控10道题中仅4道格式合格。难度分布呈U型——要么极简单要么极难。幻觉率约为18%常出现捏造的公式。V2模板约束模式部分可用——引入结构化模板将题目拆解为题干选项答案解析知识点标签五个字段通过JSON Schema约束输出。格式问题基本解决合格率提升到82%。但难度控制仍然不足——LLM对中等难度的理解与教学标准偏差很大。V3多模型评测闭环当前——核心改动有三点。第一将生成与评测分离一个模型负责生成另一个模型以模拟学生身份作答对比预计正确率与目标正确率来量化难度。第二引入题库相似度去重——用text-embedding-3-small将候选题目向量化与现有题库做余弦相似度检测阈值设为0.85。第三加入人工纠错反馈回路——审核员标记的问题题目其修正结果反写回prompt模板。三、关键代码实现多模型生成与校验管道以下是核心的生成-校验流水线的简化实现interface QuestionTemplate { type: single_choice | fill_blank | short_answer; grade: number; subject: string; knowledgePoints: string[]; difficulty: easy | medium | hard; targetCorrectRate: number; // 期望学生正确率 } interface GeneratedQuestion { stem: string; options?: string[]; answer: string; analysis: string; knowledgeTags: string[]; difficultyScore: number; } async function generateQuestion( template: QuestionTemplate, existingQuestions: { id: string; embedding: number[] }[] ): PromiseGeneratedQuestion { // 第一步调用生成模型 const prompt buildPrompt(template); const raw await callLLM(prompt, { model: gpt-4o, response_format: { type: json_object }, temperature: 0.7, max_tokens: 2000, }); const candidate parseResponse(raw); if (!candidate) { throw new GenerationError(模型返回格式无法解析); } // 第二步难度自动评估 const difficultyScore await evaluateDifficulty(candidate); const rateDelta Math.abs( difficultyScore - template.targetCorrectRate ); // 如果难度偏差超过15%重新生成 if (rateDelta 0.15) { return generateQuestion( { ...template, difficulty: adjustDifficulty(rateDelta) }, existingQuestions ); } // 第三步相似度去重 const candidateEmbedding await getEmbedding( candidate.stem candidate.answer ); for (const q of existingQuestions) { const similarity cosineSimilarity(candidateEmbedding, q.embedding); if (similarity 0.85) { throw new DuplicateError(与已有题目q_${q.id}相似度过高: ${similarity.toFixed(2)}); } } return candidate; } async function evaluateDifficulty(question: GeneratedQuestion): Promisenumber { // 使用独立的评测模型模拟学生作答 const evalPrompt 你是一名${question.grade}年级学生请尝试解答以下题目。 如果你不确定答案请选择不会。 题目${question.stem} ${question.options?.join(\n) || } 只回答会/不会 ; // 批量评估同一道题模拟5个不同水平的学生 const results await Promise.all( Array.from({ length: 5 }, () callLLM(evalPrompt, { model: gpt-4o-mini, temperature: 0.3, })) ); const correctCount results.filter(r r 会).length; return correctCount / 5; // 返回实际正确率 }这套管道实际运行中单题生成耗时约8-12秒其中难度评估占6-8秒5次并行调用。实际正确率与目标正确率的平均偏差从最初的±22%收敛到±9%。四、生产踩坑与架构权衡坑1模型幻觉在数学公式中尤为严重。GPT-4在生成二次函数顶点坐标类题目时有概率把顶点公式写错。我们的应对策略是对所有包含LaTeX公式的题目先用sympy做符号计算校验。一个题目生成的被校验次数平均为2.3次。坑2难度评估的作弊倾向。当模拟学生模型与生成模型同源都是GPT-4系列时评测结果偏高——模型更容易理解同源输出的模式。切换评测模型为Claude 3 Haiku后难度曲线回归正常。坑3题库相似度阈值的选择是经验性的。设太高不起作用设太低会误杀。经过对500对人工标注的是否相似数据进行ROC分析0.85是当前最优平衡点但会随使用场景变化。架构权衡V3架构的代价是引入了三倍于V2的API调用量和延迟。如果实时性要求高如在线出题需要预生成缓存机制。另一个权衡点是难度评估精度每提升5%API成本大约翻倍。在项目当前的ROI框架下±9%的难度偏差已可接受。五、总结这个项目的核心教训LLM直接用于生产内容的关键瓶颈从来不是能不能生成而是生成的能不能用。格式约束靠Schema能解决90%的问题但难度和语义质量必须通过评测闭环来收敛。落地要点生成与评测必须分离使用不同模型进行交叉验证题库去重需要语义级别的相似度计算关键词匹配不够人工审核的反馈数据是系统持续改进的燃料必须设计好采集管道V3架构的单题成本约$0.03含生成评测去重需按量评估ROI项目当前状态日均产出600道可入库题目人工审核通过率73%单题人工处理时间从45分钟下降到12分钟。年化节省成本约86万元。下一步优化方向将审核反馈自动化用Few-shot学习逐步提升一次通过率。