1. 项目概述为什么RAG评估不是“差不多就行”如果你最近在折腾RAG检索增强生成应用肯定有过这样的体验模型有时候回答得头头是道引经据典有时候又像喝醉了酒开始胡言乱语甚至“捏造”一些根本不存在的文档内容。你改改提示词调调检索参数感觉好像好了一点但又说不出具体好了多少。这种“凭感觉”的优化就像蒙着眼睛开车方向对不对全看运气。这就是我们今天要解决的问题。RAG评估说白了就是给你的AI应用装上一套“仪表盘”和“质检仪”。它不能帮你直接造车构建应用但能告诉你车的速度、油耗、以及哪个零件可能有问题。没有评估的RAG优化无异于盲人摸象。而“LangChain 30天保姆级教程”进行到第26天终于要直面这个最核心、也最容易被忽视的环节——如何科学地、量化地评估你的RAG系统。传统的评估方法比如人工一条条看回答或者简单计算一下检索文档和生成答案的字面匹配度在真实场景下基本是失效的。人工评估成本高、速度慢、主观性强字面匹配则完全无法应对语义层面的问题比如“苹果公司”和“水果苹果”虽然都有“苹果”但天差地别。因此我们需要一套更智能、更自动化的评估体系。这就是TruLens这类工具的价值所在。它不是一个简单的打分器而是一个评估框架允许你定义和组合多种维度的指标从“事实一致性”到“回答相关性”再到“信息冗余度”全方位地为你的RAG回答做“体检”。这次实战的目标很明确我们将手把手带你搭建一个完整的RAG评估流水线。不仅仅是调用现成的评估函数更重要的是我们会深入“自定义指标”这个核心环节。因为你的业务场景是独一无二的——一个法律咨询RAG和一个客服问答RAG它们的“好答案”标准肯定不同。我们将学习如何根据你的特定需求定义属于你自己的“黄金标准”并用代码将其实现让评估真正为你的业务目标服务。2. 评估体系设计从通用指标到自定义战场在开始写代码之前我们必须先把评估的“考纲”定下来。胡乱评估一通得到一堆数字除了自我安慰没有任何意义。一个科学的RAG评估体系通常围绕三个核心维度展开答案相关性、上下文相关性和事实一致性。TruLens将其抽象为Relevance、Context Relevance和Groundness但这只是起点。2.1 理解三大基础评估维度答案相关性生成的答案是否直接、有效地回答了用户提出的问题这是最根本的要求。例如用户问“如何更换汽车轮胎”答案却在大谈轮胎的发展历史这就是不相关。评估这个维度通常需要一个大语言模型作为“裁判”来判断问题和答案之间的语义匹配程度。上下文相关性我们检索出来并喂给大模型的“上下文”即那些文档片段它们本身是否与用户问题高度相关如果检索系统不给力塞给模型一堆无关文档那模型再厉害也是“巧妇难为无米之炊”甚至可能被无关信息带偏。这个指标评估的是检索环节的质量。事实一致性这是RAG的“生命线”。生成的答案中的事实性陈述是否严格来源于提供的上下文有没有“幻觉”即模型自己编造例如上下文只说“某产品支持A和B功能”但模型回答时却加上了“还即将推出C功能”这就是严重的事实不一致。这个指标要求模型能逐条核对答案中的主张是否在上下文中有所依据。TruLens提供了这些基础指标的实现开箱即用。但真实世界远比这复杂。2.2 为何必须引入自定义指标因为通用指标解决不了你的特殊问题。我举个例子你就明白了场景一技术文档问答你的RAG用于查询某个软件框架的API。这时候“答案的准确性”可能比“语言的流畅性”重要一万倍。一个磕磕巴巴但参数完全正确的答案远胜于一个流利但参数说错的答案。你可能需要定义一个“关键参数准确率”的指标。场景二创意写作辅助你的RAG用来根据用户提供的关键词生成故事片段。此时“事实一致性”可能没那么关键但“风格符合度”比如是否保持了悬疑风格和“创意新颖性”就至关重要。场景三合规审查你的RAG用来检查合同条款是否合规。那么“风险条款覆盖率”和“违规引用精确度”就是核心指标。你需要评估模型是否找全了所有风险点并且指出的具体条款位置是否准确。你看这些需求都无法直接用“相关性”或“一致性”来涵盖。自定义指标就是将你的业务逻辑翻译成评估模型能理解的“数学语言”的过程。2.3 设计自定义指标的四步法设计一个有效的自定义指标可以遵循以下四个步骤这比直接写代码更重要明确业务目标抛开技术先想清楚“什么样的回答对我的用户来说才是好回答”用自然语言描述出来比如“答案必须包含至少三个具体的操作步骤”、“不能出现任何主观臆测的词语”等。指标量化将自然语言描述转化为可量化的维度。例如“包含操作步骤”可以量化为“答案中枚举或列表项的数量”“无主观臆测”可以转化为“检测答案中是否出现‘可能’、‘我觉得’、‘应该’等特定词汇”。选择实现工具思考用什么技术来实现这个量化。简单的可以用正则表达式匹配关键词复杂的可能需要调用另一个LLM进行判断或者使用专门的NLP模型如情感分析模型来判断语气。定义评分规则确定如何将量化的结果映射到一个分数上比如0到1分。是布尔判断符合1不符合0还是阶梯式评分找到1个风险点得0.3找到3个以上得1或者是连续函数遵循这个思路你的自定义指标才能真正驱动优化而不是为了评估而评估。3. 环境搭建与TruLens核心概念解析工欲善其事必先利其器。在开始评估实战前我们需要把环境和核心概念理清楚。这一部分我会详细说明每一步的选择理由帮你避开初期配置的坑。3.1 依赖安装与版本管理首先创建一个干净的Python虚拟环境是绝对的好习惯它能避免包版本冲突这个“幽灵问题”。这里我推荐使用conda或venv。# 使用 conda conda create -n rag-eval python3.10 conda activate rag-eval # 或使用 venv python -m venv rag-eval source rag-eval/bin/activate # Linux/Mac # rag-eval\Scripts\activate # Windows接下来安装核心依赖。请注意LangChain和TruLens的生态更迭较快指定版本能最大程度保证本次教程的复现性。pip install langchain0.1.0 openai1.12.0 trulens-eval0.19.2 chromadb0.4.22 tiktokenlangchain我们构建基础RAG链的框架。选择0.1.0这个相对稳定的版本。openai用于调用GPT模型作为生成和评估的“大脑”。你需要准备好自己的OpenAI API密钥。trulens-eval今天的主角评估框架。chromadb一个轻量级向量数据库用于存储和检索我们的文档。选择它是因为简单易用适合演示。tiktokenOpenAI的分词器用于精确计算token数量管理成本。注意trulens-eval在安装时可能会依赖一些系统库如build-essential。如果在Linux环境下遇到编译错误通常需要安装python3-dev等包。例如在Ubuntu上可以运行sudo apt-get install python3-dev。3.2 TruLens 核心三要素App、Feedback Function 和 TruChainTruLens的架构非常清晰围绕三个核心概念构建理解它们就理解了整个评估流程App这就是你要评估的对象——你的RAG应用。在TruLens眼里你的应用就是一个接收输入用户问题并产生输出答案和中间上下文的黑盒。TruLens会通过“插桩”技术在应用运行时自动捕获这些输入、输出以及中间状态比如检索到的文档。Feedback Function反馈函数这就是具体的“评分标准”。每一个评估维度如相关性、一致性都对应一个反馈函数。它接收从App中捕获的数据如问题、答案、上下文经过计算可能调用LLM也可能用规则输出一个0到1之间的分数。TruLens内置了一些而我们主要攻克的就是如何创建自定义的反馈函数。TruChain这是连接App和Feedback Function的“桥梁”。你可以把它理解为App的一个“监控器”或“装饰器”。你用TruChain包裹住你的LangChain应用并告诉它需要运行哪些反馈函数进行评估。之后每次调用这个被包裹的链TruLens都会自动执行评估并将结果记录到数据库默认是本地SQLite中。这个设计的好处是非侵入性。你几乎不需要修改原有的应用代码只需要用TruChain把它包起来并配置好评估函数所有的记录、评估、存储就都自动完成了。这为后续的分析和迭代提供了极大的便利。3.3 初始化关键组件LLM与向量库在写评估代码前我们先搭建一个最简单的RAG应用作为评估靶子。这里会涉及一些LangChain的基础操作。import os from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 设置你的OpenAI API密钥请务必妥善保管不要提交到代码仓库 os.environ[OPENAI_API_KEY] 你的-api-key-here # 2. 初始化模型 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 评估时建议temperature0减少随机性 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 用于文档向量化 # 3. 准备文档并存入向量库 # 假设我们有一些关于“机器学习”的文档 documents [ 机器学习是人工智能的一个分支它使计算机能够在没有明确编程的情况下学习。, 监督学习需要使用带有标签的数据集进行训练例如分类和回归任务。, 无监督学习用于发现未标记数据中的模式例如聚类和降维。, 深度学习是机器学习的一个子领域它使用神经网络特别是深度神经网络。, 过拟合是指模型在训练数据上表现太好以至于无法泛化到新数据。 ] # 分割文档以适应模型的上下文窗口 text_splitter RecursiveCharacterTextSplitter(chunk_size200, chunk_overlap50) texts text_splitter.create_documents(documents) # 创建向量存储 vectorstore Chroma.from_documents(documentstexts, embeddingembeddings) retriever vectorstore.as_retriever(search_kwargs{k: 2}) # 每次检索2个片段 # 4. 构建一个简单的RAG链 prompt_template 请根据以下上下文来回答问题。如果你不知道答案就说你不知道不要编造信息。 上下文 {context} 问题 {question} 请用中文给出答案 prompt ChatPromptTemplate.from_template(prompt_template) # 定义链检索 - 组合上下文 - 提示 - LLM生成 - 解析字符串 rag_chain ( {context: retriever, question: RunnablePassthrough()} | prompt | llm | StrOutputParser() )现在我们有了一个可以运行的RAG应用rag_chain。你可以用rag_chain.invoke(“什么是监督学习”)来测试它。接下来我们将用TruLens为它装上“评估引擎”。4. 基础评估实战使用TruLens内置反馈函数让我们先感受一下TruLens内置评估能力的便利性。我们将评估上面构建的RAG链在“答案相关性”和“事实一致性”两个通用维度上的表现。4.1 初始化TruLens并连接应用首先我们需要从TruLens导入核心类并创建一个“记录器”。这个记录器负责管理所有的评估运行。from trulens_eval import TruChain, Feedback, Tru from trulens_eval.feedback import Groundedness from trulens_eval.feedback.provider.openai import OpenAI as TruLensOpenAI # 初始化TruLens默认会在当前目录创建数据库文件 tru Tru() # 使用TruLens封装的OpenAI provider来创建反馈函数 # 注意这里用的是 TruLensOpenAI它内部会处理与评估相关的prompt工程 provider TruLensOpenAI() # 定义内置的反馈函数 # 1. 答案相关性评估答案对问题的回应程度 f_qa_relevance Feedback(provider.relevance_with_cot_reasons, name答案相关性).on_input_output() # on_input_output() 表示这个反馈函数将接收链的输入问题和输出答案作为参数 # 2. 事实一致性基于上下文的真实性评估答案是否基于提供的上下文 grounded Groundedness(groundedness_providerprovider) f_groundedness Feedback(grounded.groundedness_measure_with_cot_reasons, name事实一致性).on_input().on_output().on_default() # 这里比较复杂 # .on_input(): 提供“问题” # .on_output(): 提供“答案” # .on_default(): 提供“上下文”这是TruChain自动从检索器捕获的中间状态 # 这个链式调用定义了反馈函数的数据来源。这里有个关键点on_default()。在TruLens中当你用TruChain包装一个LangChain应用时它会自动尝试捕获链中名为“context”的中间步骤输出。我们的RAG链里retriever检索出的内容正好被赋值给了context变量所以TruLens能自动抓取到它。如果你的上下文变量名不是context你需要使用.on(“你的变量名”)来明确指定。4.2 包装RAG链并运行首次评估现在我们用TruChain把我们的应用和反馈函数“绑”在一起。# 使用 TruChain 包装原始的 rag_chain并指定要使用的反馈函数 tru_rag_chain TruChain( rag_chain, app_idMy_RAG_App_v1, # 给应用起个名字方便后续在仪表盘区分 feedbacks[f_qa_relevance, f_groundedness] # 传入我们定义的两个反馈函数 ) # 运行一次评估 question 机器学习和深度学习是什么关系 response tru_rag_chain.invoke(question) print(f问题{question}) print(f答案{response})运行这段代码会发生几件事tru_rag_chain.invoke()会先执行你原有的RAG链得到答案。同时TruLens在后台自动捕获了输入问题、输出答案和上下文。然后它异步调用你定义的两个反馈函数f_qa_relevance和f_groundedness分别对这次交互进行评估。评估结果分数和原因会被自动保存到本地的SQLite数据库中。此时控制台可能不会立即打印出分数因为评估是异步的。分数被记录到了数据库。我们可以运行一个简单的命令来启动TruLens的本地仪表盘查看结果。# 在Jupyter Notebook中可以直接运行 tru.run_dashboard() # 如果是脚本运行后默认会在浏览器打开 http://localhost:8501在仪表盘中你可以看到每一次调用Record的详细信息包括输入、输出、上下文以及两个反馈函数的打分0到1之间和详细的评估理由LLM给出的判断原因。这已经比人工评估强大太多了4.3 解读首次评估结果与常见陷阱打开仪表盘你可能会看到“答案相关性”得分很高比如0.9但“事实一致性”得分可能只有0.7或更低。我们来看看为什么。高相关性因为我们的问题明确上下文也包含了“深度学习是机器学习的一个子领域”这句话所以LLM很容易给出一个高度相关的答案。一致性扣分LLM评估“事实一致性”时会逐句检查生成答案中的事实主张是否能在提供的上下文中找到支持。有时生成答案会进行一些合理的推论或换一种说法表述如果上下文没有完全相同的表述严格的评估器可能会扣分。例如答案说“深度学习属于机器学习”上下文是“深度学习是机器学习的一个子领域”这本质一致但措辞不同可能导致分数不是完美的1.0。实操心得不要盲目追求1.0分尤其是“事实一致性”LLM作为评估者本身也有局限性过于严苛的评估可能导致分数失真。内置反馈函数是一个强大的基线但它给出的绝对分数值其意义需要在你的特定数据集上经过多次评估后通过分布和趋势来理解。比如你可以先跑100个问题看看平均分和分数分布建立一个基准线。后续的优化只要能让分数分布整体上移就是有效的。5. 高级实战打造你的自定义评估指标现在进入最激动人心的部分——自定义指标。我们将针对一个具体的业务场景设计并实现两个自定义反馈函数。假设场景我们构建了一个“技术面试题解答RAG”从公司内部技术文档中检索信息来回答面试问题。对于这个场景一个好的答案不仅需要正确还应该结构化清晰最好能分点论述方便面试官阅读。包含关键术语答案中应出现文档里提到的核心技术术语以体现专业性。5.1 自定义指标一答案结构化程度评估这个指标我们希望评估答案是否采用了分点如1、2、3或•或分段等清晰的结构。from trulens_eval import Feedback, Select import re def check_answer_structure(answer: str) - float: 一个简单的规则函数检查答案的结构化程度。 规则 1. 包含数字序号列表如1. 2. 3.或项目符号如 -, *, •。 2. 或者有明显的分段如包含‘首先’、‘其次’、‘最后’等连接词。 返回一个0或1的分数。 # 规则1检查数字序号或项目符号 pattern_list re.compile(r(\d\.\s|\-\s|\*\s|\•\s)) # 规则2检查常见结构化连接词 pattern_connective re.compile(r(首先|其次|然后|接着|最后|第一|第二|第三)) if pattern_list.search(answer) or pattern_connective.search(answer): return 1.0 # 具备较好结构 else: return 0.0 # 结构不清晰 # 将规则函数包装成TruLens的Feedback函数 # 注意这里我们使用 Feedback 的 on_output() 方法因为它只依赖于答案本身。 f_structure Feedback( check_answer_structure, # 我们的自定义函数 name答案结构化程度 # 指标名称 ).on_output() # 指定这个反馈函数作用于链的输出即答案代码解析我们定义了一个纯Python函数check_answer_structure它接收一个字符串answer通过正则表达式匹配来判断其是否结构化。然后我们使用Feedback类将这个函数“包装”起来。name参数定义了在仪表盘里显示的名称。.on_output()告诉TruLens当需要计算这个反馈时把当前这次调用的“输出”即生成的答案传给我们的自定义函数。这是一个基于规则的自定义指标。它的优点是速度快、成本为零、完全确定。缺点是可能不够智能比如答案用了“其一、其二”这种模式我们的正则可能就漏掉了。但对于明确要求“分点回答”的场景它简单有效。5.2 自定义指标二关键术语覆盖度评估使用LLM上一个指标是规则现在我们来一个更智能的——使用LLM来判断。我们希望评估“答案是否涵盖了上下文中最重要的技术术语”。这需要LLM的理解能力。from trulens_eval import Feedback from trulens_eval.feedback.provider.openai import OpenAI as TruLensOpenAI provider TruLensOpenAI() # 复用之前的provider def key_terms_coverage_instruction(context: str, answer: str) - str: 构建一个Prompt指导LLM评估关键术语覆盖度。 这个函数返回的是给LLM的指令字符串。 instruction f 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请按以下步骤思考你的思考过程将用于评分 1. 从上下文中提取出3-5个最核心的技术术语或关键概念。 2. 检查答案中是否明确提及或清晰地解释了这些术语/概念。 3. 根据覆盖比例给出一个0到1之间的分数1分表示完全覆盖0分表示完全没有覆盖。 请只输出一个浮点数分数不要输出任何其他文字。 return instruction # 使用provider的generate_score_and_reasons方法。 # 这个方法会发送我们构建的instruction给LLM并解析出分数。 f_key_terms Feedback( provider.generate_score_and_reasons, # 使用provider的通用评分方法 name关键术语覆盖度 ).on_default().on_output() # 依赖于上下文和答案 # 注意这里我们通过.on_default().on_output()将context和answer都传给反馈函数。 # 但在函数内部我们需要通过TruLens的“选择器(Select)”来正确绑定参数。上面的写法在概念上是正确的但直接这样写TruLens不知道如何将context和answer映射到key_terms_coverage_instruction函数的参数上。我们需要使用TruLens的Select和Feedback的链式定义来精确绑定。from trulens_eval import Select, Feedback # 正确写法使用 Select 来指定数据流 f_key_terms Feedback( provider.generate_score_and_reasons, # 使用LLM评分的函数 name关键术语覆盖度 ).on( # 这里构建一个字典作为参数传给 provider.generate_score_and_reasons # provider.generate_score_and_reasons 期望一个 prompt 参数 prompt # 我们将一个字符串模板和Select对象结合 # Select.RecordInput 是用户的问题这里我们用不到但可以作为prompt的一部分 # Select.RecordCalls 是捕获的链的调用步骤。我们需要找到存储“上下文”的那一步。 # 在我们的链中检索器检索到的内容被放在了 context 变量中。 # TruLens 会将其记录在 app - retriever 调用的输出里。 # 更通用的方法是使用 Select.RecordCalls.retriever 的返回值。 # 但更简单直接的方式是利用 .on_default() 的默认行为。 # 实际上对于这种需要复杂Prompt构造的情况更推荐使用下面的“模板反馈函数”方法。 )鉴于直接绑定复杂参数有些棘手TruLens提供了更优雅的“模板反馈函数”方式这也是官方推荐的做法。# 方法二使用带f-string的Feedback定义更清晰 # 我们直接定义一个字符串模板其中用 {...} 预留位置TruLens会自动填充。 f_key_terms_template ( Feedback(provider.generate_score_and_reasons, name关键术语覆盖度) .on( prompt 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请按以下步骤思考你的思考过程将用于评分 1. 从上下文中提取出3-5个最核心的技术术语或关键概念。 2. 检查答案中是否明确提及或清晰地解释了这些术语/概念。 3. 根据覆盖比例给出一个0到1之间的分数1分表示完全覆盖0分表示完全没有覆盖。 请只输出一个浮点数分数不要输出任何其他文字。 ) # 使用 Select 来指定模板中 {context} 和 {answer} 应该用什么数据填充 .on_input_output( # on_input_output 提供了 input 和 output 的快捷方式但我们需要context ) ) # 注意上面的写法仍然有问题因为 on_input_output 不能直接解构出context。 # 正确且推荐的方法使用 Select 来精确映射 from trulens_eval import Select f_key_terms_correct Feedback( provider.generate_score_and_reasons, name关键术语覆盖度 ).on_prompt( # 构建Prompt模板字符串 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请只输出一个0到1之间的浮点数分数代表关键术语的覆盖比例。 ).on_input( # 映射 {answer} 到 链的输入不对答案应该是输出。 # 我们需要重新思考generate_score_and_reasons 接收一个 prompt 参数。 # 而 on_prompt 已经将上面的字符串定义为了prompt模板。 # 现在需要告诉TruLens模板里的变量从哪里来。 )经过实践最清晰可靠的自定义LLM反馈函数写法如下# 最终正确的自定义LLM反馈函数写法 def key_terms_coverage_prompt(context: str, answer: str) - str: 构建评估Prompt的函数 return f 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请只输出一个0到1之间的浮点数分数代表关键术语的覆盖比例。不要输出任何其他文字。 # 定义反馈函数并明确指定其参数来源 f_key_terms_final Feedback( provider.generate_score_and_reasons, # 基础LLM评分函数 name关键术语覆盖度 ).on( # 将 key_terms_coverage_prompt 函数的返回值作为参数传递给 provider.generate_score_and_reasons # 而 key_terms_coverage_prompt 需要两个参数context 和 answer # 我们使用 Select 对象来指定这两个参数的来源 prompt key_terms_coverage_prompt( contextSelect.RecordCalls.retriever.rets[0], # 假设检索器返回的第一个片段作为上下文 answerSelect.RecordOutput, # 链的最终输出作为答案 ) )重要提示Select.RecordCalls.retriever.rets[0]这个路径取决于你的链的具体结构。如果检索器返回多个文档片段rets是一个列表。对于更复杂的链你可能需要在TruLens仪表盘中先查看一次运行的“记录详情”找到上下文数据的确切路径。这是自定义反馈函数中最容易出错的地方。由于路径选择器可能比较繁琐对于快速验证我们可以采用一个更简单但功能稍弱的方法在Prompt中直接引用变量名并依赖TruLens的默认映射。但这种方法要求变量名在链中是固定的且TruLens能识别。5.3 整合自定义指标并运行评估为了简化演示我们暂时使用第一个基于规则的结构化评估函数f_structure以及内置的f_qa_relevance和f_groundedness来展示如何整合。# 重新包装我们的RAG链这次加入自定义的结构化评估指标 tru_rag_chain_custom TruChain( rag_chain, app_idMy_RAG_App_Custom_v1, feedbacks[f_qa_relevance, f_groundedness, f_structure] # 加入自定义指标 ) # 运行几个测试问题 test_questions [ 请解释一下什么是过拟合, 机器学习的两个主要类型是什么, 深度学习使用了什么模型 ] for q in test_questions: print(f\n评估问题{q}) response tru_rag_chain_custom.invoke(q) print(f生成答案{response[:100]}...) # 打印前100字符 # 注意反馈是异步计算的不会立即打印在控制台。 # 我们需要去仪表盘查看结果。 # 启动仪表盘查看详细评估结果 tru.run_dashboard()在TruLens仪表盘中你现在应该能看到三条记录每条记录都有三个反馈分数“答案相关性”、“事实一致性”和“答案结构化程度”。你可以点击每条记录查看每个反馈函数打分的详细理由对于内置的LLM反馈或结果。6. 评估结果分析与迭代优化收集了评估数据后真正的价值在于分析。TruLens仪表盘提供了丰富的可视化功能但核心是看懂数据并指导行动。6.1 如何解读评估结果不要只看单个分数要从多个维度进行聚合分析整体表现在仪表盘的“Dashboard”视图你可以看到所有反馈函数的平均分、分数分布直方图。这让你对应用的总体健康度有个把握。比如如果“事实一致性”平均分只有0.6那说明幻觉问题严重是首要优化目标。相关性分析观察不同指标间的相关性。例如是否“上下文相关性”低的记录其“事实一致性”也普遍低这很可能意味着检索质量是瓶颈你需要优化检索器如调整嵌入模型、改进分块策略、增加检索数量k。案例深挖点击低分记录尤其是关键指标如一致性得0分的记录仔细查看问题是什么检索到的上下文是什么是否相关生成的答案哪里出错了是模型胡编乱造还是上下文本身信息不足评估理由是什么LLM评估器指出具体哪句话没有依据6.2 基于评估的优化方向根据分析结果你可以有针对性地进行迭代如果“答案相关性”低问题可能出在提示工程或LLM本身。检查你的系统提示词是否清晰是否要求模型“严格基于上下文回答”可以尝试改进提示词加入更严格的约束比如“如果上下文没有明确信息请回答‘我不知道’”。如果“上下文相关性”低这是检索系统的问题。优化方向包括分块策略调整chunk_size和chunk_overlap。太大的块可能包含无关信息太小的块可能割裂语义。检索策略尝试不同的检索方法如MMR最大边际相关性在保证相关性的同时增加多样性或调整search_kwargs中的k返回的文档数量。嵌入模型升级到更强大的嵌入模型如text-embedding-3-large。元数据过滤如果文档有来源、章节等元数据可以在检索时加入过滤条件。如果“事实一致性”低这通常是RAG最棘手的问题。除了优化检索确保喂给模型的上下文是相关的和提示工程还可以考虑后处理在答案生成后增加一个“一致性校验”步骤让另一个LLM判断答案是否忠于上下文如果不忠则触发重答或标记。提示工程强化在提示词中多次、强调性地要求模型“只使用提供的信息”“不要添加任何已知信息之外的内容”。如果“自定义指标”分数低这直接反映了你的业务需求未满足。例如“结构化程度”低你可以在提示词中明确要求“请分点列出”“关键术语覆盖度”低可以尝试在检索后增加一个步骤从上下文中提取关键术语并强制要求模型在答案中提及它们。6.3 建立评估基准与持续监控一次性的评估意义有限。你应该建立一个评估基准数据集——一组涵盖各种类型、难度的问题及其“标准答案”或“期望属性”。定期例如每次更新检索策略或提示词后用这个数据集跑一遍评估对比关键指标的变化。TruLens允许你为同一个应用设置不同的app_id如My_RAG_App_v1_prompt1,My_RAG_App_v1_prompt2这样就可以在仪表盘中直观对比不同版本应用的表现。这构成了一个简单的A/B测试框架。最终将RAG评估集成到你的开发流水线中使其成为每次代码提交或模型更新后的一个自动化测试环节才能真正实现数据驱动的、可持续的RAG应用优化。7. 避坑指南与进阶技巧在实战中我踩过不少坑也总结出一些能大幅提升效率的技巧。7.1 常见问题与排查反馈函数不执行或分数为None原因最常见的是Select路径设置错误导致反馈函数获取不到所需的数据如context。排查在TruLens仪表盘打开一条记录的详情查看“Record”部分展开app-calls找到你的链的每一步输入输出。确认你试图访问的数据如检索器的输出的确切路径。然后修正Select语句。评估速度慢/成本高原因每个反馈函数尤其是调用LLM的如内置的相关性、一致性都会产生额外的API调用和耗时。优化批量评估不要在生产环境中为每次用户查询都运行全套评估。评估主要用于离线测试和迭代优化。可以使用tru_rag_chain.invoke的批量方式或者用Tru的run方法处理一批问题。采样评估在线上环境可以只对一小部分查询如1%进行抽样评估监控质量趋势。使用轻量级模型对于自定义的LLM反馈如果不需要极强推理能力可以考虑使用更小、更快的模型如gpt-3.5-turbo而不是gpt-4。自定义规则函数评分不准原因规则过于简单或存在漏洞。优化结合规则和LLM。例如先用规则过滤出明显结构化差的答案得0分对于规则判断模糊的再送入LLM进行精细评分。这样可以平衡成本和效果。7.2 进阶技巧组合反馈函数你可以将多个基础反馈函数的分数通过加权平均等方式组合成一个“综合分”。TruLens的Feedback机制本身支持算术运算。例如f_overall 0.4 * f_qa_relevance 0.4 * f_groundedness 0.2 * f_structure这样在仪表盘里你就能看到一个代表整体质量的单一指标。利用评估理由进行根因分析内置的LLM反馈函数带有_with_cot_reasons后缀的会输出详细的思考链。不要只看分数一定要读这些理由。它们往往是发现系统弱点的金矿。你可以批量导出这些理由做文本分析找出高频出现的错误模式。追踪上下文质量除了评估最终答案强烈建议增加一个直接评估“检索到的上下文”与“问题”相关性的反馈函数。这能帮你把检索问题和生成问题剥离开定位更精准。TruLens内置的context_relevance_with_cot_reasons就是干这个的。长期追踪与告警将TruLens的数据库默认是default.sqlite连接到你的数据看板如Grafana或者定期导出数据进行分析。可以设置一些阈值告警比如当“事实一致性”的7日滚动平均分下降超过10%时自动触发通知提醒团队检查。RAG评估不是一次性的任务而是一个伴随应用整个生命周期的持续过程。从用TruLens搭建起自动化的评估流水线开始你就拥有了优化RAG应用的“指南针”和“仪表盘”。它不能替你开车但能告诉你路在何方以及当前车速如何。记住没有度量就没有改进。现在就去为你自己的RAG应用装上这套科学的评估系统吧。
1. 项目概述为什么RAG评估不是“差不多就行”如果你最近在折腾RAG检索增强生成应用肯定有过这样的体验模型有时候回答得头头是道引经据典有时候又像喝醉了酒开始胡言乱语甚至“捏造”一些根本不存在的文档内容。你改改提示词调调检索参数感觉好像好了一点但又说不出具体好了多少。这种“凭感觉”的优化就像蒙着眼睛开车方向对不对全看运气。这就是我们今天要解决的问题。RAG评估说白了就是给你的AI应用装上一套“仪表盘”和“质检仪”。它不能帮你直接造车构建应用但能告诉你车的速度、油耗、以及哪个零件可能有问题。没有评估的RAG优化无异于盲人摸象。而“LangChain 30天保姆级教程”进行到第26天终于要直面这个最核心、也最容易被忽视的环节——如何科学地、量化地评估你的RAG系统。传统的评估方法比如人工一条条看回答或者简单计算一下检索文档和生成答案的字面匹配度在真实场景下基本是失效的。人工评估成本高、速度慢、主观性强字面匹配则完全无法应对语义层面的问题比如“苹果公司”和“水果苹果”虽然都有“苹果”但天差地别。因此我们需要一套更智能、更自动化的评估体系。这就是TruLens这类工具的价值所在。它不是一个简单的打分器而是一个评估框架允许你定义和组合多种维度的指标从“事实一致性”到“回答相关性”再到“信息冗余度”全方位地为你的RAG回答做“体检”。这次实战的目标很明确我们将手把手带你搭建一个完整的RAG评估流水线。不仅仅是调用现成的评估函数更重要的是我们会深入“自定义指标”这个核心环节。因为你的业务场景是独一无二的——一个法律咨询RAG和一个客服问答RAG它们的“好答案”标准肯定不同。我们将学习如何根据你的特定需求定义属于你自己的“黄金标准”并用代码将其实现让评估真正为你的业务目标服务。2. 评估体系设计从通用指标到自定义战场在开始写代码之前我们必须先把评估的“考纲”定下来。胡乱评估一通得到一堆数字除了自我安慰没有任何意义。一个科学的RAG评估体系通常围绕三个核心维度展开答案相关性、上下文相关性和事实一致性。TruLens将其抽象为Relevance、Context Relevance和Groundness但这只是起点。2.1 理解三大基础评估维度答案相关性生成的答案是否直接、有效地回答了用户提出的问题这是最根本的要求。例如用户问“如何更换汽车轮胎”答案却在大谈轮胎的发展历史这就是不相关。评估这个维度通常需要一个大语言模型作为“裁判”来判断问题和答案之间的语义匹配程度。上下文相关性我们检索出来并喂给大模型的“上下文”即那些文档片段它们本身是否与用户问题高度相关如果检索系统不给力塞给模型一堆无关文档那模型再厉害也是“巧妇难为无米之炊”甚至可能被无关信息带偏。这个指标评估的是检索环节的质量。事实一致性这是RAG的“生命线”。生成的答案中的事实性陈述是否严格来源于提供的上下文有没有“幻觉”即模型自己编造例如上下文只说“某产品支持A和B功能”但模型回答时却加上了“还即将推出C功能”这就是严重的事实不一致。这个指标要求模型能逐条核对答案中的主张是否在上下文中有所依据。TruLens提供了这些基础指标的实现开箱即用。但真实世界远比这复杂。2.2 为何必须引入自定义指标因为通用指标解决不了你的特殊问题。我举个例子你就明白了场景一技术文档问答你的RAG用于查询某个软件框架的API。这时候“答案的准确性”可能比“语言的流畅性”重要一万倍。一个磕磕巴巴但参数完全正确的答案远胜于一个流利但参数说错的答案。你可能需要定义一个“关键参数准确率”的指标。场景二创意写作辅助你的RAG用来根据用户提供的关键词生成故事片段。此时“事实一致性”可能没那么关键但“风格符合度”比如是否保持了悬疑风格和“创意新颖性”就至关重要。场景三合规审查你的RAG用来检查合同条款是否合规。那么“风险条款覆盖率”和“违规引用精确度”就是核心指标。你需要评估模型是否找全了所有风险点并且指出的具体条款位置是否准确。你看这些需求都无法直接用“相关性”或“一致性”来涵盖。自定义指标就是将你的业务逻辑翻译成评估模型能理解的“数学语言”的过程。2.3 设计自定义指标的四步法设计一个有效的自定义指标可以遵循以下四个步骤这比直接写代码更重要明确业务目标抛开技术先想清楚“什么样的回答对我的用户来说才是好回答”用自然语言描述出来比如“答案必须包含至少三个具体的操作步骤”、“不能出现任何主观臆测的词语”等。指标量化将自然语言描述转化为可量化的维度。例如“包含操作步骤”可以量化为“答案中枚举或列表项的数量”“无主观臆测”可以转化为“检测答案中是否出现‘可能’、‘我觉得’、‘应该’等特定词汇”。选择实现工具思考用什么技术来实现这个量化。简单的可以用正则表达式匹配关键词复杂的可能需要调用另一个LLM进行判断或者使用专门的NLP模型如情感分析模型来判断语气。定义评分规则确定如何将量化的结果映射到一个分数上比如0到1分。是布尔判断符合1不符合0还是阶梯式评分找到1个风险点得0.3找到3个以上得1或者是连续函数遵循这个思路你的自定义指标才能真正驱动优化而不是为了评估而评估。3. 环境搭建与TruLens核心概念解析工欲善其事必先利其器。在开始评估实战前我们需要把环境和核心概念理清楚。这一部分我会详细说明每一步的选择理由帮你避开初期配置的坑。3.1 依赖安装与版本管理首先创建一个干净的Python虚拟环境是绝对的好习惯它能避免包版本冲突这个“幽灵问题”。这里我推荐使用conda或venv。# 使用 conda conda create -n rag-eval python3.10 conda activate rag-eval # 或使用 venv python -m venv rag-eval source rag-eval/bin/activate # Linux/Mac # rag-eval\Scripts\activate # Windows接下来安装核心依赖。请注意LangChain和TruLens的生态更迭较快指定版本能最大程度保证本次教程的复现性。pip install langchain0.1.0 openai1.12.0 trulens-eval0.19.2 chromadb0.4.22 tiktokenlangchain我们构建基础RAG链的框架。选择0.1.0这个相对稳定的版本。openai用于调用GPT模型作为生成和评估的“大脑”。你需要准备好自己的OpenAI API密钥。trulens-eval今天的主角评估框架。chromadb一个轻量级向量数据库用于存储和检索我们的文档。选择它是因为简单易用适合演示。tiktokenOpenAI的分词器用于精确计算token数量管理成本。注意trulens-eval在安装时可能会依赖一些系统库如build-essential。如果在Linux环境下遇到编译错误通常需要安装python3-dev等包。例如在Ubuntu上可以运行sudo apt-get install python3-dev。3.2 TruLens 核心三要素App、Feedback Function 和 TruChainTruLens的架构非常清晰围绕三个核心概念构建理解它们就理解了整个评估流程App这就是你要评估的对象——你的RAG应用。在TruLens眼里你的应用就是一个接收输入用户问题并产生输出答案和中间上下文的黑盒。TruLens会通过“插桩”技术在应用运行时自动捕获这些输入、输出以及中间状态比如检索到的文档。Feedback Function反馈函数这就是具体的“评分标准”。每一个评估维度如相关性、一致性都对应一个反馈函数。它接收从App中捕获的数据如问题、答案、上下文经过计算可能调用LLM也可能用规则输出一个0到1之间的分数。TruLens内置了一些而我们主要攻克的就是如何创建自定义的反馈函数。TruChain这是连接App和Feedback Function的“桥梁”。你可以把它理解为App的一个“监控器”或“装饰器”。你用TruChain包裹住你的LangChain应用并告诉它需要运行哪些反馈函数进行评估。之后每次调用这个被包裹的链TruLens都会自动执行评估并将结果记录到数据库默认是本地SQLite中。这个设计的好处是非侵入性。你几乎不需要修改原有的应用代码只需要用TruChain把它包起来并配置好评估函数所有的记录、评估、存储就都自动完成了。这为后续的分析和迭代提供了极大的便利。3.3 初始化关键组件LLM与向量库在写评估代码前我们先搭建一个最简单的RAG应用作为评估靶子。这里会涉及一些LangChain的基础操作。import os from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 设置你的OpenAI API密钥请务必妥善保管不要提交到代码仓库 os.environ[OPENAI_API_KEY] 你的-api-key-here # 2. 初始化模型 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 评估时建议temperature0减少随机性 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 用于文档向量化 # 3. 准备文档并存入向量库 # 假设我们有一些关于“机器学习”的文档 documents [ 机器学习是人工智能的一个分支它使计算机能够在没有明确编程的情况下学习。, 监督学习需要使用带有标签的数据集进行训练例如分类和回归任务。, 无监督学习用于发现未标记数据中的模式例如聚类和降维。, 深度学习是机器学习的一个子领域它使用神经网络特别是深度神经网络。, 过拟合是指模型在训练数据上表现太好以至于无法泛化到新数据。 ] # 分割文档以适应模型的上下文窗口 text_splitter RecursiveCharacterTextSplitter(chunk_size200, chunk_overlap50) texts text_splitter.create_documents(documents) # 创建向量存储 vectorstore Chroma.from_documents(documentstexts, embeddingembeddings) retriever vectorstore.as_retriever(search_kwargs{k: 2}) # 每次检索2个片段 # 4. 构建一个简单的RAG链 prompt_template 请根据以下上下文来回答问题。如果你不知道答案就说你不知道不要编造信息。 上下文 {context} 问题 {question} 请用中文给出答案 prompt ChatPromptTemplate.from_template(prompt_template) # 定义链检索 - 组合上下文 - 提示 - LLM生成 - 解析字符串 rag_chain ( {context: retriever, question: RunnablePassthrough()} | prompt | llm | StrOutputParser() )现在我们有了一个可以运行的RAG应用rag_chain。你可以用rag_chain.invoke(“什么是监督学习”)来测试它。接下来我们将用TruLens为它装上“评估引擎”。4. 基础评估实战使用TruLens内置反馈函数让我们先感受一下TruLens内置评估能力的便利性。我们将评估上面构建的RAG链在“答案相关性”和“事实一致性”两个通用维度上的表现。4.1 初始化TruLens并连接应用首先我们需要从TruLens导入核心类并创建一个“记录器”。这个记录器负责管理所有的评估运行。from trulens_eval import TruChain, Feedback, Tru from trulens_eval.feedback import Groundedness from trulens_eval.feedback.provider.openai import OpenAI as TruLensOpenAI # 初始化TruLens默认会在当前目录创建数据库文件 tru Tru() # 使用TruLens封装的OpenAI provider来创建反馈函数 # 注意这里用的是 TruLensOpenAI它内部会处理与评估相关的prompt工程 provider TruLensOpenAI() # 定义内置的反馈函数 # 1. 答案相关性评估答案对问题的回应程度 f_qa_relevance Feedback(provider.relevance_with_cot_reasons, name答案相关性).on_input_output() # on_input_output() 表示这个反馈函数将接收链的输入问题和输出答案作为参数 # 2. 事实一致性基于上下文的真实性评估答案是否基于提供的上下文 grounded Groundedness(groundedness_providerprovider) f_groundedness Feedback(grounded.groundedness_measure_with_cot_reasons, name事实一致性).on_input().on_output().on_default() # 这里比较复杂 # .on_input(): 提供“问题” # .on_output(): 提供“答案” # .on_default(): 提供“上下文”这是TruChain自动从检索器捕获的中间状态 # 这个链式调用定义了反馈函数的数据来源。这里有个关键点on_default()。在TruLens中当你用TruChain包装一个LangChain应用时它会自动尝试捕获链中名为“context”的中间步骤输出。我们的RAG链里retriever检索出的内容正好被赋值给了context变量所以TruLens能自动抓取到它。如果你的上下文变量名不是context你需要使用.on(“你的变量名”)来明确指定。4.2 包装RAG链并运行首次评估现在我们用TruChain把我们的应用和反馈函数“绑”在一起。# 使用 TruChain 包装原始的 rag_chain并指定要使用的反馈函数 tru_rag_chain TruChain( rag_chain, app_idMy_RAG_App_v1, # 给应用起个名字方便后续在仪表盘区分 feedbacks[f_qa_relevance, f_groundedness] # 传入我们定义的两个反馈函数 ) # 运行一次评估 question 机器学习和深度学习是什么关系 response tru_rag_chain.invoke(question) print(f问题{question}) print(f答案{response})运行这段代码会发生几件事tru_rag_chain.invoke()会先执行你原有的RAG链得到答案。同时TruLens在后台自动捕获了输入问题、输出答案和上下文。然后它异步调用你定义的两个反馈函数f_qa_relevance和f_groundedness分别对这次交互进行评估。评估结果分数和原因会被自动保存到本地的SQLite数据库中。此时控制台可能不会立即打印出分数因为评估是异步的。分数被记录到了数据库。我们可以运行一个简单的命令来启动TruLens的本地仪表盘查看结果。# 在Jupyter Notebook中可以直接运行 tru.run_dashboard() # 如果是脚本运行后默认会在浏览器打开 http://localhost:8501在仪表盘中你可以看到每一次调用Record的详细信息包括输入、输出、上下文以及两个反馈函数的打分0到1之间和详细的评估理由LLM给出的判断原因。这已经比人工评估强大太多了4.3 解读首次评估结果与常见陷阱打开仪表盘你可能会看到“答案相关性”得分很高比如0.9但“事实一致性”得分可能只有0.7或更低。我们来看看为什么。高相关性因为我们的问题明确上下文也包含了“深度学习是机器学习的一个子领域”这句话所以LLM很容易给出一个高度相关的答案。一致性扣分LLM评估“事实一致性”时会逐句检查生成答案中的事实主张是否能在提供的上下文中找到支持。有时生成答案会进行一些合理的推论或换一种说法表述如果上下文没有完全相同的表述严格的评估器可能会扣分。例如答案说“深度学习属于机器学习”上下文是“深度学习是机器学习的一个子领域”这本质一致但措辞不同可能导致分数不是完美的1.0。实操心得不要盲目追求1.0分尤其是“事实一致性”LLM作为评估者本身也有局限性过于严苛的评估可能导致分数失真。内置反馈函数是一个强大的基线但它给出的绝对分数值其意义需要在你的特定数据集上经过多次评估后通过分布和趋势来理解。比如你可以先跑100个问题看看平均分和分数分布建立一个基准线。后续的优化只要能让分数分布整体上移就是有效的。5. 高级实战打造你的自定义评估指标现在进入最激动人心的部分——自定义指标。我们将针对一个具体的业务场景设计并实现两个自定义反馈函数。假设场景我们构建了一个“技术面试题解答RAG”从公司内部技术文档中检索信息来回答面试问题。对于这个场景一个好的答案不仅需要正确还应该结构化清晰最好能分点论述方便面试官阅读。包含关键术语答案中应出现文档里提到的核心技术术语以体现专业性。5.1 自定义指标一答案结构化程度评估这个指标我们希望评估答案是否采用了分点如1、2、3或•或分段等清晰的结构。from trulens_eval import Feedback, Select import re def check_answer_structure(answer: str) - float: 一个简单的规则函数检查答案的结构化程度。 规则 1. 包含数字序号列表如1. 2. 3.或项目符号如 -, *, •。 2. 或者有明显的分段如包含‘首先’、‘其次’、‘最后’等连接词。 返回一个0或1的分数。 # 规则1检查数字序号或项目符号 pattern_list re.compile(r(\d\.\s|\-\s|\*\s|\•\s)) # 规则2检查常见结构化连接词 pattern_connective re.compile(r(首先|其次|然后|接着|最后|第一|第二|第三)) if pattern_list.search(answer) or pattern_connective.search(answer): return 1.0 # 具备较好结构 else: return 0.0 # 结构不清晰 # 将规则函数包装成TruLens的Feedback函数 # 注意这里我们使用 Feedback 的 on_output() 方法因为它只依赖于答案本身。 f_structure Feedback( check_answer_structure, # 我们的自定义函数 name答案结构化程度 # 指标名称 ).on_output() # 指定这个反馈函数作用于链的输出即答案代码解析我们定义了一个纯Python函数check_answer_structure它接收一个字符串answer通过正则表达式匹配来判断其是否结构化。然后我们使用Feedback类将这个函数“包装”起来。name参数定义了在仪表盘里显示的名称。.on_output()告诉TruLens当需要计算这个反馈时把当前这次调用的“输出”即生成的答案传给我们的自定义函数。这是一个基于规则的自定义指标。它的优点是速度快、成本为零、完全确定。缺点是可能不够智能比如答案用了“其一、其二”这种模式我们的正则可能就漏掉了。但对于明确要求“分点回答”的场景它简单有效。5.2 自定义指标二关键术语覆盖度评估使用LLM上一个指标是规则现在我们来一个更智能的——使用LLM来判断。我们希望评估“答案是否涵盖了上下文中最重要的技术术语”。这需要LLM的理解能力。from trulens_eval import Feedback from trulens_eval.feedback.provider.openai import OpenAI as TruLensOpenAI provider TruLensOpenAI() # 复用之前的provider def key_terms_coverage_instruction(context: str, answer: str) - str: 构建一个Prompt指导LLM评估关键术语覆盖度。 这个函数返回的是给LLM的指令字符串。 instruction f 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请按以下步骤思考你的思考过程将用于评分 1. 从上下文中提取出3-5个最核心的技术术语或关键概念。 2. 检查答案中是否明确提及或清晰地解释了这些术语/概念。 3. 根据覆盖比例给出一个0到1之间的分数1分表示完全覆盖0分表示完全没有覆盖。 请只输出一个浮点数分数不要输出任何其他文字。 return instruction # 使用provider的generate_score_and_reasons方法。 # 这个方法会发送我们构建的instruction给LLM并解析出分数。 f_key_terms Feedback( provider.generate_score_and_reasons, # 使用provider的通用评分方法 name关键术语覆盖度 ).on_default().on_output() # 依赖于上下文和答案 # 注意这里我们通过.on_default().on_output()将context和answer都传给反馈函数。 # 但在函数内部我们需要通过TruLens的“选择器(Select)”来正确绑定参数。上面的写法在概念上是正确的但直接这样写TruLens不知道如何将context和answer映射到key_terms_coverage_instruction函数的参数上。我们需要使用TruLens的Select和Feedback的链式定义来精确绑定。from trulens_eval import Select, Feedback # 正确写法使用 Select 来指定数据流 f_key_terms Feedback( provider.generate_score_and_reasons, # 使用LLM评分的函数 name关键术语覆盖度 ).on( # 这里构建一个字典作为参数传给 provider.generate_score_and_reasons # provider.generate_score_and_reasons 期望一个 prompt 参数 prompt # 我们将一个字符串模板和Select对象结合 # Select.RecordInput 是用户的问题这里我们用不到但可以作为prompt的一部分 # Select.RecordCalls 是捕获的链的调用步骤。我们需要找到存储“上下文”的那一步。 # 在我们的链中检索器检索到的内容被放在了 context 变量中。 # TruLens 会将其记录在 app - retriever 调用的输出里。 # 更通用的方法是使用 Select.RecordCalls.retriever 的返回值。 # 但更简单直接的方式是利用 .on_default() 的默认行为。 # 实际上对于这种需要复杂Prompt构造的情况更推荐使用下面的“模板反馈函数”方法。 )鉴于直接绑定复杂参数有些棘手TruLens提供了更优雅的“模板反馈函数”方式这也是官方推荐的做法。# 方法二使用带f-string的Feedback定义更清晰 # 我们直接定义一个字符串模板其中用 {...} 预留位置TruLens会自动填充。 f_key_terms_template ( Feedback(provider.generate_score_and_reasons, name关键术语覆盖度) .on( prompt 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请按以下步骤思考你的思考过程将用于评分 1. 从上下文中提取出3-5个最核心的技术术语或关键概念。 2. 检查答案中是否明确提及或清晰地解释了这些术语/概念。 3. 根据覆盖比例给出一个0到1之间的分数1分表示完全覆盖0分表示完全没有覆盖。 请只输出一个浮点数分数不要输出任何其他文字。 ) # 使用 Select 来指定模板中 {context} 和 {answer} 应该用什么数据填充 .on_input_output( # on_input_output 提供了 input 和 output 的快捷方式但我们需要context ) ) # 注意上面的写法仍然有问题因为 on_input_output 不能直接解构出context。 # 正确且推荐的方法使用 Select 来精确映射 from trulens_eval import Select f_key_terms_correct Feedback( provider.generate_score_and_reasons, name关键术语覆盖度 ).on_prompt( # 构建Prompt模板字符串 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请只输出一个0到1之间的浮点数分数代表关键术语的覆盖比例。 ).on_input( # 映射 {answer} 到 链的输入不对答案应该是输出。 # 我们需要重新思考generate_score_and_reasons 接收一个 prompt 参数。 # 而 on_prompt 已经将上面的字符串定义为了prompt模板。 # 现在需要告诉TruLens模板里的变量从哪里来。 )经过实践最清晰可靠的自定义LLM反馈函数写法如下# 最终正确的自定义LLM反馈函数写法 def key_terms_coverage_prompt(context: str, answer: str) - str: 构建评估Prompt的函数 return f 你是一个技术评估专家。请根据提供的“上下文”评估“答案”是否涵盖了上下文中最核心、最相关的技术术语。 上下文 {context} 答案 {answer} 请只输出一个0到1之间的浮点数分数代表关键术语的覆盖比例。不要输出任何其他文字。 # 定义反馈函数并明确指定其参数来源 f_key_terms_final Feedback( provider.generate_score_and_reasons, # 基础LLM评分函数 name关键术语覆盖度 ).on( # 将 key_terms_coverage_prompt 函数的返回值作为参数传递给 provider.generate_score_and_reasons # 而 key_terms_coverage_prompt 需要两个参数context 和 answer # 我们使用 Select 对象来指定这两个参数的来源 prompt key_terms_coverage_prompt( contextSelect.RecordCalls.retriever.rets[0], # 假设检索器返回的第一个片段作为上下文 answerSelect.RecordOutput, # 链的最终输出作为答案 ) )重要提示Select.RecordCalls.retriever.rets[0]这个路径取决于你的链的具体结构。如果检索器返回多个文档片段rets是一个列表。对于更复杂的链你可能需要在TruLens仪表盘中先查看一次运行的“记录详情”找到上下文数据的确切路径。这是自定义反馈函数中最容易出错的地方。由于路径选择器可能比较繁琐对于快速验证我们可以采用一个更简单但功能稍弱的方法在Prompt中直接引用变量名并依赖TruLens的默认映射。但这种方法要求变量名在链中是固定的且TruLens能识别。5.3 整合自定义指标并运行评估为了简化演示我们暂时使用第一个基于规则的结构化评估函数f_structure以及内置的f_qa_relevance和f_groundedness来展示如何整合。# 重新包装我们的RAG链这次加入自定义的结构化评估指标 tru_rag_chain_custom TruChain( rag_chain, app_idMy_RAG_App_Custom_v1, feedbacks[f_qa_relevance, f_groundedness, f_structure] # 加入自定义指标 ) # 运行几个测试问题 test_questions [ 请解释一下什么是过拟合, 机器学习的两个主要类型是什么, 深度学习使用了什么模型 ] for q in test_questions: print(f\n评估问题{q}) response tru_rag_chain_custom.invoke(q) print(f生成答案{response[:100]}...) # 打印前100字符 # 注意反馈是异步计算的不会立即打印在控制台。 # 我们需要去仪表盘查看结果。 # 启动仪表盘查看详细评估结果 tru.run_dashboard()在TruLens仪表盘中你现在应该能看到三条记录每条记录都有三个反馈分数“答案相关性”、“事实一致性”和“答案结构化程度”。你可以点击每条记录查看每个反馈函数打分的详细理由对于内置的LLM反馈或结果。6. 评估结果分析与迭代优化收集了评估数据后真正的价值在于分析。TruLens仪表盘提供了丰富的可视化功能但核心是看懂数据并指导行动。6.1 如何解读评估结果不要只看单个分数要从多个维度进行聚合分析整体表现在仪表盘的“Dashboard”视图你可以看到所有反馈函数的平均分、分数分布直方图。这让你对应用的总体健康度有个把握。比如如果“事实一致性”平均分只有0.6那说明幻觉问题严重是首要优化目标。相关性分析观察不同指标间的相关性。例如是否“上下文相关性”低的记录其“事实一致性”也普遍低这很可能意味着检索质量是瓶颈你需要优化检索器如调整嵌入模型、改进分块策略、增加检索数量k。案例深挖点击低分记录尤其是关键指标如一致性得0分的记录仔细查看问题是什么检索到的上下文是什么是否相关生成的答案哪里出错了是模型胡编乱造还是上下文本身信息不足评估理由是什么LLM评估器指出具体哪句话没有依据6.2 基于评估的优化方向根据分析结果你可以有针对性地进行迭代如果“答案相关性”低问题可能出在提示工程或LLM本身。检查你的系统提示词是否清晰是否要求模型“严格基于上下文回答”可以尝试改进提示词加入更严格的约束比如“如果上下文没有明确信息请回答‘我不知道’”。如果“上下文相关性”低这是检索系统的问题。优化方向包括分块策略调整chunk_size和chunk_overlap。太大的块可能包含无关信息太小的块可能割裂语义。检索策略尝试不同的检索方法如MMR最大边际相关性在保证相关性的同时增加多样性或调整search_kwargs中的k返回的文档数量。嵌入模型升级到更强大的嵌入模型如text-embedding-3-large。元数据过滤如果文档有来源、章节等元数据可以在检索时加入过滤条件。如果“事实一致性”低这通常是RAG最棘手的问题。除了优化检索确保喂给模型的上下文是相关的和提示工程还可以考虑后处理在答案生成后增加一个“一致性校验”步骤让另一个LLM判断答案是否忠于上下文如果不忠则触发重答或标记。提示工程强化在提示词中多次、强调性地要求模型“只使用提供的信息”“不要添加任何已知信息之外的内容”。如果“自定义指标”分数低这直接反映了你的业务需求未满足。例如“结构化程度”低你可以在提示词中明确要求“请分点列出”“关键术语覆盖度”低可以尝试在检索后增加一个步骤从上下文中提取关键术语并强制要求模型在答案中提及它们。6.3 建立评估基准与持续监控一次性的评估意义有限。你应该建立一个评估基准数据集——一组涵盖各种类型、难度的问题及其“标准答案”或“期望属性”。定期例如每次更新检索策略或提示词后用这个数据集跑一遍评估对比关键指标的变化。TruLens允许你为同一个应用设置不同的app_id如My_RAG_App_v1_prompt1,My_RAG_App_v1_prompt2这样就可以在仪表盘中直观对比不同版本应用的表现。这构成了一个简单的A/B测试框架。最终将RAG评估集成到你的开发流水线中使其成为每次代码提交或模型更新后的一个自动化测试环节才能真正实现数据驱动的、可持续的RAG应用优化。7. 避坑指南与进阶技巧在实战中我踩过不少坑也总结出一些能大幅提升效率的技巧。7.1 常见问题与排查反馈函数不执行或分数为None原因最常见的是Select路径设置错误导致反馈函数获取不到所需的数据如context。排查在TruLens仪表盘打开一条记录的详情查看“Record”部分展开app-calls找到你的链的每一步输入输出。确认你试图访问的数据如检索器的输出的确切路径。然后修正Select语句。评估速度慢/成本高原因每个反馈函数尤其是调用LLM的如内置的相关性、一致性都会产生额外的API调用和耗时。优化批量评估不要在生产环境中为每次用户查询都运行全套评估。评估主要用于离线测试和迭代优化。可以使用tru_rag_chain.invoke的批量方式或者用Tru的run方法处理一批问题。采样评估在线上环境可以只对一小部分查询如1%进行抽样评估监控质量趋势。使用轻量级模型对于自定义的LLM反馈如果不需要极强推理能力可以考虑使用更小、更快的模型如gpt-3.5-turbo而不是gpt-4。自定义规则函数评分不准原因规则过于简单或存在漏洞。优化结合规则和LLM。例如先用规则过滤出明显结构化差的答案得0分对于规则判断模糊的再送入LLM进行精细评分。这样可以平衡成本和效果。7.2 进阶技巧组合反馈函数你可以将多个基础反馈函数的分数通过加权平均等方式组合成一个“综合分”。TruLens的Feedback机制本身支持算术运算。例如f_overall 0.4 * f_qa_relevance 0.4 * f_groundedness 0.2 * f_structure这样在仪表盘里你就能看到一个代表整体质量的单一指标。利用评估理由进行根因分析内置的LLM反馈函数带有_with_cot_reasons后缀的会输出详细的思考链。不要只看分数一定要读这些理由。它们往往是发现系统弱点的金矿。你可以批量导出这些理由做文本分析找出高频出现的错误模式。追踪上下文质量除了评估最终答案强烈建议增加一个直接评估“检索到的上下文”与“问题”相关性的反馈函数。这能帮你把检索问题和生成问题剥离开定位更精准。TruLens内置的context_relevance_with_cot_reasons就是干这个的。长期追踪与告警将TruLens的数据库默认是default.sqlite连接到你的数据看板如Grafana或者定期导出数据进行分析。可以设置一些阈值告警比如当“事实一致性”的7日滚动平均分下降超过10%时自动触发通知提醒团队检查。RAG评估不是一次性的任务而是一个伴随应用整个生命周期的持续过程。从用TruLens搭建起自动化的评估流水线开始你就拥有了优化RAG应用的“指南针”和“仪表盘”。它不能替你开车但能告诉你路在何方以及当前车速如何。记住没有度量就没有改进。现在就去为你自己的RAG应用装上这套科学的评估系统吧。
)
