一 为什么而建 互联网圈子是出了名的跳槽频繁，跳槽的目的就是为了拿到更高的薪酬，公司为什么会给你开出更高的薪酬，第一决定要素就是面试过程中你回答的够不够好。 所以每个人在面试前都会去刷大量的面试题，每个人的刷题方式都不同，有的是看自己之前总结的文章、有的是网上针对自己的盲区去搜索相关面试题、有的就无目的的直接搜索前端/后端面试题、有的是在面试后被面试官问完然后把不懂的问题记下后再去网上找答案。 每个人最后都能够拿到offer，但是是不是自己满意的就不得而知。 但是我们如果在面试前做好充足的准备，刷足够的面试题，最后也可以坦然的对自己说“这次的跳槽我已经尽力了”。 如果我们盲目的刷题，只会让自己越来越焦虑，越觉得自己知道的太少了。 所以是不是需要有个网站，可以把所有的经典面试题和面经都汇总好，放在那里等着你来看，你也可以根据自己薄软的知识点去筛选出对自己最有用的那部分内容，这样你就可以在最短的时间内，获取到最...

<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...

<title LCEL ≈ 函数式管道 / 中间件链，Runnable ≈ 可组合的处理单元</title <callout emoji="📌" 本文定位 ：LangChain 核心原理教程，从后端工程师视角深入理解 LCEL（LangChain Expression Language）与 Runnable 接口的设计思想、核心机制与实战模式。 前置知识 ：了解 Python 基础、函数式编程概念、Web 中间件模式。 父文档 ：Day 22：LangChain 核心组件深入 </callout 一、概述：为什么需要 LCEL？ 在 LangChain 的早期版本中，构建一条 LLM 链需要使用 LLMChain 类，将 Prompt、LLM、Output Parser 等组件硬编码在一起。这种方式存在三个核心痛点： 1. 组合不灵活 ：组件之间的耦合度高，难以自由替换或重组 2. 执行模式单一 ：默认同步阻塞，流式、批量、异步需要额外封装 3. 生产化困难 ：从原型到生产需要大量重构，缺乏统一的可观测性入口 LCEL...

<title LLM / ChatModels 抽象、Prompt Templates、Output Parsers，Runnable 接口（LCEL），链式组合（pipe 操作符）</title 概述 LangChain 作为大语言模型（LLM）应用开发的主流框架，其核心设计理念是 将复杂的 LLM 应用拆解为可组合、可复用的标准化组件 。本文系统讲解 LangChain 中最基础也最重要的五大核心抽象：模型抽象（LLM / ChatModels）、提示模板（Prompt Templates）、输出解析器（Output Parsers）、可运行接口（Runnable Interface）以及基于 LCEL 的链式组合（pipe 操作符）。 理解这五大组件，是掌握 LangChain 整个生态的基石——无论是 RAG、Agent 还是 Tool Calling，最终都可以还原为这些基础组件的组合与编排。 <callout emoji="📌" 本文定位 ：偏向原理教程，从抽象设计到代码实现逐层拆解，适合有一定 Python 基础、希望深入理解 LangCha...

<title LangChain 核心组件深入</title 概述 LangChain 是一个用于构建由大语言模型（LLM）驱动的应用程序的开源框架。它的核心设计哲学是 组件化 与 可组合性 ——将复杂的 LLM 应用拆解为一系列可独立替换、可灵活组合的标准组件，开发者可以像搭积木一样构建从简单问答到复杂 Agent 的各类应用。 本文将从原理层面深入剖析 LangChain 的六大核心组件： Models 、 Prompts 、 Indexes 、 Memory 、 Chains 和 Agents ，阐明每个组件的设计动机、内部机制、关键抽象以及它们之间的协作方式。 <callout emoji="💡" 阅读指引 ：本文偏向原理教程，每个组件均包含「设计动机 → 核心抽象 → 工作原理 → 代码示例 → 适用场景」的结构。建议按顺序阅读，因为后续组件的理解依赖于前面组件的概念。 </callout LangChain 整体架构 在深入每个组件之前，先建立对 LangChain 整体架构的宏观认知。LangChai...

<title 对比「直接检索」与「查询改写 + 重排序」的检索结果质量，用 10 个测试问题做主观评估</title <callout emoji="📚" 本文隶属于「Day 19：检索质量优化」学习计划，系统讲解直接检索与查询改写 + 重排序两种链路的原理差异，并提供一套可落地的 10 题主观评估方案。 </callout 引言：为什么要对比两种检索链路 在检索增强生成（RAG）系统中，检索环节的质量直接决定了大模型最终回答的准确性和相关性。然而，用户的原始查询往往存在表述模糊、信息不完整、口语化或过于复杂等问题，直接将其送入检索引擎往往难以获得理想结果<cite type="citation" <a href="https://juejin.cn/post/7639261453330399274" url-type="5" 稀土掘金：查询优化技术在RAG系统的实际应用</a </cite 。 业界主流的优化思路分为两个方向：一是在检索前对查询进行 改写 （Query Rewriting），使其更接近知识库的表述风格；二是在检索后对候选结果进行 重排序 ...