LangChain/LlamaIndex等框架应用 思维导图（定稿版）

• 总览
  • 1. 框架定位与对比
  • 2. LangChain核心体系
  • 3. LlamaIndex核心体系
  • 4. 框架工程化与选型

一、框架定位与对比

• LangChain定位
  • 一句话定位：通用LLM应用开发框架，像“瑞士军刀”
    • 提供了构建LLM应用所需的各种组件和抽象
  • 核心能力
    • Chain（链）：把多个步骤串起来，A→B→C
    • Agent（智能体）：让LLM自主决策，调用工具
    • Tool（工具）：封装外部能力，供Agent调用
    • Memory（记忆）：管理对话历史和上下文
    • Prompt模板：管理和复用Prompt
  • 擅长场景
    • 需要编排复杂工作流的应用（多步推理+工具调用）
    • Agent类应用（自主决策、多工具协作）
    • 需要灵活组合各种LLM能力的场景
  • 面试点：LangChain的定位是“通用框架”，什么都能做，但具体领域可能需要自己组装
• LlamaIndex定位
  • 一句话定位：专注数据索引和检索的框架，像“图书管理员”
    • 擅长把各种数据源变成LLM可检索的知识库
  • 核心能力
    • 数据连接器（Data Connectors）：从各种来源加载数据（文档/数据库/API/网页）
    • 索引（Index）：把数据组织成方便检索的结构（向量索引/树索引/关键词索引等）
    • 查询引擎（Query Engine）：接收用户问题，检索相关数据，生成答案
    • 高级检索策略：句子窗口检索、自动合并检索、递归检索等
  • 擅长场景
    • RAG应用（文档问答、知识库问答）
    • 需要复杂数据结构化处理的场景（嵌套文档、多级索引）
    • 多源数据聚合与分析
  • 面试点：LlamaIndex的定位是“数据+索引专家”，做RAG用它比LangChain更专业
• 核心区别速查表（面试必须能说出来）
  • 定位差异
    • LangChain：通用LLM应用开发框架，覆盖Chain/Agent/Tool/Memory/Prompt
    • LlamaIndex：专注数据索引和检索，覆盖Data Connector/Index/Query Engine
  • 擅长的不同
    • LangChain擅长的：复杂工作流编排、Agent、多工具协作
    • LlamaIndex擅长的：RAG、文档问答、结构化数据检索
  • 关键概念对比
    • LangChain的核心：Chain（链式编排）
    • LlamaIndex的核心：Index（数据索引）
  • 类比记忆
    • LangChain = 万能工具箱（能拼出各种东西）
    • LlamaIndex = 专业检索系统（做数据检索特别强）
• 什么时候用哪个（选型决策）
  • 用LangChain的场景
    • 需要Agent，让LLM自主调用多种工具
    • 需要编排复杂的多步骤工作流
    • 需要灵活组合各种LLM能力，不局限于RAG
  • 用LlamaIndex的场景
    • 主要做RAG，核心需求是文档问答
    • 需要处理复杂数据结构（嵌套文档、多级索引、多模态）
    • 需要高级检索策略（句子窗口/自动合并）
  • 两者可以混合使用
    • 用LlamaIndex做数据索引和检索
    • 用LangChain做Agent和工具编排
    • 面试点：实际项目中经常两者混用，不是非此即彼
  • 面试点：选型关键是看核心需求——主要做RAG选LlamaIndex，需要Agent选LangChain
• LangGraph的定位（高频追问）
  • 和LangChain的关系
    • LangChain是LangGraph的前身和基础
    • LangGraph是LangChain生态中专攻复杂Agent编排的框架
  • 为什么需要LangGraph
    • LangChain的Chain是单向DAG（无环图），不能循环和回溯
    • LangGraph支持循环、条件路由、状态管理，适合需要自我反思的Agent
  • 一句话区别
    • LangChain：适合简单链式任务（A→B→C）
    • LangGraph：适合复杂Agent（A→B→判断→回到A或继续C→循环）
  • 面试点：LangGraph是LangChain的升级版，专为复杂Agent设计
• 面试话术：框架对比回答模板
  • “两个框架我这样区分：LangChain是通用LLM应用框架，像瑞士军刀；LlamaIndex是数据检索专家，像图书管理员”
  • “做RAG我优先选LlamaIndex，索引和检索能力更专业；需要Agent和复杂工作流我选LangChain”
  • “实际项目中两者经常混合使用，LlamaIndex管检索，LangChain管编排”
  • “如果Agent逻辑复杂到需要循环和回溯，我会考虑上LangGraph”

二、LangChain核心体系

• Chain、Agent、Tool三者的关系（必考题）
  • Tool（工具）
    • 定位：最基础的执行单元，封装一个具体能力
      • 举例：搜索引擎Tool、计算器Tool、数据库查询Tool、天气查询Tool
    • 核心组成
      • name：工具名称，LLM通过名称决定调哪个
      • description：工具描述，告诉LLM这个工具干什么、什么时候该用
      • func：实际执行的函数，接收参数返回结果
    • 面试点：Tool的定义质量直接影响Agent的调用准确率
  • Chain（链）
    • 定位：把多个步骤按固定顺序串起来
      • 举例：用户提问→检索文档→拼Prompt→调LLM→返回答案
    • 特点：流程是预定义的，不会根据中间结果改变路径
    • 面试点：Chain适合流程固定的任务，不适合需要动态决策的场景
  • Agent（智能体）
    • 定位：让LLM自主决定调用哪些Tool、以什么顺序调
      • 举例：用户问“深圳天气怎么样，如果下雨推荐室内活动” → LLM自主决定先查天气，再根据结果决定要不要搜室内活动
    • 和Chain的本质区别
      • Chain：人预先定义好步骤顺序
      • Agent：LLM动态决定步骤和顺序
    • 面试点：Agent = LLM + Tool + 决策循环，核心是LLM的推理能力驱动决策
• 自定义Tool（面试高频实操题）
  • 实现步骤
    • 方式一：使用@tool装饰器（最简单）
      • @tool装饰一个Python函数，自动生成Tool对象
    • 方式二：继承BaseTool类（更灵活）
      • 适合需要复杂逻辑或异步调用的场景
    • 方式三：使用StructuredTool（需要严格参数校验时）
      • 用Pydantic定义参数Schema，自动校验参数类型
  • Tool定义的关键要点
    • 函数名即工具名：简洁明确，LLM通过名字识别
    • docstring即描述：LLM通过docstring判断什么时候该调用
      • 反面：“查询信息” → 正面：“根据城市名称查询当天天气，参数city为中文城市名”
    • 参数类型注解：帮助LLM正确传参
  • 面试点：能当场写一个自定义Tool的代码骨架是很好的加分项
• ReAct Agent实现
  • 在LangChain中如何实现ReAct Agent
    • 核心组件
      • LLM：负责推理和决策
      • Tools列表：可用的工具集合
      • AgentExecutor：执行Thought-Action-Observation循环
    • 创建步骤
      • 步骤一：定义Tools列表
      • 步骤二：选择Agent类型（ReAct/OpenAI Functions/Tool Calling）
      • 步骤三：创建AgentExecutor
      • 步骤四：调用executor.invoke({“input”: “用户问题”})
  • AgentExecutor的工作流程
    • 把用户输入和可用Tools传给LLM
    • LLM返回Thought（思考）和Action（要调用的工具+参数）
    • AgentExecutor执行工具调用，获取Observation（结果）
    • 把Observation反馈给LLM，让LLM决定下一步
    • 循环直到LLM返回Final Answer
  • 面试点：能画清楚这个循环、讲清AgentExecutor的职责是Agent开发的核心能力
• 同步调用的局限性及异步改造
  • 同步调用的问题
    • 问题一：阻塞主线程
      • 调用LLM API时，整个服务卡住等待响应，其他请求排队
    • 问题二：并发能力差
      • 同步模式下，100个请求只能串行处理，吞吐量极低
    • 问题三：多工具调用时效率低
      • Agent需要调多个工具时，一个接一个串行调，总延迟是所有工具延迟之和
  • 异步改造方案
    • 使用asyncio + aiohttp替代同步HTTP调用
    • 使用LangChain的AsyncChain/AsyncAgent
      • 调用方式从invoke()改为ainvoke()
    • 多工具并行调用
      • 不依赖彼此结果的多个工具可以同时调，总延迟取最慢的那个
  • 面试点：异步改造是生产环境的必备优化，同步模式只适合Demo和开发调试
• 面试话术：LangChain核心概念回答模板
  • “Chain、Agent、Tool三者关系：Tool是最基础的执行单元，Chain是按固定顺序组合Tool，Agent是让LLM动态决定调哪些Tool和顺序”
  • “自定义Tool我用@tool装饰器，关键是写好docstring，LLM通过它判断什么时候该调用”
  • “ReAct Agent的核心是AgentExecutor，它执行Thought-Action-Observation循环，直到LLM给出最终答案”
  • “同步调用的最大问题是阻塞，生产环境必须用ainvoke做异步改造，多工具能并行就并行”

三、LlamaIndex核心体系

• 三大核心抽象（必背框架图）
  • 数据连接器（Data Connectors）
    • 职责：从各种数据源加载数据，统一转换成Document对象
    • 支持的数据源
      • 文件：PDF、Word、Markdown、PPT、图片
      • 数据库：SQL数据库、MongoDB、Elasticsearch
      • API：Notion、Slack、Google Docs、GitHub
      • 网页：URL直接抓取、网站爬虫
    • LlamaHub：LlamaIndex官方维护的数据连接器市场
      • 面试点：LlamaHub提供了几百种开箱即用的数据连接器，省去自己写解析代码
    • 面试点：数据连接器让LlamaIndex能接入几乎任何数据源
  • 索引（Index）
    • 职责：把Document切成Node，组织成方便检索的结构
    • 常见索引类型
      • VectorStoreIndex（向量索引）：最常用，Document→Node→Embedding→存向量库
      • SummaryIndex（摘要索引）：存储每个Node的摘要，适合概览类问题
      • TreeIndex（树索引）：把Node组织成树状结构，适合层级分类
      • KeywordTableIndex（关键词表索引）：建立关键词到Node的映射，适合精确匹配
      • KnowledgeGraphIndex（知识图谱索引）：抽取实体和关系建图
    • 面试点：VectorStoreIndex是最常用的，大部分RAG场景用这一个就够了
  • 查询引擎（Query Engine）
    • 职责：接收用户问题，检索索引，调用LLM生成答案
    • 查询流程
      • 用户提问 → 查询引擎接收
      • 从索引中检索相关Node（Retrieve）
      • 将检索结果和问题拼接成Prompt（Synthesize）
      • 调用LLM生成答案返回
    • 面试点：查询引擎是用户面对的唯一接口，内部封装了检索和生成的完整流程
• 高级索引策略（LlamaIndex的核心竞争力）
  • 句子窗口检索（SentenceWindowNodeParser）
    • 解决的问题：固定大小切片容易把完整语义切碎
    • 核心思路
      • 切片时：按句子切，每个Node只包含一个句子（小块）
      • 检索时：用小句子的Embedding做精确匹配
      • 返回时：把匹配句子前后各N句一起返回（扩大窗口）
    • 优势：检索精度高（小块匹配），上下文完整性好（大窗口返回）
    • 面试点：句子窗口检索同时解决了检索精度和上下文完整性两个矛盾需求
  • 自动合并检索（Auto-Merging Retriever）
    • 解决的问题：层级文档（章节→段落→句子）中，小块匹配后丢失父级上下文
    • 核心思路
      • 建索引时：建立父子层级关系（文档→章节→段落）
      • 检索时：先匹配小块
      • 返回时：如果同一个父节点下多个子节点都被命中，自动合并返回父节点
    • 适用场景：层级结构清晰的文档（技术手册、百科、论文）
    • 面试点：自动合并检索能避免返回一堆零散的小段落，而是返回完整的章节内容
  • 递归检索（Recursive Retriever）
    • 解决的问题：一次检索不够精确，需要多轮检索缩小范围
    • 核心思路
      • 第一轮：从大范围索引中检索
      • 第二轮：在第一轮结果的基础上再检索
      • 多轮迭代直到找到最相关的内容
    • 适用场景：需要多跳推理的复杂问题、多级索引的文档集合
• 多模态能力（加分项）
  • 多模态文档处理
    • 问题：PDF中既有文字又有图片和表格，如何统一处理？
    • 方案
      • 步骤一：解析PDF时分别提取文字、图片、表格
      • 步骤二：图片用多模态模型生成文字描述
      • 步骤三：表格转成Markdown或JSON保持结构
      • 步骤四：文字、图片描述、表格统一建索引
    • 面试点：多模态RAG的核心是把非文字内容转成文字描述，和文字一起检索
  • 多模态检索
    • 用户传一张图片提问 → 用多模态模型理解图片 → 转成文字Query → 检索知识库
    • 面试点：LlamaIndex支持多模态模型集成，能处理图片理解和图文混合检索
• 面试话术：LlamaIndex核心概念回答模板
  • “LlamaIndex的架构可以归纳为三层：数据连接器负责接入数据，索引负责组织数据，查询引擎负责回答用户问题”
  • “高级索引策略是LlamaIndex最大的优势。句子窗口检索解决检索精度和上下文完整性的矛盾，自动合并检索解决层级文档的父级上下文丢失问题”
  • “多模态文档处理我一般走文字提取+图片描述生成+表格结构化的路线，把所有内容统一转成文字再建索引”
  • “大部分RAG场景用VectorStoreIndex就够了，文档结构复杂时再考虑句子窗口或自动合并检索”

四、框架工程化与选型

• LangChain到LangGraph的迁移
  • 为什么要迁移
    • LangChain的Chain是单向DAG，不支持循环和条件分支
    • Agent需要自我反思和回溯时，LangChain的线性结构不够用
    • 需要更精细的状态管理（多轮对话/多步骤任务的状态跟踪）
  • 迁移的核心变化
    • 思维转变：从“步骤链”变成“状态图”
      • LangChain：定义步骤1→步骤2→步骤3的顺序
      • LangGraph：定义节点（处理单元）和边（流转规则），包括条件边和回路
    • 代码层面变化
      • 原来用Chain/SequentialChain → 改用StateGraph
      • 原来用AgentExecutor → 改用LangGraph的Agent节点+工具节点
      • 原来用Memory管理历史 → 改用State中的消息列表
    • 最大挑战：不是代码重写，是思维从“线性”转向“图”
  • 迁移策略（务实方案）
    • 不建议全量迁移：现有LangChain项目跑得好好的别动
    • 新功能用LangGraph：需要循环/条件/多Agent的新需求用LangGraph开发
    • 混合运行：LangChain的简单Chain和LangGraph的复杂Agent共存
    • 面试点：迁移不是二选一，是渐进式演进，旧的不动新的用新框架
  • 面试点：面试官问“怎么迁移”不是要你背代码，是要听迁移策略和成本评估
• 生产级RAG中框架的职责边界
  • 框架擅长做的（直接使用）
    • 数据接入和预处理（LlamaIndex的数据连接器）
    • 索引构建和管理（LlamaIndex的索引体系）
    • Prompt模板管理和组装（LangChain的PromptTemplate）
    • 基础检索和生成流程编排
  • 框架不擅长做、需要自研的
    • 高并发下的性能优化
      • 框架默认是同步模式，生产需要自己改异步
      • 批量Embedding、连接池、多级缓存这些框架只管基础版
    • 业务逻辑深度定制
      • 复杂的权限控制（谁能搜哪些文档）
      • 业务规则引擎（某些条件下禁用某些工具）
      • 自定义的检索后处理逻辑
    • 稳定性保障
      • 框架不提供熔断、限流、降级这些生产必备能力
      • 需要自己在框架外层包一层稳定性中间件
    • 监控和可观测性
      • 框架有基本的日志，但生产级全链路追踪需要自己搭
      • 检索质量监控、LLM调用耗时分布等需要自建
  • 面试点：框架是加速开发的工具，不是生产的银弹。能用框架的就用，不够用的自己包一层
• 什么时候自研替代框架
  • 适合用框架的情况
    • 项目早期快速验证（MVP阶段）
    • 标准RAG场景（文档问答、知识库搜索）
    • 团队没有足够资源做底层开发
  • 适合自研的情况
    • 业务逻辑高度定制，框架的抽象反而成为限制
      • 举例：特有的检索排序算法、自定义的文档结构解析
    • 性能要求极高，框架的通用实现成为瓶颈
      • 举例：需要自己控制Embedding的批量大小和并发数
    • 需要精确控制依赖和版本
      • 框架升级频繁，API变动大，稳定业务受不了频繁改代码
    • 安全合规要求，不能引入第三方框架的依赖链
  • 自研的代价
    • 开发周期长：框架几行代码的事，自研可能要几周
    • 维护成本高：框架有社区维护，自研全靠自己
    • 面试点：自研不是技术多牛，是业务需求框架真的满足不了才考虑
  • 务实建议
    • 先框架快速上线 → 跑通业务 → 识别瓶颈 → 针对性自研替代
    • 面试点：最务实的做法是框架+自研混用，框架搭骨架，自研填血肉
• 不同应用场景的框架选型参考
  • 简单RAG文档问答
    • 推荐：LlamaIndex，它的数据接入和索引体系开箱即用
  • 复杂Agent多工具协作
    • 推荐：LangChain + LangGraph，Agent和工具编排是LangChain的强项
  • 多源数据聚合分析
    • 推荐：LlamaIndex，数据连接器丰富，索引策略灵活
  • 需要自定义工作流的业务系统
    • 推荐：LangGraph，状态图天然适合描述复杂业务流程
  • 面试点：选型不要教条，根据场景选工具，不是学了哪个就用哪个
• 面试话术：框架工程化回答模板
  • “迁移上我不建议全量重写。现有LangChain项目稳定运行就别动，新功能需要循环和条件路由的用LangGraph，两者可以共存”
  • “框架的职责边界是加速开发，不是替代工程能力。检索和索引用框架，高并发、稳定性、监控这些生产必备能力自己在框架外层包一层”
  • “自研替代我不会一上来就做。先用框架快速验证，业务跑通了如果框架确实成为瓶颈，再针对瓶颈模块自研替换”
  • “选型的核心是根据业务场景选最合适的工具，不是学了一个框架就到处套用”