AIAgent开发-LangChain

鱼儿在飞 發表於 2026-3-19 10:17:00

<h1>前言</h1>
回顾人类与机器的协同模式已经经历了如下几大阶段：
搜索引擎阶段：机器负责信息检索，人进行逻辑推理、任务执行。
LLM阶段：机器负责内容推理和任务执行，人输入指令。
Agent阶段：机器负责推理决策 + 自主执行，人输入目标定义、需求明确、结果校验。
如运维领域已经出现了SQL/代码审计、AIOPS故障定位根因分析、OAM/YAML/配置自动生成等各类AIAgent。
我觉得AI时代人机协同的范式应该就是人重思考，AI执行。
<h1>AI Agent</h1>
AI Agent也称人工智能体/智能代理内置
<ul>
<li>大语言模型(LLM)</li>
<li>记忆（Memory）</li>
<li>解析器/控制逻辑（Agent Core）</li>
<li>工具集(Tools)</li>
</ul>
AI Agent本质是把原本需要人类与LLM进行的多轮推理、决策、实践的过程，通过程序自动化。赋予LLM在完成决策后，调用工具和执行任务的能力。
<h2>架构概览</h2>
<img alt="image" width="703" height="328" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260320150812791-779422698.png" class="lazyload">
<h2>AIAgent工作流程</h2>
1个企业级AIAgent应用应该具备以下流程
<div class="cnblogs_code">
<pre>用户提问
↓
1. 意图识别 & 分类
↓
2. 历史对话压缩/摘要
↓
3. 少样本示例检索（Few-shot）
↓
4. RAG 知识库粗检索（向量库）
↓
5. Rerank 重排序（精排）
↓
----------------------------------
【第一次 LLM 调用：工具决策】
----------------------------------
↓
6. 工具参数校验 + 权限校验
↓
7. 执行工具调用（K8s/API/DB/CLI）
↓
8. 工具结果清洗、格式化
↓
----------------------------------
【第二次 LLM 调用：最终回答生成】
----------------------------------
↓
返回答案</pre>
</div>
<h3>1. 用户提问 → 意图识别 & 分类</h3>
<ul data-start="93" data-end="210">
<li data-section-id="1h31npg" data-start="93" data-end="134">
目的：理解用户需求，判断属于哪类操作（查询/修改/告警/数据分析等）。
</li>
<li data-section-id="1hh1itx" data-start="135" data-end="210">
实现方式：
<ul data-start="149" data-end="210">
<li data-section-id="fka7x6" data-start="149" data-end="192">
训练意图分类模型（BERT/LLM zero-shot 或 fine-tune）。
</li>
<li data-section-id="11jy1qd" data-start="195" data-end="210">
输出分类标签 + 置信度。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="27czvi" data-start="212" data-end="230">2. 历史对话压缩 / 摘要</h3>
<ul data-start="231" data-end="314">
<li data-section-id="3epsbw" data-start="231" data-end="265">
目的：减少上下文长度，保留关键信息，让 LLM 更高效。
</li>
<li data-section-id="l9g8db" data-start="266" data-end="314">
实现方式：
<ul data-start="280" data-end="314">
<li data-section-id="jn1bxk" data-start="280" data-end="293">
摘要模型压缩历史消息。
</li>
<li data-section-id="dvpxj1" data-start="296" data-end="314">
可选：按时间窗口/关键实体抽取。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="12plqe2" data-start="316" data-end="340">3. 少样本示例检索（Few-shot）</h3>
<ul data-start="341" data-end="430">
<li data-section-id="mqqlwp" data-start="341" data-end="373">
目的：给 LLM 提供类似场景或模板，让生成更准确。
</li>
<li data-section-id="17rswjs" data-start="374" data-end="430">
实现方式：
<ul data-start="388" data-end="430">
<li data-section-id="y3v92g" data-start="388" data-end="398">
构建少量示例库。
</li>
<li data-section-id="1smzuh6" data-start="401" data-end="430">
使用相似度匹配或 embedding 检索最相关示例。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="1mcrmm9" data-start="432" data-end="454">4. RAG 知识库粗检索（向量库）</h3>
<ul data-start="455" data-end="580">
<li data-section-id="gl6jop" data-start="455" data-end="482">
目的：从知识库中找到可能有用的文档/片段。
</li>
<li data-section-id="1re6d06" data-start="483" data-end="580">
实现方式：
<ul data-start="497" data-end="580">
<li data-section-id="1hxb120" data-start="497" data-end="543">
文档向量化（OpenAI Embeddings / FAISS / Milvus 等）。
</li>
<li data-section-id="x6z8k" data-start="546" data-end="580">
通过用户 query 向量与库向量匹配，返回 Top-K 文档。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="17y2mo1" data-start="582" data-end="603">5. Rerank 重排序（精排）</h3>
<ul data-start="604" data-end="718">
<li data-section-id="jtqfwj" data-start="604" data-end="639">
目的：提高知识片段的相关性，减少 LLM “胡编”的概率。
</li>
<li data-section-id="kkf7zl" data-start="640" data-end="718">
实现方式：
<ul data-start="654" data-end="718">
<li data-section-id="17a40re" data-start="654" data-end="691">
使用专门的reranker 模型（如cross-encoder交叉编码器模型）。
</li>
<li data-section-id="1hpwlcx" data-start="694" data-end="718">
结合 query、上下文、实体信息重新评分。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="1if6n0h" data-start="725" data-end="746">【第一次 LLM 调用：工具决策】</h3>
<ul data-start="747" data-end="828">
<li data-section-id="184udmp" data-start="747" data-end="778">
功能：决定下一步需要调用哪个工具，并生成调用参数。
</li>
<li data-section-id="1mz3ut9" data-start="779" data-end="808">
输入：意图标签 + 历史上下文 + 检索知识。
</li>
<li data-section-id="1t4viog" data-start="809" data-end="828">
输出：工具调用指令或决策。
</li>
</ul>
<h3 data-section-id="1c84gpy" data-start="835" data-end="855">6. 工具参数校验 + 权限校验</h3>
<ul data-start="856" data-end="937">
<li data-section-id="1d0kblz" data-start="856" data-end="877">
目的：保证操作安全性和合法性。
</li>
<li data-section-id="nkho84" data-start="878" data-end="937">
实现方式：
<ul data-start="892" data-end="937">
<li data-section-id="1wdih8h" data-start="892" data-end="907">
参数类型、范围、格式校验。
</li>
<li data-section-id="pmggbz" data-start="910" data-end="937">
用户权限/角色校验（RBAC 或自定义权限系统）。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="buhlob" data-start="939" data-end="968">7. 执行工具调用（K8s/API/DB/CLI）</h3>
<ul data-start="969" data-end="1017">
<li data-section-id="7jjccm" data-start="969" data-end="1017">
实现方式：
<ul data-start="983" data-end="1017">
<li data-section-id="1imcohr" data-start="983" data-end="998">
根据工具类型调用对应接口。
</li>
<li data-section-id="1jma80j" data-start="1001" data-end="1017">
可能涉及异步执行或任务队列。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="2x85bv" data-start="1019" data-end="1036">8. 工具结果清洗、格式化</h3>
<ul data-start="1037" data-end="1117">
<li data-section-id="1xkmvck" data-start="1037" data-end="1067">
目的：统一输出格式，便于 LLM 生成最终答案。
</li>
<li data-section-id="8rocyh" data-start="1068" data-end="1117">
实现方式：
<ul data-start="1082" data-end="1117">
<li data-section-id="tnbk79" data-start="1082" data-end="1093">
JSON 标准化。
</li>
<li data-section-id="188pk5y" data-start="1096" data-end="1117">
提取关键字段、统计数据、表格化信息等。
</li>
</ul>
</li>
</ul>
<h3 data-section-id="fxcd1z" data-start="1124" data-end="1147">【第二次 LLM 调用：最终回答生成】</h3>
<ul data-start="1148" data-end="1241">
<li data-section-id="1oz8x36" data-start="1148" data-end="1181">
目的：将工具结果、知识片段、上下文整合成自然语言输出。
</li>
<li data-section-id="1ta57yt" data-start="1182" data-end="1241">
实现方式：
<ul data-start="1196" data-end="1241">
<li data-section-id="vs586u" data-start="1196" data-end="1214">
LLM 生成面向用户的自然回答。
</li>
<li data-section-id="1pi0j49" data-start="1217" data-end="1241">
可选择多轮对话生成、带解释的回答或建议操作。
</li>
</ul>
</li>
</ul>
<h2>Agentic Workflow设计范式</h2>
RAG：通过内部知识库 + 检索 + LLM推理，解决模型知识不足的问题，保证回答的准确性与稳定性；、
Agent：通过LLM推理 + 工具调用，实现对外部系统和能力的动态操作与执行；
Workflow：通过预定义流程编排，提供稳定、可控的任务骨架。
Agentic Workflow：因此在实际系统中，例如扣子常采用Workflow + Agent + RAG的组合模式：
由Workflow负责整体流程控制，在关键节点嵌入 Agent 提供智能决策能力，并结合 RAG 引入企业知识，实现兼具稳定性与灵活性的Agentic Workflow架构。
<h3 data-section-id="vo3462" data-start="66" data-end="92">1.Agent（完全/多轮推理型）</h3>
特点：
<ul data-start="99" data-end="217">
<li data-section-id="1jhut7k" data-start="99" data-end="130">
核心是 LLM + 工具 + while loop
</li>
<li data-section-id="jejef2" data-start="131" data-end="157">
能多轮推理、自主决定调用哪些工具
</li>
<li data-section-id="1f3ugrr" data-start="158" data-end="178">
每次调用 LLM 都可能产生新的行动
</li>
<li data-section-id="1sf7gmq" data-start="179" data-end="194">
优势：灵活，能处理未知场景
</li>
<li data-section-id="1d6nvfr" data-start="195" data-end="217">
风险：死循环、成本高、不可控、可能误操作
</li>
</ul>
典型场景：
<ul data-start="226" data-end="271">
<li data-section-id="v37g2s" data-start="226" data-end="252">
自动排障 Agent（理论上LLM决定每步）
</li>
<li data-section-id="2jf7mt" data-start="253" data-end="262">
自动化脚本生成
</li>
<li data-section-id="lgbjt1" data-start="263" data-end="271">
高度动态任务、高度自动化
</li>
</ul>
<h3 data-section-id="1k5qp2z" data-start="278" data-end="334">2.RAG（Retrieval-Augmented Generation）+ Workflow</h3>
<img alt="image" width="1660" height="187" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260323215930019-537091563.png" class="lazyload">
特点：
<ul>
<li>支持加载企业内部文档、私有知识库，信息更贴合业务</li>
<li>流程固定，行为可控、稳定、可预测</li>
<li>减少无效LLM调用，Token成本更低</li>
<li>易调试、易监控、易上线运维</li>
</ul>
典型场景：
<ul data-start="470" data-end="494">
<li data-section-id="1rkv9g2" data-start="470" data-end="476">
告警分析
</li>
<li data-section-id="1gzrdsq" data-start="477" data-end="485">
事件根因分析
</li>
<li data-section-id="12ncnjp" data-start="486" data-end="494">
运维知识问
</li>
</ul>
<h1>LangChain</h1>
在AI Agent中
<ul>
<li data-start="37" data-end="200">LLM是大脑，负责生成决策和答案；</li>
<li data-start="37" data-end="200">工具是手脚，执行具体操作；</li>
<li data-start="37" data-end="200">记忆是经验，积累上下文和历史信息；</li>
<li data-start="37" data-end="200">而解析器/控制逻辑（LangChain或Dify）才是中枢神经，将大脑、手脚和经验高效协同起来。没有中枢神经，Agent无法根据LLM输出的答案自动调用对应工具执行任务。</li>
</ul>
LangChain是开发AI Agent 的一站式框架，它的核心价值在于将大模型（LLM）、记忆、工具、规划等 Agent 核心模块串联起来，使开发者无需从零实现整个系统，就能快速搭建能够自主完成复杂任务的智能体。
LangChain 的核心模块可以总结为六大类（加上 RAG 增强）：
<h2>1.LLM</h2>
LLM负责处理Prompt并生成结果，是AI Agen核心能力组件。
根据部署方式不同，模型通常分为外部 LLM（云模型） 和 企业内部 LLM（私有模型） 两种。
<h3 data-section-id="nfxqhq" data-start="47" data-end="68">1. 外部LLM（云LLM）</h3>
外部LLM指由第三方厂商提供的大语言模型服务，通过互联网API调用。
常见的外部模型包括：
<ul data-start="121" data-end="288">
<li data-section-id="16plzgz" data-start="121" data-end="204">ChatGPT（由 OpenAI 提供） </li>
<li data-section-id="1fmabmb" data-start="205" data-end="288">Claude（由 Anthropic 提供） </li>
</ul>
客户端通过HTTP API调用模型服务，通常按照 Token使用量进行计费。
<h3 data-start="290" data-end="403">2. 企业内部 LLM（私有LLM）</h3>
企业内部 LLM 指企业将开源大模型部署在自身基础设施中，对内部用户提供推理服务。
常见部署模型包括：
<ul data-start="495" data-end="614">
<li data-section-id="1fetjdh" data-start="495" data-end="534">DeepSeek </li>
<li data-section-id="16uh11" data-start="535" data-end="574">Llama </li>
<li data-section-id="btvcid" data-start="575" data-end="614">Qwen </li>
</ul>
企业通常借助推理框架（如 vLLM）将模型封装为API服务，对内部系统或用户开放访问。
私有化部署的特点：
<ul data-start="707" data-end="767">
<li data-section-id="x3odzc" data-start="707" data-end="725">数据不出企业内网，安全性更高</li>
<li data-section-id="kuxran" data-start="726" data-end="745">可以根据业务需求进行定制化优化</li>
<li data-section-id="26v9ik" data-start="746" data-end="767">初期需要投入 GPU 服务器等算力资源</li>
</ul>
在硬件方面，大多数大模型推理需要GPU加速才能达到可接受的响应速度和并发能力。
<h2>2.ModelI/O(模型I/O)</h2>
管理提示词模板、格式化输入，解析模型输出。
<img alt="0c1f9c2dab1d67ee4088d365b9f0e29a" width="753" height="314" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260322131010140-1285235158.png" class="lazyload">
<h3>提示词分类</h3>
<h4>System Prompt（系统提示词）</h4>
System Prompt（系统提示词）用于定义模型的人设与行为规则。
<h4 data-start="57" data-end="147">Agent Skill</h4>
自研Agent客户端会在代码中封装System Prompt，或在客户端（Claude Code）预留Skills文件与System Prompt 输入入口，支持自定义 Agent Skills。
为啥需要Agent skill？
降本：解决上下文臃肿与成本爆炸
不再把海量SOP、API文档全量塞进System Prompt，而是通过Skill Router动态路由按需挂载技能。
大幅减少Token消耗，避免模型注意力丢失，同时降低推理成本。
解耦：解决多智能体协调复杂
Skill采用无状态设计，配合Blackboard黑板模式共享状态，让各技能之间完全解耦。
不需要Agent之间频繁通信，避免逻辑死循环，提升系统稳定性与可扩展性。
增效：确保Agent调用到工具准确率：
解决Agen有工具但不去用，不会用的问题：模块化Skill 把 Instructions（指令）+ Reference（知识）+ Scripts（执行逻辑） 打包成完整技能包。
让 AI 清楚知道在什么业务节点、该调用哪个工具、如何组合使用，确保工具真正落地业务。
<img alt="image" width="775" height="316" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260326095449001-469757783.png" class="lazyload">
 
Agent Skill企业级架构
<img alt="image" width="809" height="710" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260326094320527-808816845.png" class="lazyload">
RAG是动态知识路由，Agent Skill是动态技能路由，它们都是Prompt路由（Prompt Routing）的不同落地形式。
<h4>User/Human Prompt（用户提示词）</h4>
指用户以自然语言输入的内容，即人类提出的问题或请求。
<h4>Assistant Prompt（助手提示词）</h4>
AI之前的历史回答记录，LLM客户端与LLM的对话记忆。
<h4>Context Prompt（上下文提示词）</h4>
LLM没有记忆，豆包和DeepSeek某些情况能记住我们，是因为它们属于Chart智能体，而不是LLM。
短期记忆 = 对话历史，直接放在上下文。
长期记忆 = 存在外面，通过 RAG 检索后，再放进上下文
上下文 = 模型在这一轮能看到的所有信息
如果智能体需要支持多轮交互，记忆模块是提示用户体验的重要部
<h4>Tool Prompt（工具提示词）</h4>
工具说明书，告诉LLM有哪些工具可以用，需要生成哪些参数。
LLM生成json格式参数之后，Agent Core结合反射机制调用函数/类，传参执行。
<h2>3.Chain（链）</h2>
将多个步骤/调用串联成复杂流程，实现流水线式推理。
<h2>5.Tools（工具）</h2>
当前主流 LLM（如豆包、GPT-4o、Claude、通义千问、文心一言）均不支持直接调用工具
而Agent可通过Prompt向模型描述意图与可用工具，引导LLM根据人类语言输入，输出对应的目标工具名称和执行参数，再由Agent Core根据LLM输出的工具名称和参数，间接调用执行工具，经过多轮思考+实践，最终完成任务。
正是这关键的一步，使AI完成了从聊天工具到AI Agent(自助思考+使用工具)的跨越。
<div class="cnblogs_code">
<pre>LLM
↓
Function Calling
{
"name":"query_pod_event",
"arguments":{"pod":"podA"}
}
↓
Agent
↓
MCP 调用
↓
MCP Server
↓
Kubernetes API</pre>
</div>
<h3>MCP</h3>
在AI Agent规模化落地的过程中，我们常常会遇到一个典型痛点：同一个业务工具（如订单查询、数据库操作、第三方 API 调用等），在不同AI Agent、不同框架甚至不同大模型接入场景下，都需要重复编写工具描述、重新适配调用格式。
这不仅带来大量冗余开发，也让工具管理分散混乱，严重阻碍了AI能力的标准化与规模化复用。
<img alt="fe4373a2a6f36c165a2fd7ba76cd9348" width="642" height="393" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260321201921098-866391999.png" class="lazyload">
<div>MCP（Model Context Protocol）正是为解决这一问题而设计的标准化协议，可以理解为一套AI Agent与外部工具交互的通用接口规范。</div>
<h2>6.Agent（智能体）</h2>
根据任务自主决策调用 Chain 或 Tools。
<h2>7.RAG（检索增强生成）</h2>
LLM本身虽然具备强大的推理与文本/图片/视频生成能力，但其内置知识是静态的，无法实时更新，也无法直接使用企业或个人的私有、隐私数据。
通过持续微调大模型来更新知识，门槛和成本较高，需要大量高性能显卡、充足算力资源，还必须依赖专业的算法工程师进行训练与调优，对大多数企业来说难以负担。
RAG能有效解决大模型的幻觉（胡编乱造）和知识滞后问题，让模型在不需重新训练的情况下，掌握私有或最新的知识。
<div class="cnblogs_code"><img id="code_img_closed_1ab907f3-493d-4ab5-82af-8bfecfd205e6" class="code_img_closed lazyload" data-src="http://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif"><img id="code_img_opened_1ab907f3-493d-4ab5-82af-8bfecfd205e6" class="code_img_opened lazyload" style="display: none" data-src="http://images.cnblogs.com/OutliningIndicators/ExpandedBlockStart.gif">
<div id="cnblogs_code_open_1ab907f3-493d-4ab5-82af-8bfecfd205e6" class="cnblogs_code_hide">
<pre>import os
from langchain_openai import ChatOpenAI
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
# 加载
loader = TextLoader("./ops_sop.txt", encoding="utf-8")
documents = loader.load()
splitter = RecursiveCharacterTextSplitter(
chunk_size=300,# 每块300字符
chunk_overlap=50# 重叠50字符
)
texts = splitter.split_documents(documents)
print(f"切分后总共 {len(texts)} 个 chunk")

#LLM
chat_model=ChatOpenAI(
name="gpt-4.1-mini",
base_url="https://api.openai-proxy.org/v1",
api_key="",
temperature=0.5,
max_tokens=20,
)

# Embedding模型
embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh")
vectordb = Chroma.from_documents(
documents=texts,
embedding=embedding,
persist_directory="./ops_sop"
)
#存储到向量数据库
vectordb.persist()

#RAG
def blog_agent(query: str):
docs = vectordb.similarity_search(query, k=1)
return "\n\n---\n\n".join()

#RAG工作流
def ops_agent(key_word, top_k=1) -> str:
#查询向量数据库:prompt---->Embeding模型---->向量---->查询向量数据库--->返回文档--->LLM
retrieved_docs = vectordb.similarity_search(query=key_word, k=top_k)
context = "\n\n".join()
#提示词
prompt = f"你是运维专家，基于以下文档回答问题：\n{context}\n\n问题：{key_word}"
# 调用 ChatOpenAI
response = chat_model.invoke(prompt)
return response.content

# 提问
if __name__ == "__main__":
while True:
q = input("我是运维专家，请输入你的问题：")
print(f"请参考：{ops_agent(q)}")</pre>
</div>
rag</div>
不需要重新训练LLM，只需将最新的内部文档数据接入检索知识库，LLM即可基于检索到的真实、实时信息生成回答，既实现了知识更新，又保护了数据隐私，同时大幅降低LLM落地门槛和成本。
<img alt="image" width="554" height="365" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260321101203400-585445198.png" class="lazyload">
<h3>RAG流程所需模型分类</h3>
在大模型应用中，RAG（检索增强生成）是解决知识时效性、事实准确性的核心方案。
<img alt="c2641636fbeace12ee150fbaa5943c15" width="599" height="350" loading="lazy" src="https://img2024.cnblogs.com/blog/1122865/202603/1122865-20260327201911526-867386595.png" class="lazyload">
<div data-page-id="S3WmfxGwCdqUZuc9r75c8OKpnBd" data-lark-html-role="root" data-docx-has-block-data="false">
<div class=" old-record-id-GiacfR4lSdsbu2cWrYHcM3Y7nMg">
<div class=" old-record-id-GiacfR4lSdsbu2cWrYHcM3Y7nMg">支撑整个RAG流程的，正是5类核心模型。它们各司其职、环环相扣，从原始文本处理到最终答案生成，每一步都离不开特定模型的支撑。</div>
<table style="height: 217px; width: 1452px">
<thead>
<tr><th>阶段</th><th>核心模型</th><th>核心作用</th></tr>
</thead>
<tbody>
<tr>
<td>文本拆分（Chunking）</td>
<td>Chunk 模型</td>
<td>将长文档按语义或长度切分为小块，为后续向量化与检索做准备</td>
</tr>
<tr>
<td>向量化（Embedding）</td>
<td>Embedding 模型</td>
<td>把文本小块编码为向量，实现语义层面的相似性检索</td>
</tr>
<tr>
<td>候选精排（Rerank）</td>
<td>Rerank模型</td>
<td>对粗召回候选集逐对计算相关性分数，按分数重排序并过滤冗余噪声</td>
</tr>
<tr>
<td>内容精炼（可选）</td>
<td>提纯模型</td>
<td>提取关键信息或生成摘要，精简素材以提升后续处理效率</td>
</tr>
<tr>
<td>答案生成</td>
<td>LLM</td>
<td>整合高相关性素材，组织语言生成连贯、准确的最终回答</td>
</tr>
</tbody>
</table>
</div>
</div>
<h2>8.Graph RAG</h2>
传统 RAG（Retrieval-Augmented Generation）主要依赖用户提示词与文本块之间的语义相似度匹配来完成知识检索。
其核心流程是将文档切分为多个文本块（Chunk），通过向量化（Embedding）存入向量数据库，在用户提问时根据语义相似度检索相关文本，并将检索结果作为上下文提供给大模型生成回答。
这种方式虽然能够有效补充大模型的知识，但仍然存在明显局限：
<ul data-start="295" data-end="371">
<li data-section-id="1pt0isk" data-start="295" data-end="321">检索对象是文本块，只具备语义相似关系；</li>
<li data-section-id="12c8qi7" data-start="322" data-end="344">无法表达实体之间的结构化关系；</li>
<li data-section-id="xrd4fe" data-start="345" data-end="371">对复杂问题（尤其是涉及多步推理的问题）支持较弱。</li>
</ul>
Graph RAG在传统RAG流程的基础上，增加知识图谱作为知识组织方式，将原本以文本块为单位的知识，进一步抽象为 实体（Entity）与关系（Relation） 的结构化表示，从而构建语义网络。
通过这种方式，系统不仅能够检索相关文本信息，还能够理解不同知识实体之间的关联关系。
小结
从系统架构角度来看，无论是向量数据库还是知识图谱，本质上都是为大模型提供外部知识存储能力。
由于大模型本身的知识主要固化在训练参数中，这些知识既难以实时更新，也无法存储企业私有数据。因此，在实际应用中，通常需要构建独立的知识存储体系，为模型提供可持续更新的知识来源。
在AI Agent或知识问答系统中，这类外部知识存储通常被称为长期记忆（Long-term Memory）。
长期记忆用于保存系统在不同任务和时间周期中积累的知识，并在需要时通过检索机制提供给大模型使用，从而支持更复杂的任务处理和推理能力。
目前，常见的长期记忆实现方式主要包括三类：
模型参数微调
通过微调大模型参数，将知识固化在模型内部。这种方式推理效率高，但更新成本较高，且不适合频繁变化的知识。
知识图谱
将知识以 实体—关系—实体 的结构化形式进行存储，形成语义网络。知识图谱擅长表达实体之间的复杂关系，并支持多跳推理。
向量数据库
将非结构化数据（如文档、代码、日志等）转化为向量表示，通过语义相似度检索实现知识获取。向量数据库适合处理大规模文本知识，但不具备复杂关系表达能力。
在实际系统中，这三种方式通常结合使用，共同构建完整的知识记忆体系。
 
 
 
参考 
来源：https://www.cnblogs.com/sss4/p/19737505

頁: [1]

琼殿技术论坛's Archiver

AIAgent开发-LangChain