LLM驱动的文本相关性评估：从RAG到可持续性分析的工程实践

1. 从“检索”到“分析”：LLM相关性评估的价值跃迁

最近在折腾几个跟大语言模型相关的项目，从简单的RAG（检索增强生成）应用，到更复杂的可持续性报告分析，我反复被一个问题卡住：如何判断LLM生成的回答，或者它检索到的文档，真的和我的问题“相关”？这个问题看似简单，但当你把LLM从一个“聊天玩具”升级为生产环境中的“决策辅助大脑”时，它就变成了一个核心的质量阀门。

传统的文本相关性评估，比如在搜索引擎里，我们看TF-IDF、BM25这些算法，它们计算的是词频、逆文档频率，本质上是词汇层面的匹配。你问“苹果公司市值”，它给你返回一篇讲“苹果营养价值”的文章，虽然都有“苹果”这个词，但显然不相关。LLM的出现，让我们第一次有机会去理解语义层面的相关性。它不仅能看懂“苹果”在语境里指的是水果还是科技巨头，还能理解“市值”和“财务报告”、“股价波动”之间的深层关联。

但问题也随之而来。LLM自己说相关就相关吗？我们怎么去量化、去评估这种由“黑盒模型”做出的相关性判断？特别是在两个越来越重要的场景里：检索增强生成（RAG）和可持续性分析。在RAG流程中，相关性评估是精准召回信息的守门员，直接决定生成答案的质量上限；在可持续性分析中，它则是从海量非结构化报告（如ESG报告、企业社会责任文件）中提取有效信息、进行交叉验证的基石。如果相关性评估不准，后续的一切分析都像是建立在流沙之上。

所以，这篇文章我想结合自己的实践，聊聊怎么用LLM本身来评估文本相关性，把这件事从一个模糊的感觉，变成一套可落地、可迭代的技术方案。我们会从最基础的RAG场景切入，再延伸到更具挑战性的可持续性分析领域，看看这里面有哪些坑，以及我是怎么填上的。

2. RAG流程中的相关性评估：不只是“找得到”，更要“找得准”

检索增强生成（RAG）的基本流程大家都熟悉：用户提问 -> 检索相关文档片段 -> 将片段和问题一起喂给LLM -> LLM生成答案。这里的致命弱点在第二步和第三步之间：我们默认检索系统返回的Top-K个片段都是高度相关的。但现实很骨感，基于向量相似度的检索，经常会混入一些“似是而非”的内容。

2.1 为什么需要独立的“相关性裁判”？

最开始做RAG应用时，我也偷懒，直接把检索到的前3个片段塞进上下文就完事了。结果就是，LLM时而发挥超常，时而又会一本正经地胡说八道（Hallucination）。仔细复盘发现，很多次胡诌，都是因为上下文里混入了一个相关度只有60%的文档。LLM很“努力”地想把这个片段和问题联系起来，反而导致了事实扭曲。

这时就需要一个独立的“相关性裁判”。它的任务是在文档片段进入LLM生成环节之前，对其进行过滤和排序。这个裁判本身也是一个LLM（通常是比生成模型更小、更快的模型），它的输入是“用户问题”和“候选文档”，输出是一个相关性分数或分类（如“相关”/“不相关”）。

这么做有几个实在的好处：

1. 提升答案质量与事实性：确保生成模型基于最相关的信息作答，减少幻觉。
2. 降低计算成本与延迟：如果只用前K个，可能要把K设得很大才能保证召回，导致每次生成都要处理很长的上下文，既贵又慢。先用小模型做一次过滤，可以只把最相关的少量片段送给大模型，性价比极高。
3. 改善用户体验：对于明确不相关的问题，可以直接在检索后阶段回复“未找到相关信息”，而不是让大模型硬编一个答案。

2.2 构建评估器：Prompt设计、模型选择与评分策略

如何构建这个“裁判”？直接让LLM做判断题或者打分题。

首先是Prompt设计。这是效果差异的关键。一个糟糕的Prompt会让LLM的评估变得极不稳定。

我踩过的坑：最初我用的是非常简单的Prompt：“请判断以下文档是否与问题相关。只回答‘是’或‘否’。” 结果发现，对于某些边缘情况，模型经常给出模棱两可的回答，甚至有时会额外输出解释，导致后续程序解析失败。

目前我验证效果比较好的Prompt结构如下：

你是一个精准的信息过滤助手。你的任务是根据用户问题，严格评估提供的文档内容是否包含回答问题所必需的关键信息。 用户问题：{query} 待评估文档：{document} 请按照以下步骤思考： 1. 理解用户问题的核心意图和关键信息需求。 2. 精读文档，提取其核心主题和关键事实。 3. 判断文档内容是否直接包含或强烈支持回答用户问题所需的信息。注意，文档仅需提供部分关键信息即可视为相关，不要求完整回答。 4. 你的输出必须严格遵循以下格式，且仅包含格式中的内容： 格式： 相关性判断：[相关/不相关] 置信度：[0.0-1.0之间的一个浮点数，保留一位小数] 判断理由：[一句话简要说明原因，不超过20字]

这个Prompt的改进点在于：

• 角色定义：明确了“信息过滤助手”的定位，引导模型聚焦于“必要性”而非“泛泛相关性”。
• 链式思考（CoT）：通过“请按照以下步骤思考”引导模型进行内部推理，这通常能提高判断的准确性，尤其对于复杂问题。
• 结构化输出：强制规定输出格式，便于程序自动化解析。同时引入“置信度”，为后续的阈值过滤或加权排序提供了更精细的维度。
• 降低标准：明确“文档仅需提供部分关键信息即可视为相关”，这符合RAG的实际场景——我们常常需要从多个片段拼凑答案。

其次是模型选择。你不一定需要GPT-4来干这个活。我的经验是：

• 轻量级本地模型是首选：如Qwen-7B-Chat、Llama-3-8B-Instruct 这类模型，在专门训练或精调后，在相关性判断任务上可以达到非常不错的水平，且延迟低、成本可控。这就是为什么“python调用qwen llm”、“ubuntu 安装llm”会成为热门搜索——大家都在寻求可控、私有的评估方案。
• API模型的优缺点：使用GPT-3.5-Turbo或Claude Haiku等API模型，开发速度快，效果相对稳定，但会产生持续费用，且有数据隐私考量。适合原型验证或对数据隐私不敏感的场景。
• 关键指标：选择模型时，除了准确率，更要关注评估延迟和吞吐量。因为每个检索结果都需要评估，这个环节很容易成为性能瓶颈。

最后是评分策略与阈值调优。拿到“置信度”分数后，怎么用？

1. 硬过滤：设定一个阈值（如0.7），高于阈值的保留，低于的丢弃。这个阈值需要你在自己的验证集上反复测试来确定。阈值太高，可能过滤掉有用的信息（假阴性）；阈值太低，则过滤效果不佳。
2. 软排序/加权：不丢弃任何片段，而是将相关性置信度作为权重，在后续的上下文组织或答案生成中体现。例如，在构造生成模型的上下文时，将高相关度的片段放在更靠前的位置。
3. 混合策略：先硬过滤掉低分（如<0.3）的明显噪声，再对中等分数的片段进行加权排序。

实操心得：阈值不是一成不变的。如果你的文档库和问题类型发生变化，阈值可能需要重新校准。建立一个包含各种相关性程度样本的小型测试集，定期跑一下评估器，观察其性能变化，是一个好习惯。

3. 从通用评估到领域深化：可持续性分析的特殊挑战

如果说RAG中的相关性评估是“选择题”（判断单个片段是否相关），那么在可持续性分析（尤其是ESG——环境、社会、治理分析）中，相关性评估就变成了“综合阅读理解题”。它的挑战维度要多得多。

3.1 领域知识的深度融合：让LLM理解“双碳”、“供应链人权”与“董事会多样性”

可持续性报告充满了专业术语和特定语境。例如，一家公司的报告里写“我们减少了Scope 1和Scope 2的排放”。一个通用领域的相关性评估器，可能只知道“减少”、“排放”是相关的，但它无法理解“Scope 1和Scope 2”是温室气体核算体系中的核心分类，这个信息对于评估企业的碳管理绩效极度相关。

因此，在可持续性分析领域，构建相关性评估器不再是简单的Prompt工程，而需要领域知识注入。方法主要有两种：

1. 领域知识增强的Prompting：在Prompt中明确加入领域定义和关键概念。

   • 原始Prompt：“判断文档是否与‘公司环保表现’相关。”
   • 增强后Prompt：“判断文档是否与‘公司环保表现’相关。此处‘环保表现’特指与温室气体排放（尤其是Scope 1, 2, 3）、能源消耗、水资源管理、废弃物处理及生物多样性影响相关的披露、数据、政策或行动。关于一般性社区活动或员工福利的描述，如无明确环境维度，则视为不相关。”

2. 领域数据微调（Fine-tuning）模型：这是更彻底但效果通常更好的方法。收集一批可持续性报告文本片段，并由领域专家标注它们与各类ESG问题（如“碳排放”、“劳工权益”、“反腐败政策”）的相关性。然后用这批数据去微调一个基础LLM（如Qwen-7B），得到一个领域专用的相关性评估模型。这个模型内化了ESG领域的语义空间，对相关性的判断会精准得多。搜索词“llm knowledge graph builder 软件功能介绍”背后，也反映了人们想用更结构化的方式（如知识图谱）来管理领域知识，进而辅助LLM进行更精准的理解和关联。

3.2 长文档分析与多粒度评估：段落、句子与数据点

可持续性报告往往是上百页的PDF。我们评估的不再是预先切好的短片段，而是可能需要对整个长文档进行多粒度的扫描。

• 篇章级相关性：快速判断这份报告整体上是否与“气候变化”或“社会包容性”主题相关？这可以帮助分析师快速筛选需要深入阅读的报告。
• 段落/章节级相关性：找到报告中具体讨论“供应链碳排放管理”或“董事会性别比例”的部分。
• 句子/数据点级相关性：精确提取“2023年碳排放强度为每营收单位XX吨二氧化碳当量”这样的具体数值和陈述。

这就要求我们的评估流程是一个分层漏斗：

1. 先用一个轻量模型或规则（如关键词匹配）对报告进行粗筛。
2. 对可能相关的报告，进行章节分割，然后使用评估器对章节进行评分。
3. 对高相关章节，进一步进行句子级拆分和精细评估，以提取关键事实和数据。

这个过程会涉及大量的文本分割（Chunking）和多次的LLM调用，对流程设计和成本控制要求很高。这也解释了为什么“上传一个文件 作为llm的分析数据报token过大”是一个常见痛点——需要设计合理的文本预处理和分块策略来适配模型的上下文窗口。

3.3 事实核查与证据关联：超越语义，锚定事实

在可持续性分析中，相关性不仅关乎“是否提及”，更关乎“是否提供了支持性证据”。比如，一家公司声称“我们致力于循环经济”，这是相关的。但如果评估标准更严格，我们会要求找到“具体措施”，比如“产品A使用了30%的再生塑料”或“在B工厂实施了废水回收系统”。

因此，高级的相关性评估需要具备事实核查和证据关联的能力。这可以通过以下方式实现：

• 设计具有核查意识的Prompt：“判断文档是否提供了关于‘公司循环经济实践’的具体证据或实例。仅泛泛而谈的承诺或政策声明视为弱相关或需要进一步核查；包含具体项目、数据、技术名称的视为强相关。”
• 多轮评估与溯源：第一轮评估定位到相关陈述，第二轮评估针对该陈述，要求模型从上下文中提取或总结支持性证据。这为后续的人工审核或交叉验证提供了便利。
• 与知识图谱结合：这正是“llm knowledge graph builder”类工具的用武之地。可以将提取出的实体（公司名、项目、数据）、关系（实施了、达到了、减少了）和属性（数值、百分比、年份）存入知识图谱。相关性评估可以转化为在图谱中查找关联路径的强度。例如，判断“公司X”与“碳中和”的相关性，可以转化为查找图谱中从“公司X”节点出发，通过“实施项目”、“排放数据”、“减排技术”等关系链，能否连接到“碳中和”目标节点，以及路径上证据的权重如何。

4. 构建生产级评估系统：工程化与持续优化

把一两个成功的Prompt测试用例变成一个稳定、高效、可维护的生产系统，是另一回事。这里涉及到大量的工程化细节。

4.1 系统架构与性能考量

一个典型的生产级LLM相关性评估系统可能包含以下组件：

• 调度器：管理评估任务队列，处理并发请求，实现负载均衡。
• 模型服务层：可以封装本地部署的模型（如通过vLLM、TGI等高性能推理框架）或协调多个云API的调用。需要考虑模型的热加载、故障转移。
• 缓存层：这是提升性能的关键。完全相同的(query, document)对，其评估结果在一定时间内是稳定的。可以将其结果缓存起来（如使用Redis），下次直接返回，能极大减少LLM调用和降低延迟。缓存键的设计需要精心考虑，比如对query和document进行标准化处理（去除多余空格、统一大小写）后再哈希。
• 评估日志与监控：详细记录每一次评估的输入、输出、耗时、模型使用情况。这不仅是排查问题的依据，更是后续优化数据的主要来源。

关于性能，如果使用API，需要注意速率限制和错误重试机制（搜索词“agent failed before reply: llm request failed: provider rejected the request”正是此类错误的体现）。如果使用本地模型，则需要优化批处理（Batching）能力，一次性评估多个(query, document)对，以充分利用GPU算力。

4.2 评估器的评估：如何知道我们的“裁判”是公正的？

我们依赖LLM评估相关性，但谁来评估这个“评估器”本身的好坏？我们需要一套验证机制。

1. 构建黄金标准测试集：这是最根本的。需要领域专家人工标注一批高质量的(query, document, 相关性标签)数据对。这个数据集应覆盖各种情况：明显相关、明显不相关、边界模糊、需要领域知识判断等。
2. 定义评估指标：
   • 准确率/精确率/召回率/F1分数：这是分类任务的标准指标。根据你的需求，可能更关注精确率（尽量减少误判为相关的噪声）或召回率（尽量不漏掉真正相关的文档）。
   • 与人类标注的一致性：计算评估器输出与专家标注的Kappa系数等一致性指标。
   • 延迟与吞吐量：在满足质量要求下的性能表现。
3. 持续迭代：用测试集定期评估模型性能。如果发现模型在某些类型的问题上表现不佳（例如，无法理解某些专业术语），可以将这些bad cases加入训练数据，对模型进行进一步的精调（Fine-tuning），或者调整Prompt。这就是一个持续的“评估-优化”循环。

4.3 常见陷阱与应对策略

在实际部署中，会遇到一些意料之外的问题：

• Prompt的脆弱性：稍微改变问题的措辞，可能导致评估结果波动。应对策略是进行广泛的对抗性测试，用不同方式询问同一个问题，检查评估结果是否一致。
• 长上下文带来的信息稀释：当document很长时，关键信息可能被淹没，导致模型误判。应对策略是优化文本分块策略，确保每个chunk在语义上相对完整，并且大小适合模型处理。也可以尝试在Prompt中要求模型“重点关注文档的开头、结尾以及加粗、标题部分”。
• 成本失控：对于海量文档库，全量评估成本高昂。应对策略是采用多级过滤：先用成本极低的关键词或向量相似度进行粗筛，得到候选集，再使用LLM评估器对候选集进行精筛。
• 模型本身的偏见：LLM可能内置某种倾向性。例如，对于涉及某些行业或议题的文本，模型可能有过度的“相关性”或“不相关性”倾向。需要通过多样化的测试集来检测并尝试通过Prompt或数据来缓解。

5. 未来展望：走向自动化、可解释与多模态评估

LLM驱动的文本相关性评估还在快速演进。结合当前的实践和趋势，我认为有几个方向值得关注：

• 自动化工作流的深度集成：评估器不再是一个孤立的模块，而是深度嵌入到从数据爬取、清洗、标注到分析报告生成的整个自动化流水线中。例如，在可持续性分析平台中，自动化的报告抓取器+智能分块器+领域评估器+信息提取器可以形成一个端到端的解决方案。
• 评估过程的可解释性：目前我们更多依赖模型的“自信度”分数。未来，我们可能需要模型提供更详细的评估依据，例如“因为文档在第X段提到了Y数据，这与问题中的Z概念直接对应”。这能极大增强人类对AI判断的信任，也便于审计和纠错。
• 多模态相关性评估：企业的可持续性信息不仅存在于PDF报告中，还存在于图片（如工厂环境照片）、图表（碳排放趋势图）甚至视频（CEO演讲）中。未来的评估系统需要能够理解多模态内容，并判断其与文本问题的相关性。例如，判断一张图片是否展示了公司的污水处理设施，并与此前文本中声称的“水资源管理投入”相关联。
• 从小样本学习到零样本泛化：我们希望评估器能够快速适应新的领域或新的评估维度，而不需要每次都收集大量标注数据。通过更好的Prompt设计、思维链（CoT）以及模型本身能力的进化，实现更强的零样本或少样本泛化能力，将是降低应用门槛的关键。

从我自己的项目经验来看，基于LLM的文本相关性评估，已经从一项前沿探索，变成了构建可靠AI应用不可或缺的基础设施。它就像给系统装上了“语义嗅觉”，让机器能更精准地捕捉信息之间的内在联系。无论是在RAG中提升答案的置信度，还是在可持续性分析中从繁杂的信息中提炼真知灼见，这项技术都在扮演着越来越重要的角色。当然，它并不完美，对Prompt的依赖、对计算资源的消耗、对领域知识的渴求，都是现实的挑战。但正因为有这些挑战，才有我们这些工程师不断调试、优化和创新的空间。