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[] }[] ): Promise<GeneratedQuestion> { // 第一步：调用生成模型 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): Promise<number> { // 使用独立的评测模型模拟学生作答 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学习逐步提升一次通过率。