创新性评估智能体怎么开发？从项目材料到证据判断的完整流程

开发创新性评估智能体时，最容易出现的错误，就是把一份项目材料直接交给大模型，然后问它：“这个项目的创新性怎么样？”

模型通常会很快给出一个答案，甚至还会从技术创新、应用价值和市场前景几个方面分别打分。问题是，这些分数是怎么来的？模型比较了哪些已有研究？项目里写的目标是已经完成，还是计划完成？所谓的“国内领先”又是和谁比较？

如果这些问题说不清楚，那么报告写得再完整，也只是模型根据文字作出的印象判断。

我在科技文献智能服务平台里开发了一个创新性评估智能体。它不直接给整个项目打一个总分，而是先把项目里的关键主张拆出来，再去找文献证据，最后逐条形成判断。

这篇文章就用这个实例，讲一下这种智能体应该怎么开发。

一、先把最终结果定义清楚

开发之前，先确定系统最后要交付什么。

创新性评估的结果，不应该只有“创新性较高”或者一个八十分。比较有用的结果，至少要包括下面几部分：

• 项目主要声称了什么；
• 每条主张有没有外部证据；
• 已有研究和项目方案有什么相同或不同；
• 当前证据能够支持到什么程度；
• 哪些表述存在风险，需要用户确认。

把输出定义清楚以后，中间流程就容易拆了。系统不是去猜一个分数，而是帮助用户完成“拆主张、找证据、做比较、写结论”这几件事。

二、第一步不是检索，而是识别材料

用户上传的内容可能不止一份申报书。实际场景里，经常还会有项目指南、查新报告、技术说明、验收指标和参考资料。

这些文件的作用不一样。申报书里写的是项目团队自己的方案，指南写的是项目需要满足的要求，查新材料可能包含已有的对比结果。如果把它们全部当成项目事实，后面的判断就会混乱。

所以第一步要做材料解析和分类。至少要保存文件名称、材料类型、正文内容和原文位置。遇到扫描件，还要先做文字识别；遇到表格，不能只提取成一段没有结构的文本。

这一阶段有个实用原则：先保证内容能够回到原文，再考虑让模型总结。后面如果用户对某条结论有疑问，系统应该能指出它来自哪份文件、哪一段内容。

三、把项目里的“主张”拆出来

材料识别完成以后，下一步是提取项目主张。

主张可以简单理解成项目希望别人相信的事情。例如：提出了一种新的方法，某项指标优于已有方案，解决了以前没有解决的问题，或者首次应用在某个场景中。

模型很适合帮助我们从长文档中找出这些内容，但不能只保存一段总结。最好把每条主张整理成结构化数据，例如：

{
  "claim": "项目提出了一种新的文献关系发现方法",
  "claim_type": "方法创新",
  "source_file": "项目申报书.pdf",
  "source_position": "第12页，创新点2",
  "status": "计划实现"
}

这里尤其要区分“已经实现”和“计划实现”。申报材料里经常会写“项目将达到某个指标”，如果模型在报告中把它改写成“项目已经达到”，结论就完全变了。

同样，目标指标、阶段指标和验收指标也不要混在一起。它们需要分别保存，后面比较时才能使用同一个口径。

四、围绕每条主张制定检索方案

主张提取完成以后，再开始检索外部文献。

这里不要使用一个很大的关键词，把所有内容一次搜完。更稳妥的做法，是针对每条主张分别设计检索条件。

例如要验证一种方法是否新颖，就需要检索相似的研究对象、技术方法和应用场景；要比较某个性能指标，就需要找使用相同数据、相同计算方法和相近实验条件的文献。

大模型可以把自然语言主张转换成检索词，程序负责调用数据库和保存结果。每次检索最好记录：

• 使用了哪些关键词；
• 查询了什么时间范围；
• 返回了多少结果；
• 哪些文献被纳入证据池；
• 哪些结果因为不相关被排除。

保存这些内容，不只是为了调试。它还可以帮助用户理解为什么系统得出了某个判断。

五、核心结构是“主张—证据—判定”

创新性评估智能体最核心的数据结构，其实并不复杂，就是“主张—证据—判定”。

主张是项目说了什么。证据是项目材料和外部文献分别能够证明什么。判定则是把两边放在一起比较以后，系统形成的结论。

例如项目声称“首次将某种算法用于科技文献主题发现”。系统找到两篇更早的论文，也使用了相似算法处理科技文献，那么“首次”这个说法就需要重新确认。

但这并不意味着项目完全没有创新。它可能使用了新的数据，改进了算法流程，或者把方法用于更复杂的真实场景。智能体需要指出具体差异，不能因为发现相似研究，就直接把整个项目判定为没有创新。

最终可以把每条结果整理成这样：

项目主张	外部证据	当前判断
首次将某算法用于科技文献主题发现	已找到更早的相似研究	“首次”表述证据不足，需要缩小范围
在真实业务数据上提高识别效果	已有研究主要使用公开数据集	存在应用场景差异，但仍需补充实验结果

这种结构最大的好处，是用户看到结论时，可以继续查看它对应的原文和文献，而不是只能接受模型给出的分数。

六、不要把“没有搜到”写成“绝对原创”

开发这类智能体时，一定要处理好检索边界。

数据库不可能包含世界上所有研究，检索词也可能遗漏某些表达。没有找到相似文献，只能说明在当前数据库、关键词和时间范围内没有发现，不能证明全世界都没有人做过。

所以报告里可以写：“在本次检索范围内，暂未发现高度相似的公开研究。”不要直接写：“该项目属于全球首创。”

对于“首次、唯一、领先、填补空白”这类强表述，系统最好自动标记为高风险。如果证据覆盖不够，就交给用户或专家确认。

智能体有时候需要承认不知道。这个能力比写出一个很确定、但无法证明的答案更重要。

七、八个执行阶段，前台可以只讲五步

在系统实现里，我把创新性评估拆成八个阶段：

1. 解析材料并确认评估范围；
2. 提取项目目标、创新主张和指标；
3. 为不同主张制定检索方案；
4. 建立外部文献证据池；
5. 逐条比较主张和证据；
6. 判断创新性、先进性和表述风险；
7. 进行质量检查和人工复核；
8. 生成并导出评估报告。

但普通用户不需要一开始就看到八个技术阶段。前台可以把它们压缩成五步：解析、提取、溯源、评估和态势分析。

后端流程可以详细，前台表达要简单。开发人员不要把所有内部状态都堆给用户，而是让用户知道当前在做什么、为什么需要等待、出现问题时应该补充什么。

八、模型和程序还是要分工

创新性评估中，大模型适合做材料理解、主张提取、语义比较和报告表达。

普通程序负责文档保存、检索调用、文献去重、指标计算、引用编号、状态管理和规则检查。

例如“这两个方案的技术路线有什么区别”可以让模型分析；“这个数值是否比基准值高百分之十”应该由程序计算；“引用的论文是否真的存在”也应该由程序检查。

如果让模型自由生成所有数字和引用，报告每运行一次都可能发生变化。能通过程序确定的内容，尽量不要让模型猜。

九、质量检查不是再让模型重写一遍

报告生成后，还要做一次质量检查。

检查的重点包括：每条关键结论是否有证据，引用是否能够打开，项目指标和文献指标是否使用同一口径，是否把计划目标写成已有成果，以及报告中有没有过度结论。

发现问题后，不要只是让模型“重新生成一份更准确的报告”。应该回到最早出现问题的阶段。

如果文献不够，就重新检索；如果主张提取错了，就回到材料解析；如果指标口径不同，就标记冲突并请求人工确认。这样才能真正解决问题，而不是换一种说法把错误隐藏起来。

十、第一版应该先做什么

如果刚开始开发，不需要第一版就实现完整的八阶段系统。

可以先做一条最小链路：上传一份项目说明，提取三到五条创新主张，为每条主张搜索相关文献，然后生成一张“主张—证据—判定”对照表。

只要这条链路能够稳定运行，并且每条结果都能回到原文和外部文献，这个智能体就已经有了基本价值。

后面再逐步增加多文件解析、指标口径检查、趋势分析、人工复核、网页报告和文档导出。先保证每一步可靠，再增加更多功能。

最后

创新性评估智能体不是一个自动打分工具。它更像一个帮助用户整理材料、查找证据和核对表述的助手。

开发这类智能体时，重点不是让模型给出多专业的评价，而是让每个判断都有来源、每个强结论都有边界、发现不确定时能够停下来。

把项目拆成主张，把主张连接到证据，再基于相同对象和相同口径形成判断，这套方法不只适合科研项目。产品评估、技术调研、方案审查和合规检查，也可以按照类似的思路开发。

智能体真正有用的地方，不是替人承担最终责任，而是把原来分散、重复、容易遗漏的核对工作整理好，让人能够更快作出有依据的判断。