很多做题库的人都有类似经历题目数量到一定规模后审核重点就不再是“有没有复制”而是“有没有隐性重复”。我印象很深的一道数学应用题表面看和另一道题毫无关系。A 题考“一次函数求最值”B 题考“比例计算”题干文字完全不同连人名和地名都换成了虚构内容。可当我把两份题目并排打开时发现它们借用了同一张“出租车计费表”的信息结构只是把里程、单价、等待时间换了一些数字。审核员如果不把两题放在同一屏幕里对比几乎不可能发现。这还不是最麻烦的。最麻烦的是这两道题被编进了同一场测评的不同分卷先做完 A 题的学生在 B 题里一眼就能识别出“又是那张表”从而更快定位解法。对另一部分学生来说这种隐形的线索并不存在。测评的公平性就在这种不起眼的细节里被一点点侵蚀。这类问题对应一个专门的表述item incidental content similarity也就是测评题目之间发生了非刻意但客观上存在的内容相似。它可以发生在题干里、情境素材里、选项结构里甚至藏在图表的数据逻辑里。题库规模越大靠人工抽检就越不可靠。所以用大语言模型LLM搭建一个自动化相似性分析框架成了一个很自然的解法。但和传统“查重”思路不同的是仅仅比较文本是不够的。于是就有了“双维度”的设计一个维度管“文本像不像”另一个维度管“题目在测评功能上会不会互相干扰”。把这两个维度拆开才能把相似性从“文本事件”变成“内容质量事件”。1. 大规模测评里的“内容相似”为什么值得单独做一个框架1.1 相似性不一定来自抄袭它有三条完全不同的来源在大规模测评场景里题库的规模少则几千题多则几十万题。题目要保持独立性是测评效度的基本前提。这里的“独立性”不是指文字不同而是指一道题的出现不应该给另一道题提供不公平的解题线索。在实际内容审核中相似性通常来自三种不同路径直接文字复用整段题干、选项、导语被复制或轻微改写。这一种最常见也最好识别。素材共用文字表面完全不同但底层的情境素材是一样的。比如同一个数据表、同一篇短文、同一个实验设计只是修改了变量名和数字。认知任务撞车题目素材不同文字也不同但解题时依赖的线索路径、推理步骤或信息提取方式高度重合。比如两道题都要求先从文本中定位某个干扰信息再排除两个近义选项最后用比例关系得到答案。三种来源里直接文字复用靠传统查重工具就能处理素材共用需要结合语义理解认知任务撞车则几乎只能靠有测评经验的人来判断。而“偶然内容相似性”恰恰集中在后两类——它不是故意的但因为题材有限、情境套路有限、命题人习惯相近题目在功能层面发生了隐性重叠。1.2 传统查重工具卡在哪一层传统文本相似度手段大体上分三个层次字符串层n-gram 重叠、simhash、MD5 指纹去重适合抓精确重复和近似重复。词袋层TF-IDF、BM25、关键词共现能抓词汇层面的重合但很难处理同义改写和语序变化。语义向量层sentence embedding、向量检索可以抓语义相近但它解决的是“这句话和那句话意思近不近”而不是“这道题和那道题在测评中会不会互相泄底”。向量嵌入的进步已经很大可它依然缺少一层能力理解题目的测评意图。举个例子两道阅读题分别来自不同的文章文字没有重合但都设计了同一个问题“作者为什么在第二段提到这个细节”在测评功能上这两道题高度相似它们都考察同一个阅读策略但嵌入模型很可能给它们一个较低的相似度分数因为词面重叠太少。这也是传统方法在大规模测评里始终不够用的原因。它们本质上是在回答“文本是否雷同”而不是“题目之间是否存在内容质量风险”。当你需要清理的是后者时就必须换一个判断框架。1.3 从“文本查重”到“内容质量审查”是一次目标升级一旦目标从“查重”变成“内容质量审查”整个分析逻辑就要重构。文本查重只需要一个输出相似还是不相似。内容质量审查需要回答更多问题相似发生在哪一层是文字层、素材层还是认知任务层相似程度是否已经达到会影响考试公平性的级别应该直接去重还是在拼卷时不让它们出现在同一场测评里这些问题传统方法很难拆解。而大语言模型天然适合做这件事它能阅读完整题目理解情境素材还能按照提示词给出的维度逐项分析。于是一个围绕 LLM 的双维度分析框架就成了顺理成章的选择。2. 双维度框架到底在拆解什么2.1 第一个维度文本表征层解决“看起来像不像”第一个维度负责判断题目在文本和语义上的接近程度。它的输入是题目的完整文本包括题干、选项、说明、图表标题、脚注等。它需要回答的问题非常直接这两道题在字面和语义上像不像具体来说LLM 在这个维度要判断的内容包括题干语句是否存在字面重复或明显的同义改写关键名词、数字、单位、操作指令是否雷同选项的措辞和结构是否相似整段文字去掉修饰后核心信息是否高度重叠。这个维度的输出不能只是一个分数。对人工审核来说更有价值的是证据。比如“两道题都出现了 1200 元月租金、物业费分摊比例这两个关键数字”或者“选项中都包含‘无法确定’这个相同干扰项”。有了证据审核人员才能在几十个高相似对里快速判断哪些真的需要处理。文本层相似度高不一定代表题目必须被处理。同一批命题人习惯了某种表达风格或者同类题型天然会使用相似指令这些都会造成文本层分数偏高。它更多是一个危险信号提醒审核人员“这两道题值得再看一眼”。2.2 第二个维度测评功能层解决“放进同一场测评会不会互相泄题”第二个维度才是双维度框架真正区别于传统查重的地方。它分析的不是文字本身而是题目在测评中承担的功能是否重叠。测评功能层需要判断的内容包括两道题是否共用同一个情境素材例如同一张数据表、同一篇短文、同一个案例背景是否要求考生提取相同的信息路径例如都先定位某个异常数据再计算增长率是否共享关键解题线索例如某一题的题干无意中为另一题提供了公式或取值方向是否在认知层次和考察目标上构成重复比如同一场测评里连续出现两道“仅考查信息定位”的题目选项构造是否存在相同的诱导模式比如都利用“单位换算错误”设计干扰项。这类相似不依赖文字重合因此很难被嵌入模型直接捕捉。但它对测评公平性的影响往往比文字雷同更大。两道文字风格迥异的题目如果共用同一个情境素材那么先做第一题的学生在做第二题时已经对素材结构有了预判这种优势不是所有考生都有的。2.3 为什么必须保留两个维度而不是合并成一个综合分很多团队在第一次做相似性分析时倾向于让模型输出一个 0 到 100 的综合相似度分。这样看起来简单但实际落地会发现一个严重问题它把不同类型、不同处置方式的风险混在了一起。按照双维度框架的输出风险可以被分成四类文本层功能层典型情况建议处置高低同一命题人风格、模板化表达但测评功能独立优先级低可抽检低高文字完全不同但共用素材或解题线索最高优先级必须人工复核高高明显复用或深度改编高风险直接进入人工处理低低两题基本无关通过不处理真正最危险的不是“看起来像”的题目而是“看起来完全不像、但放在同一场考试里会互相暴露线索”的题目。如果只用综合分这类风险会被“文本层低分”稀释掉。所以框架的输出结构应该是两个维度各自独立成项而不是合成一个数字。这样既方便规则引擎自动分流也方便人工审核员快速定位风险类型。3. LLM 在双维度分析里的完整角色3.1 LLM 不是替代打分而是生成“可解释的判断”在这个框架里LLM 的核心能力不是给出一个相似度数值而是完成一次有依据的分析。它希望输出的是两个题目各自包含哪些关键要素这些要素在文本层和功能层分别有多大重叠重叠的证据是什么综合来看属于哪种风险级别。这套输出天然适合人工审核。审核员看到的不再只是一个“相似度 87 分”而是一份证据清单。比如文本层证据“两题题干都包含‘某市出租车计费标准’的完整段落只是调整了起租价和等候费的数字。”功能层证据“两题都要求考生从同一张分段计费表中推断临界里程解题路径一致存在线索暴露风险。”这类判断只有理解了测评上下文才能生成。LLM 恰好能在一个提示词里同时完成要素提取、维度判断和证据列举。如果你在这个场景里用传统嵌入模型你得到的是向量距离用规则引擎你需要穷举所有相似模式。而 LLM 让“用自然语言定义相似规则再用自然语言输出证据”成为可能。3.2 一个可参考的双维度提示词结构虽然不同框架的实现细节不一样但提示词结构通常可以分为三层系统指令、题目输入、输出约束。第一层告诉模型它扮演什么角色。这里需要强调“测评内容质量审核专家”而不是泛泛的文本相似度计算器。第二层传入完整的题目 A、题目 B以及可选的元数据比如题型、知识点、难度、考察能力。元数据不参与文本比较但能帮助模型理解题目在测评中的位置。第三层设定输出格式。我的建议是强制 JSON 结构化输出并明确要求模型给出证据。一个常见的设计结构如下你是一名测评内容质量审核专家。请比较以下两道题目分别从文本层和测评功能层判断它们的内容相似程度。 【题目 A】 {题目 A 的完整文本} 【题目 B】 {题目 B 的完整文本} 【元数据】 题目 A 题型{...} 题目 B 题型{...} 请按 JSON 格式输出 { textual_similarity: { score: low | medium | high, evidence: [证据1, 证据2] }, functional_similarity: { score: low | medium | high, evidence: [证据1, 证据2] }, overall_assessment: pass | review | flag, reason: 综合判断理由控制在150字以内 }实际使用时可以根据题库属性增加字段比如“知识考点是否重复”“情境素材是否共用”“是否涉及图表数据”。但要注意字段设计最终要服务于处置规则不要为了复杂而复杂。3.3 从原始题目到结构化结果中间需要一条完整数据链LLM 的输出只有在落入业务表之后才有价值。常见的数据链大致是这样的从题库中抽取题目原始内容保存为纯文本或 Markdown预处理环节补齐缺失部分比如把图表说明、选项、听力原文都拼装进题目文本组装题目对带上元数据调用 LLM校验 LLM 输出确认 JSON 能解析、字段完整、枚举值合法把分析结果写入相似性分析表包括文本层等级、功能层等级、证据、整体建议、模型版本、提示词版本在审核界面中并排展示两道题和 LLM 证据由人工做最终判断。很多项目在第三步和第四步之间就栽了。因为 LLM 返回的 JSON 偶尔会多一个字段、少一个逗号或者枚举值不符合预期。框架在工程上是否稳定往往取决于你对输出解析和校验的处理是否严格。4. 从单题对验证到大规模批处理必须走一条两阶段流水线4.1 最小可用流程先手工构造十几道“已知问题题”不要一上来就铺全量。我建议的最小可用流程分三步走。第一步从真实题库里挑 15 到 30 对题目。其中一半是已经确认存在内容相似风险的问题对一半是随机抽取、明显无关的对照组。第二步用同一个提示词跑一遍人工检查 LLM 的判断。重点不是看它判得准不准而是看它的证据是否合理、两个维度是否区分得开、有没有反复把“风格相似”误判成“功能相似”。第三步根据结果调整提示词和判定规则。比如明确告诉模型“文字风格类似不是风险共用情境素材且可能产生解题线索才是风险。”然后把每次调整都存成版本作为后续回归测试的基准。这套最小流程很重要。因为相似性判断没有标准答案只有在自己的题库样本上跑过一遍你才知道这个框架有没有真正理解业务。4.2 不能全量两两比较先用向量召回再用 LLM 精判很多人会犯一个直观但成本极高的错误直接把题库里所有题目两两配对丢给 LLM 做全量比较。假设题库有 10 万道题两两组合接近 50 亿对。就算每对只消耗几百 token运行成本也会高到无法接受更不用说多数比较完全没有意义。工程上更合理的做法是两阶段流水线第一阶段用嵌入模型对全部题目做向量化然后对每道题取 top-k 个最相似的候选对。k 通常取 20 到 50。这一阶段的任务不是精确判断而是把一个平方级问题压缩成一个近似线性问题。第二阶段只对候选对调用 LLM 做双维度分析。此时需要精判的题对数已经大幅下降成本可控。粗筛阶段可以用传统的向量相似度也可以结合题目元数据做过滤。比如先把题型不同的题对排除掉或者把不在同一考试时间窗内的题对排除掉。过滤条件越贴近业务候选对质量越高。这里要特别提醒一个指标粗筛的召回率。top-k 选得太小会漏掉大量真正的相似对选得太大LLM 精判阶段的成本又会上升。比较好的做法是先用一批已知风险题对做测试看当前配置能召回多少再决定 k 值。漏一点没关系但不能漏掉那些真正会造成风险的相似对。4.3 批处理时的成本、并发与稳定性控制在进入大规模批处理之后需要考虑的问题就开始向工程化转移。固定模型版本LLM 版本更新会改变输出风格和判断倾向不固定版本会导致分析结果不可复现。温度调到最低相似性分析需要稳定不需要创意。如果接口支持随机种子尽量固定。并发控制大规模调用时要注意接口速率限制设置合理的并发数避免批量失败。超时与重试为每次调用设置超时时间对超时和临时错误做退避重试并记录失败原因。断点续跑把处理状态写入数据库每个题目对都有“待处理、处理中、已完成、失败”几种状态。这样任何一步中断都不需要从头开始。成本方面真正的大头在 LLM 精判阶段。所以控制候选对数量就是在控制预算。如果发现成本过高优先检查粗筛阶段的 top-k 是否过大或者提示词里是否传入了大量对判断没有帮助的元数据。5. 落地时最容易翻车的几个边界问题5.1 输入不是一道题的题干而是完整刺激材料很多团队最开始只把“题干”文本传给 LLM结果发现判断结果很不稳定。原因很简单大量相似信息并不在题干里而在选项、图表、阅读材料、导语说明中。比如英语听力题题目文字可能只是“What does the man mean?”真正的相似性藏在两段听力文本里。这时如果不把听力原文拼装进输入LLM 就只能盲猜。建议在预处理阶段就把一道题的完整刺激材料拼装成规范文本包括题目导语、题干、选项、材料、图表说明、脚注。如果题目里有图片暂时无法做 OCR 抽取文本至少要在文本里保留“[图片] 图出租车分段计费表”这样的占位说明否则模型无法识别图表中的核心信息。5.2 不要把“相似”和“不应该出现”混为一谈这是判断标准上最容易出问题的一点。LLM 如果被简单要求“判断两道题是否相似”它很容易把任何相似都标成高风险。结果就是误报率极高人工审核团队很快被淹没在不必要的工单里。更好的做法是在提示词里明确分层。“相似”是中性的描述它只是告诉你两题存在某种关联只有当这种关联会影响到测评独立性时才需要标记为高风险。也就是说框架需要输出“两个维度等级”同时还要有一个“业务处置建议”。这两件事不能混在一起。比如“文本层高、功能层低”的题目对可以建议抽检但不建议直接进入高风险处理流程。5.3 结果不稳定是常态必须有审计链路LLM 的分析结果天然存在随机性。哪怕温度调到最低同一对题目在不同时间调用输出也可能有细微差别。这不代表框架不可用但要求你在工程上留好审计链路。我建议为每一次分析记录以下信息输入文本的哈希值或版本号提示词的版本号模型名称和版本LLM 原始返回内容解析后写入业务表的结构化结果人工复核的最终结论。这样一旦某条审核结果被认定是误判团队可以回放现场确认问题出在输入组装、提示词、模型版本还是后处理逻辑。没有审计链路任何 LLM 应用都很难在严肃业务里长期运行。5.4 一套面向双维度分析项目的排查顺序如果上线后发现结果明显不合理不建议直接调提示词。先按下面的顺序排查先看现象是漏报了相似题对还是误报了大量无关题对再看输入题目文本是否完整选项、图表说明、听力原文有没有缺失有没有混入模板标记或 HTML 标签再看粗筛阶段top-k 是否覆盖住了真正的相似对嵌入模型的领域和语言是否匹配阈值是不是把一些相似对提前过滤掉了再看提示词两个维度的定义是否清晰是否明确区分了“相似”和“需要处置”再看输出解析JSON 校验失败、字段缺失、枚举值越界这些都会导致结果异常。最后看模型和上下文模型上下文窗口是否足够容纳完整题目截断位置是否落在关键信息上模型版本是否发生变化多数问题不会出在 LLM 本身的“判断力”上而是出在输入、解析或者中间过滤环节。建议每一条 LLM 分析都保留“输入、提示词版本、模型版本、原始输出、解析后结果”五要素。原因是人工复核发现误判时能快速定位到底是哪一环节出了问题。6. 双维度框架的长期价值不只是“查重”6.1 它把内容审核的粒度推进到了题目关系层传统题库管理里内容审核往往是靠抽检和命题人自觉。题目量大之后审核团队只能按比例抽检漏检风险始终存在。双维度框架带来的一个长期变化是审核可以从“抽检”变成“全量初筛”。每一道新题入库前都能和已有题目做一次双维度比较输出一个低成本的相似度风险等级。审核人员的精力可以集中到那些“低文本、高功能相似”的题目对上——也就是最隐蔽、最危险的那类问题。这个转变的意义不在于省了审核员的多少时间而在于把题库内容质量从被动发现变成了主动预防。很多不该流到正式测评里的题目在入库阶段就被拦住了。6.2 适合什么场景不适合什么场景这套框架并不是万能的。它的典型适用场景包括大规模题库的定期质量审查新题入库前的相似度预筛组卷阶段检查同一套试卷内是否存在情境素材或解题线索重复学习资源库、教辅内容平台的重复题识别和关联推荐。但它不适合这样的场景法律意义上的抄袭判定。这涉及法律定性LLM 的判断只能作为线索不能作为依据完全无人值守的自动处置。测评公平性影响很大最终结论必须有人工确认题目总量很小、人工审核已经完全够用的小团队。另外还有一个前置条件题库数据要相对规范。如果题目文本本身残缺、图片信息没有 OCR、元数据大量缺失这个框架的效果会大打折扣。先做数据治理再上 LLM 框架顺序不能反。6.3 如果要长期运行还缺哪几块拼图把一个实验性质的框架变成一个长期运行的审核能力还需要补齐四块拼图。第一块是反馈回路。人工审核的结果要回写形成“哪些相似被确认为风险、哪些相似被认定为无关”的标签数据。这些数据是后续优化提示词和判定规则的依据。第二块是评估指标。不要只看“准确率”要拆开看召回率、误报率、审核人员处理单题的平均耗时、高风险题目发现率。这些指标能帮你判断框架到底有没有降低审核成本。第三块是版本管理。提示词版本、模型版本、题目文本版本都要纳入管理。否则一次提示词调整导致批量误判时你很难快速回滚。第四块是内容政策表。不同测评项目对“怎么处置相似题目”可能有不同规则。框架输出的只是风险等级最终处置要落到业务规则引擎里再由规则引擎转成人工工单或自动拦截。真正难的不是把 LLM 接进来而是把“内容相似性”这个模糊的业务概念拆成两个可计算、可验证、可审计的维度再围绕它们搭建一条从样本验证到大规模批处理的稳定流程。如果你也想做类似的自动审核能力我建议不要先买一堆大模型 API而是先从自己的题库里挑出二三十对真实问题题人工标注出相似类型然后让 LLM 跑一版双维度提示词。你会很快发现这套思路值不值得继续投入答案几乎会在第一轮结果里就显现出来。