<title 能搭建 RAG 评估流水线，量化系统效果</title <callout emoji="🎯" 本文是「Day 26：RAG 评估方法」的实践延伸，系统讲解如何从零搭建一套可复现、可量化的 RAG 评估流水线，覆盖检索质量、生成质量与系统性能三大维度。 </callout 一、为什么需要 RAG 评估流水线 RAG（Retrieval-Augmented Generation，检索增强生成）系统由 检索 和 生成 两个独立环节串联而成。任何一个环节出问题，最终答案质量都会下降。仅凭"感觉答案还不错"来调优，就像闭着眼睛开车——你不知道是检索没找到正确资料，还是大模型拿着正确资料却产生了幻觉。 一套标准化的评估流水线能够： 定位问题根因 ：区分是检索召回不足、排序不佳，还是生成阶段出现幻觉或答非所问 量化迭代效果 ：每次改动（换 Embedding 模型、调 Chunk 大小、换 LLM）都能用数字衡量收益 保障上线质量 ：将评估嵌入 CI/CD，防止回归问题流入生产环境 降低人工成本 ：用 LLM-as-

<title LLM-as-Judge 评估方法</title <callout emoji="📚" 本文是「Day 26：RAG 评估方法」的子文档，系统讲解 LLM-as-Judge（大模型作为评判者）评估方法的核心原理、主流框架、RAG 场景指标、工程实践与偏见缓解策略，帮助读者从零搭建可复现的自动评估流水线。 </callout 概述与核心原理 什么是 LLM-as-Judge LLM-as-Judge 是一种使用 大语言模型作为自动评估器 来评判另一个模型输出质量的方法。传统评估依赖精确字符串匹配（如 BLEU、ROUGE）或人工标注，前者无法捕捉语义层面的质量差异，后者成本高昂且难以规模化。LLM-as-Judge 通过向评判模型输入任务描述、待评估输出和评分标准（rubric），由其返回分数或判定结果，从而实现 低成本、可扩展、语义感知 的自动评估。[[1]](https://deepeval.com/blog/llm-as-a-judge) 其核心思想可以类比为：一位老师无法独自批改一万篇作文，于是聘请另一位能力足够的"AI 助教"...

<title RAG 评估方法</title <callout emoji="📚" 本文系统介绍检索增强生成（Retrieval-Augmented Generation, RAG）系统的评估方法论，覆盖检索质量、生成质量、端到端效果及业务价值四大维度，结合 LLM-as-Judge 自动化评估范式与主流开源框架，帮助开发者构建可量化、可诊断、可迭代的 RAG 评估体系。 </callout 为什么需要 RAG 评估 检索增强生成系统通过外部知识库为大语言模型（LLM）提供实时、可溯源的信息，已成为企业知识问答、客服机器人、文档摘要等场景的核心技术方案。然而，RAG 系统是一个包含 文档解析、分块、向量化、检索、重排序、Prompt 组装、生成 等多个环节的复杂流水线，任意一环的退化都可能导致最终回答质量下降。 缺乏系统化评估的 RAG 系统往往面临以下困境： "答非所问"难以定位 ：回答错误时，无法判断是检索没找到相关文档，还是找到了但模型没用到，抑或是模型本身产生了幻觉。 优化方向盲目 ：调整分块大小、更换 Embedding 模型、修

<title RAG 评估维度：检索质量（召回率、MRR、NDCG）、生成质量（忠实度 faithfulness、相关性、答案完整性）</title 为什么需要系统化的 RAG 评估 检索增强生成（Retrieval-Augmented Generation, RAG）通过外部知识库为大语言模型提供事实依据，已成为企业级 AI 应用的主流架构。然而，RAG 系统的最终输出质量取决于 两个独立且串联的环节 ：检索器能否找到正确的上下文，生成器能否基于上下文给出准确、完整的回答。任何一个环节出现问题，都会导致最终答案不可靠。 <callout emoji="💡" 仅凭"感觉答案不错"来调优 RAG 是不可靠的。幻觉可能来自检索缺失（正确文档没找到），也可能来自生成偏离（找到了但模型没用好）。必须用可量化的指标分别诊断两个环节。 </callout 本文系统梳理 RAG 评估的两大核心维度—— 检索质量 与 生成质量 ，深入讲解每个指标的定义、计算原理、适用场景与局限，帮助开发者建立可复现、可对比的评估体系。 RAG 评估整体框架 RAG 评估遵循"...

<title 能用 LangChain 快速构建带工具的 Agent，理解其内部循环机制</title <callout emoji="📚" 本文是 Day 25「LangChain Tools 与 Agent」的原理教程，聚焦 Agent 的内部循环机制与快速构建方法。 </callout 概述：从"只会聊天"到"自动做事" 传统的大语言模型（LLM）本质上是一个"文本预测器"——它接收输入，生成一段文本，然后结束。这种模式下，模型无法主动获取外部信息、无法执行操作，所有能力都局限于训练数据中已有的知识。 Agent（智能体）的核心突破在于：让 LLM 不再只是"回答问题"，而是能够 自主决策、调用工具、观察结果、循环迭代 ，直到完成复杂任务。LangChain 提供了一套标准化的 Agent 构建框架，将这套复杂的循环机制封装为简洁的 API。 <callout emoji="💡" 一句话理解 Agent ：Agent = LLM（大脑）+ Tools（手脚）+ 控制循环（神经系统）。LLM 负责决策"做什么"，Tools 负责"怎么做"，控制...

<title AgentExecutor 原理</title <callout emoji="📚" 本文隶属于「Day 25：LangChain Tools 与 Agent」学习路径，聚焦 AgentExecutor 的内部循环机制与核心原理，帮助你从源码层面理解 LangChain Agent 的运行时是如何驱动模型与工具协同完成任务的。 </callout 概述 AgentExecutor 是 LangChain 中 Agent 的 运行时环境（Runtime） 。它负责实际调用 Agent、执行 Agent 选择的动作（工具调用）、将动作输出回传给 Agent，并重复这一过程，直到 Agent 输出最终结果。 在 LangChain 的设计哲学中， Agent 负责"决定下一步做什么"（由 LLM + Prompt + Output Parser 组成），而 AgentExecutor 负责"把决定变成现实"——它是整个 ReAct（Reasoning + Acting）循环的调度引擎。[[1]](https://python.langch...

<title create_react_agent</title 部分内容由豆包生成 <callout emoji="📌" 本文是「Day 25：LangChain Tools 与 Agent」的子文档，深入解析 create_react_agent 的底层原理、核心组件与执行流程，帮助你从"会用"进阶到"懂原理"。 </callout 概述 create_react_agent 是 LangChain（及 LangGraph）中用于快速构建 ReAct 模式智能体的工厂函数。它将大语言模型（LLM）、工具集（Tools）和提示词（Prompt）组装成一个能够自主推理并调用工具的 Agent，是 LangChain Agent 体系中最经典、最常用的入口之一。 ReAct（Reasoning + Acting）范式源自论文 ReAct: Synergizing Reasoning and Acting in Language Models ，其核心思想是让模型在 思考（Thought） 与 行动（Action） 之间交替进行，通过观察（...

<title 内置工具（Tavily 搜索、Python REPL 等）</title <callout emoji="📚" 本文是 Day 25「LangChain Tools 与 Agent」的子文档，深入讲解 LangChain 内置工具的原理与使用，重点覆盖 Tavily 搜索与 Python REPL 两大核心工具。 </callout 概述：为什么 Agent 需要内置工具 大语言模型（LLM）本质上是一个基于训练数据的「概率预测引擎」，它存在两个天然局限： 知识截止 ：训练数据有时间边界，无法获知实时信息 计算能力弱 ：复杂数学运算、数据处理容易出错 LangChain 的内置工具（Built-in Tools）正是为了弥补这些缺陷而设计的。工具是 Agent 的「感官」和「手脚」——搜索工具让 Agent 能「看到」外部世界，代码执行工具让 Agent 能「动手」完成计算任务。[[1]](https://un.csdn.net/aombs5zme4se) ![流程图](https://static.developers.pub

<title LangChain Tool 抽象、@tool 装饰器</title <callout emoji="📚" 本文隶属于「Day 25：LangChain Tools 与 Agent」学习计划，深入讲解 Tool 抽象层的设计原理与 @tool 装饰器的内部机制。 </callout 一、Tool 抽象的核心设计 1.1 什么是 Tool 在 LangChain 中， 工具（Tool） 是将一个 Python 函数（function） 与一个 模式（schema） 关联起来的抽象。该模式定义了函数的 名称（name） 、 描述（description） 和 预期参数（expected arguments） ，从而使大语言模型（LLM）能够理解并请求调用这个函数。[[1]](https://python.langchain.ac.cn/docs/concepts/tools/) 工具的本质是一座桥梁：一端连接 LLM 的自然语言决策能力，另一端连接确定性的代码执行能力。模型通过工具的 schema 知道"有哪些工具可用、...

<title LangChain Tools 与 Agent</title 部分内容由豆包生成 概述 LangChain 是构建大语言模型（LLM）应用的主流框架，而 Tools（工具） 与 Agent（智能体） 是其最核心的两个抽象。工具赋予模型"动手能力"，智能体则赋予模型"自主决策能力"。二者结合，使 LLM 从单纯的文本生成器升级为能够感知环境、调用外部能力、自主完成复杂任务的执行系统。<cite type="citation" <a href="https://docs.langchain.com/oss/python/langchain/overview" url-type="5" LangChain 官方文档 Overview</a </cite <callout emoji="💡" 核心心智模型 ：Agent = LLM（大脑）+ Tools（手脚）+ 执行循环（神经反射）。LLM 负责推理决策，Tools 负责与外部世界交互，执行循环负责将二者串联为自主闭环。 </callout 什么是 Tool Tool（工

<title 实现 Parent-Child Chunking 策略——小块用于检索匹配，大块用于上下文生成</title 概述 在检索增强生成（RAG）系统中，文档分块（Chunking）是决定检索质量与生成效果的核心环节。传统的固定大小分块策略往往面临一个两难困境：分块太小则上下文不完整，生成时缺乏足够的语义背景；分块太大则检索精度下降，大量无关信息被塞入上下文窗口，稀释关键内容并增加 Token 消耗。 Parent-Child Chunking（父子分块） 正是为解决这一矛盾而提出的高级分块策略。其核心思想极为简洁：用 小块（Child Chunk） 做语义检索匹配，保证召回精度；用 大块（Parent Chunk） 做上下文生成，保证语义完整性。两者通过元数据关联，在检索时命中小块，在生成时回溯获取其父块的完整内容。<cite type="citation" <a href="https://docs.llamaindex.ai/en/stable/module_guides/loading/node_parsers/modules.html pa...

<title 父子分块（Parent-Child Chunking）、假设性文档嵌入（HyDE）、Self-RAG、Graph RAG 原理教程</title 概述：从基础 RAG 到高级检索模式 检索增强生成（Retrieval-Augmented Generation, RAG）通过为大语言模型（LLM）提供外部知识库，有效缓解了幻觉问题并扩展了知识边界。然而，基础 RAG 在实际应用中面临诸多挑战：分块粒度难以兼顾检索精度与上下文完整性、短查询与长文档之间存在语义鸿沟、检索结果缺乏质量评估机制、全局问题难以通过局部片段回答。 本文系统介绍四种高级 RAG 模式的核心原理与架构设计，帮助读者理解各自的解决思路、适用场景与组合策略。 图 1：四种高级 RAG 模式的演进定位与核心价值 父子分块（Parent-Child Chunking） 核心问题：检索精度与上下文完整性的矛盾 在 RAG 系统中，...

<title 高级 RAG 模式</title <callout emoji="📚" 本文系统讲解高级 RAG（Retrieval-Augmented Generation，检索增强生成）模式的核心原理、架构设计、关键技术与工程落地方法，适合有一定 RAG 基础、希望深入掌握进阶技术的工程师和技术学习者。 </callout RAG 概述与演进 什么是 RAG RAG（Retrieval-Augmented Generation，检索增强生成）是一种将 信息检索 与 大语言模型生成 相结合的混合架构。它通过在生成答案前先从外部知识库中检索相关文档，有效解决了纯大语言模型的三大核心痛点： 知识截止日期限制 ：模型无法获取训练数据之后的新知识 幻觉问题 ：模型在面对不确定信息时容易编造看似合理但错误的内容 私有知识无法访问 ：模型无法直接获取企业内部文档、个人数据等私有知识 RAG 的基本思想是： 先检索、后生成 。用户提问时，系统先从知识库中召回最相关的文档片段，然后将这些片段作为上下文与问题一起送入大模型，由模型基

<title LangChain Memory 与对话管理</title 部分内容由豆包生成 <callout emoji="🧠" 本文系统讲解 LangChain 中 Memory（记忆）模块的设计原理、核心类型与实战用法，帮助开发者为对话系统选择合适的记忆策略，实现真正的多轮上下文感知。 </callout 为什么需要 Memory LLM 的无状态本质 大语言模型（LLM）在每次调用时本质上是 无状态 的——模型本身不会记住上一轮对话的内容。每一次 API 请求都是独立的，模型只能看到当前请求中传入的文本。这意味着，如果不做任何额外处理，用户在第二轮问"它的优缺点是什么？"时，模型根本不知道"它"指代的是什么。 Memory 模块的核心使命就是： 在无状态的 LLM 之上，构建一层有状态的对话上下文管理层 ，让应用能够记住历史对话，并在每轮交互时将相关历史注入 Prompt，使模型具备"记忆"能力。 <callout emoji="💡" 关键洞察 ：Memory 不是让模型本身记住东西，而是在应用层管理对话历史，并在每次调用...

<title ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory、基于向量库的长期记忆、记忆与 RAG 的结合</title <callout emoji="📚" 本文为「Day 23：LangChain Memory 与对话管理」的原理教程，系统讲解五种记忆机制的核心原理、工作流程、代码实践与适用场景，并深入探讨记忆与 RAG 的结合架构。 </callout 概述：为什么 LLM 需要记忆 大语言模型（LLM）本身是 无状态 的——每一次 API 调用都是独立的，模型不会自动记住之前的对话内容。要让 AI 助手具备连续对话能力，就需要在外部维护一份「对话历史」，并在每次请求时将其注入到 Prompt 中。这就是 Memory（记忆） 模块的核心职责。 LangChain 提供了多种记忆实现，它们在「保留多少历史」「以什么形式保留」「如何控制 Token 消耗」三个维度上做出了不同的权衡。 ![流程图](https://static.de...