把用户宠上天的金数据，用AI Agent攻克企业培训考试难题

“快出题”官网界面

快出题的能力，首先是出题，AI组件能够快速从已有的题库中抽取题目，生成一份试卷，并且支持AI阅卷；其次是提供练习模式，尤其适用于企业培训场景，用户也可以导出试卷，方便在线下组织考试；最后还提供出题API，如果企业有自己的考试系统，可以通过快出题的API将出好的题目导入到自己的系统里。

在快出题的迭代过程中，我们经历了“金数据考试——AI考试——快出题”三个阶段。其实快出题最初是为金数据表单中有考试场景需求的用户设计的，但金数据表单主要用于数据收集，在考试场景存在一些先天的不足，比如难以支持大型题库，也不支持练习模式。于是，我们当时开发了一个无论在操作体验，还是流畅度上都表现出色的考试编辑器。然而，我们发现几乎没有人使用。为什么呢？因为导入题库这件事太难了。

我们最早发布的内测版本中，导入题库需要用户按指定的 Excel 模版上传题库，操作繁琐且出错概率极高，基本上用户都卡在了这一步。怎么办？当然是宠粉！用户居然导入不进来，我们就帮他解决这个问题，于是我们推出了第一个AI功能—— 通过AI导入题库 。用户上传任意格式的题库文件，我们都能用AI解析其中的题目，并格式化成题库供用户使用。

但随后我们又发现了一个问题：许多用户根本没有题库，而是直接将他们的资料文档当作题库上传。为了满足用户需求，我们开发了 基于资料库生成题库 的功能，只要用户有文档资料，我们就能帮助他们生成题目。

后来一些用户告诉我们，想用我们的产品做企业培训，但并没有成型的资料。怎么办？我们依然是主打一个宠粉！于是，我们又推出了一个功能—— 基于一句话出题 。用户只需输入需求，我们就能生成一套考试题目，到了这一步，基本上用户只要进来就能用起来。但有些用户开始反馈说，哎，你们生成的结果好像不太对。

问题出在哪里呢？我们都知道大模型有一个“幻觉”问题。当资料不足时，大模型就会编造一些虚假事实。当时有一位用户反馈，在我们的一句话出题功能中出了关于网络热梗“成都迪士尼”的题目。出题时，AI误以为成都真的要建迪士尼，于是生成了许多关于成都迪士尼门票、项目相关的题目，这显然不是用户想要的。

后来我们通过联网搜索的方式，确保了生成的题目准确无误。至此，我们的产品基本完成，去年3月25日上线时，我们将产品正式命名为金数据AI考试，并基于AI出题开发了一系列功能。

在推广过程中，我们发现，用户在尝试一句话生成题目时，往往会想到生成数学题或语文题，而提示词工程在K12学科方面的出题表现并不理想。后来，我们尝试了COT，即通过构建一个复杂且包含大量示例的提示词，一步步引导AI完成复杂任务。简单来说，就是教会AI如何“工作”。与此同时，我们开始研究老师是如何出题的。通过研究大量文献，形成专门的提示词，在大模型上进行反复尝试，最终找到了最优解。不仅适用于K12出题，还可以用于各种职业资格考试，如司法考试、会计考试、建造师/建筑师考试等，从而真正实现了“万物皆可考”。

接下来，我们面临了一个新的挑战：一些大型企业用户已经拥有自己的考试系统，但非常认可金数据的出题能力，问我们能否通过API将金数据的出题能力集成到他们自己的系统里。于是，我们开始着手构建对外开放的API。

当时，为了快速开发，我们所有的提示词工程都是在我们的Ruby项目里完成的。选择Ruby的原因主要有两个：一方面，金数据本身就主张使用Ruby；另一方面，金数据在Ruby社区中处于顶尖水平，我们对驾驭这个技术栈非常有信心。

然而，随着技术功能的不断迭代，我们逐渐发现Ruby生态的不足。由于缺乏丰富的生态支持，在Ruby上很难进行快速调试和问题追踪，代码编写也缺乏一定的规范性。如果要开发一个对外的API，并满足用户的私有化定制需求，难度极大。因此，我们痛定思痛，决定将所有的AI应用模型从Ruby中迁移出来，切换到LangChain，拥抱Lang圈生态，简化后续的维护和开发工作。

我们也对比了其他解决方案，例如Defy、LlamIndex、Mastra等，但它们都存在各自的问题。最终，我们选择了LangChain作为技术方案。完成迁移后，我们发现开发API变得非常快速且易于实现。

在开发对外API的过程中，我们还进一步认识到，许多用户已经有了自己的考试系统，更需要我们帮助他们完成出题环节。于是，我们从市场需求出发，对产品方向进行了调整，从“金数据AI考试”进化为“快出题”，适当降低了考试功能的比重，专注于提升出题能力。

技术侧的创新尝试为我们带来了显著的改进：

首先，我们引入了LangGraph，它是LangChain生态中专门用于Agent编排和Workflow组织的工具。我们可以借此构建更为复杂的AI应用。

以一句话出题功能为例，此前它是通过单一的Prompt加上一些输入、输出检查实现的单一Agent。改进后，我们将出题过程拆分成多个部分，每个部分由一个 Agent 单独完成，所以出题就变成了多个 Agents 的协同工作。Analyzer 先分析用户意图，Retriever 检索相关资料，在取得意图和资料后交由 Generator 出题，出题完成后 Validator 会检查题目质量，如果不合格会要求 Generator 改进，最后将结果呈现给用户。经过这一系列改进，一句话出题的效果显著增强，包括题目的深度、难度、受众语气，甚至还能增加趣味性。比如，模拟林黛玉的语言风格出一套春节拜年题，在过去是无法实现的，现在的题目则变得更加灵活、有新意，进一步拓展了使用场景。

在知识库出题方面，我们也进行了优化，将之前的线性生成改为并行处理。我们增加了一个Planner，它可以将一个任务拆分成多个小任务，每个小任务分配一个 Generator 执行，生成完成后，由一个专门的 Picker Agent 从结果中挑选出优质内容，最终形成一个题库呈现给用户。这一提升首先体现在速度上，生成100道题，仅需30秒；其次是稳定性，不会因为输出过长，导致大模型降智。无论出多少题，质量都能得到保证。

其次，我们引入了一个大模型监测平台LangFuse，它带来了两个显著优势：一方面，我们可以对所有任务进行Trace，便于跟踪和调试，从而提升研发效率；另一方面，金数据旗下还有一款名为“浩客”的产品。在快出题生成一套题目后，浩客会弹出一个小窗口，询问用户对结果是否满意。这正是大模型能力测评中非常重要的一部分——用户反馈。我们可以通过浩克收集到的数据，将生成的任务和用户对任务的评价关联起来，我们便能更好地了解改进效果如何，在哪些方面还需要提升。

在AI应用领域，选择往往比努力更重要。如果我们一开始继续在Ruby上进行迭代，可能很难实现后面这些能力的提升。

回顾整个迭代的过程，我们觉得做对了三件事：坚持交互体验。确保用户在使用金数据时，不会遇到超过五秒的loading，所有地方都是实时返回结果，迅速给用户反馈，这样用户才更有动力坚持操作，直至看到最终生成的题目；坚持产品驱动。不断深挖产品使用中的痛点和不足，快速迭代和上线，持续为用户创造价值；拥抱技术革新。我们不会因为自己在Ruby社区中的地位而固守原有的技术。

与此同时，我们也收获了三个宝贵的经验：避免过度优化。在AI调优的过程中，我们曾花费大量精力进行调整，但随着大模型的升级，之前的优化往往变得不再适用。所以，当我们在大模型或AI应用中遇到棘手问题时，也许等一等是一个更好的选择；多尝试、多探索。选对方案往往比努力更重要；辨识用户的真实需求。我们最初开发考试功能，是因为用户表示他们需要题库和组织考试的能力。随着产品的迭代，最后我们发现，用户最大的需求其实是出题。

展望未来，我们今年会更多的深耕具体的考试场景，提供更有针对性的优化，以及更专业的服务。在对外开放的API上加大投入，提供更加便捷的接入方式，让更多用户接入我们的AI Agent能力。

最近，我们关注到Anthropic提出的MCP（一个框架协议），它可以将产品封装成一个工具，供其他AI产品调用。这可能是未来AI产品发展的主流趋势，我们也在积极探索提供快出题的MCP server，以便更好地融入未来的AI生态。