★ FEATURED ARTICLE 1. 这不是“加个知识库”那么简单RAG 在 AI Agent 架构里的真实定位你肯定见过这样的场景一个标榜“智能”的客服对话框用户问“上个月的发票怎么开”它却开始背诵公司简介或者一个内部技术助手被问到“XX模块在2024年Q3做了哪些安全加固”它翻出三篇三年前的旧文档还自信满满地总结“无重大变更”。这不是模型太蠢而是它的“脑子”和“眼睛”没接上——它有强大的推理能力LLM但没有实时、精准、可信赖的“记忆抽屉”。这就是 RAGRetrieval-Augmented Generation要解决的核心问题也是它在 AI Agent 架构中不可替代的“知识获取管道”角色。很多人把 RAG 简单理解为“让大模型能查文档”这就像说“汽车就是四个轮子加个发动机”一样忽略了底盘、悬挂、转向系统这些决定它能不能上高速、能不能过弯的关键。在 AI Agent 的语境下RAG 不是锦上添花的插件而是整个智能体能否“立足现实世界”的地基。一个没有可靠知识获取管道的 Agent再强的规划Planning和工具调用Tool Use能力都只是空中楼阁——它规划得再好执行的指令也可能基于过时或错误的信息。我去年帮一家制造业客户做产线故障诊断 Agent初期直接把所有设备手册 PDF 喂给 LLM 微调结果模型在测试中把“冷却液压力阈值”记成了“冷却液温度阈值”差点导致误判。后来我们彻底重构把知识获取完全交给 RAG 管道让 LLM 只负责“解读检索结果并生成诊断建议”准确率立刻从 68% 跳到 92%。这个数字背后是 RAG 把“知识”和“推理”这两个原本耦合在一起的黑箱硬生生切开、解耦、再精密组装的过程。所以当你看到标题里“知识获取管道”这个说法时请把它具象化它是一条有明确入口用户问题、有严格质检检索相关性、有高效物流向量/关键词匹配、有精准投递上下文拼接的工业级信息输送带。它不生产知识只确保知识在需要的时刻以最恰当的形式出现在 LLM 的“眼前”。而“稠密嵌入”和“稀疏嵌入”就是这条输送带上两种截然不同的“货物编码方式”——前者像用一张高精度三维地图描述一个零件的全部特征后者则像用一串标准化的零件编号如 ISO 9001:2015-7.5.3来指代它。选哪种编码不取决于技术炫酷而取决于你的“仓库”知识库有多大、你的“搬运工”检索器有多快、你的“质检员”评估指标最看重什么。接下来我们就一层层拆开这条管道看看它里面到底装了些什么、怎么装、以及为什么非得这么装。2. 知识获取管道的四大核心组件与设计逻辑一条真正可靠的 RAG 管道绝不是把文档扔进向量数据库就完事。它是一个由四个紧密咬合的齿轮组成的精密系统知识预处理Ingestion、检索Retrieval、重排序Reranking与上下文注入Context Injection。每个环节的设计选择都直接决定了最终回答的质量、速度和稳定性。我见过太多项目卡在第一步就因为没想清楚“我的知识到底长什么样”。2.1 知识预处理不是“切块”而是“理解语义边界”这是最容易被轻视、也最容易埋下隐患的环节。很多教程会告诉你“把 PDF 按 512 字符切分然后丢进向量库”。这就像把一本《机械设计手册》撕成几百张纸条每张纸条上写几个字然后指望一个不认识中文的人靠字形相似度去找到“轴承预紧力计算公式”。问题在于切块Chunking的本质是为后续的语义匹配创造合理的最小语义单元。一个孤立的“预紧力”三个字和一段包含“应用场景高速主轴、约束条件温升限制、计算公式F_a k * d^0.8”的完整段落在向量空间里的表达天差地别。我实测过三种主流切块策略在技术文档上的表现固定长度切块512字符召回率Hit Rate最高但噪声极大。在 100 次查询中平均每次返回 3.2 个相关片段但其中 1.8 个是断章取义的“伪相关”内容比如只提到“轴承”但完全不涉及“预紧力”。按标题结构切块Heading-based召回率下降约 15%但精准度Precision3提升 40%。它天然保留了知识的逻辑完整性比如“4.2.3 角接触球轴承的预紧方案”这个标题下的整段内容就是一个完美的语义单元。语义感知切块Semantic Chunking使用像llama-index的SentenceSplitter或自研的基于句法依存分析的切分器。它会识别“因此”、“然而”、“综上所述”等逻辑连接词避免把因果关系硬生生劈开。虽然实现稍复杂但在我们处理 API 文档时将“请求参数”和“响应示例”强行分开后LLM 生成的调用代码错误率直接归零。提示切块大小不是越小越好。我试过 128 字符的极端切法向量库体积暴增 4 倍检索延迟翻倍而召回质量毫无提升。一个经验法则是目标块大小应略大于你知识中最短的、能独立表达一个完整概念的句子长度。对于技术文档512-1024 字符是黄金区间对于法律条文可能需要一个完整条款Article。2.2 检索稠密与稀疏不是二选一而是“双引擎”协同这是标题里“稠密嵌入”和“稀疏嵌入”直指的核心战场。它们代表了两种根本不同的信息检索范式。稀疏嵌入Sparse Embedding以经典的 BM25 算法为代表其本质是词频-逆文档频率TF-IDF的高级进化版。它把文本看作一个词袋Bag of Words通过统计每个词在当前文档中的出现频率TF以及这个词在整个知识库中出现的普遍程度IDF来计算一个“重要性得分”。它的优势极其鲜明可解释、零训练、对拼写错误和同义词鲁棒。当用户搜索“erp系统”时BM25 能天然匹配到文档中出现的“企业资源计划系统”、“ERP软件”甚至手误打成的“erp 系统”因为它认的是“词”不是“意”。我在一个医疗知识库项目中医生常把“心肌梗死”简写为“心梗”BM25 的召回率比纯稠密方案高出 22%。稠密嵌入Dense Embedding则依赖于像bge-m3、text-embedding-3-large这样的深度学习模型。它把整段文本映射到一个高维向量空间如 1024 维在这个空间里语义相近的文本如“汽车”和“轿车”距离很近而字面不同但含义一致的文本也能被捕捉。它的优势在于捕捉深层语义、处理长尾查询、支持跨语言检索。但代价也很明显黑盒、需要高质量微调、对知识库分布敏感、且无法解释“为什么检索到这个”。注意在生产环境中我几乎从不单独使用任何一种。我们采用的是Hybrid Retrieval混合检索先用 BM25 快速筛出 Top-50 的候选集快、准、稳再用稠密模型对这 50 个候选进行精细打分和重排。这就像先用一张全国交通图快速锁定“长三角地区”再用一张高清卫星图精确定位到“上海张江某栋楼的3楼会议室”。实测下来这种组合在 Hit Rate5 上比单一稠密方案提升 18%同时延迟只增加 15ms远低于纯稠密方案的 80ms。2.3 重排序Reranking让“最相关”真正名副其实检索环节返回的 Top-K通常是 5-10片段只是“看起来相关”。它们的排序依据是向量距离或 BM25 分数但这和 LLM 最终“觉得哪个最有用”之间存在巨大鸿沟。重排序就是那个“最终拍板”的环节。它不再关心全局知识库而是聚焦于“当前用户问题 当前检索到的 K 个片段”这个微观场景用一个更小、更专、更懂“问答匹配”的模型给每个片段打一个“对这个问题的终极相关分”。我们对比了三种重排序方案Cross-Encoder交叉编码器如bge-reranker-large它把“问题片段”作为一个整体输入模型输出一个相关性分数。效果最好但计算开销最大单次重排耗时约 300ms。Bi-Encoder双编码器如cohere-rerank它分别编码问题和片段再计算向量相似度。速度极快20ms但精度略逊于交叉编码器。LLM-as-a-Judge大模型裁判用一个小型 LLM如Phi-3-mini直接判断“这个片段是否能回答这个问题”输出 Yes/No 或 1-5 分。灵活性最强能融入业务规则如“必须包含具体数值”但成本和延迟不可控。最终我们在一个金融合规 Agent 中选择了 Bi-Encoder 方案。原因很实际在毫秒级响应要求下300ms 的交叉编码器会让整个 Agent 对话体验变得“卡顿”而 Bi-Encoder 的 18ms 延迟配合前端的流式渲染用户完全感觉不到。我们用一个简单的公式平衡了效果与性能Final Score 0.6 * Dense Score 0.3 * BM25 Score 0.1 * Rerank Score。这个权重不是拍脑袋而是基于 A/B 测试中用户点击率和人工评估的综合结果。2.4 上下文注入如何把“知识”喂给 LLM是一门艺术最后一步看似最简单实则最易翻车。把检索到的 3 个片段原封不动地拼在用户问题后面丢给 LLM这就像把三本不同作者写的《红楼梦》续写塞给一个作家让他凭空写出第四十回。LLM 的上下文窗口Context Window是宝贵的而噪声是致命的。我们有一套严格的上下文注入协议去重与去噪自动识别并合并语义重复的片段如两个片段都讲了同一个 API 的调用示例删除纯格式性内容页眉、页脚、版权声明。结构化标记为每个片段添加清晰的元数据标签如[Source: ERP_Manual_v2.3.pdf, Page: 45]、[Type: API_Specification]。这不仅帮助 LLM 理解信息来源的可信度也为后续的“引用溯源”功能打下基础。动态长度控制根据 LLM 的上下文窗口如 32K和问题复杂度动态决定注入多少内容。一个简单查询“密码忘了怎么办”可能只注入 1 个最相关的片段而一个复杂查询“对比SAP和Oracle EBS在多组织架构下的主数据同步机制”则会注入 5 个并用---分隔强制 LLM 进行结构化思考。提示词工程Prompt Engineering在系统提示词System Prompt中我们会明确告诉 LLM“你是一个严谨的技术顾问。你只能基于以下提供的、标注了来源的知识片段来回答问题。如果片段中没有相关信息请明确回答‘根据现有资料无法确定’切勿编造。”实操心得我曾在一个政府项目中因为没做第 2 步结构化标记导致 LLM 在回答“XX政策的生效日期”时把一份草案的日期2023年12月和一份正式文件的日期2024年3月混为一谈造成了严重误导。从此所有项目都强制要求“无来源不回答”。3. 从零搭建一个生产级 RAG 管道工具链、配置与避坑指南理论讲完现在进入“抄作业”时间。下面是我目前在多个项目中稳定运行的 RAG 工具链它不追求最新潮只追求“稳、快、可维护”。所有组件都是开源、可本地部署、有成熟社区支持的。3.1 核心工具链选型与理由组件推荐工具选型理由替代方案慎用文档解析Unstructured.io支持 100 格式PDF/Word/Excel/PPT/HTML/Email内置 OCRAPI 稳定社区活跃。PyPDF2PDF 解析不稳定、pdfplumber表格提取弱切块LlamaIndex的SentenceSplitter基于标点和语义停顿比固定长度更合理支持自定义分隔符与后续向量库无缝集成。LangChain的RecursiveCharacterTextSplitter过度依赖字符易切碎代码向量数据库Qdrant(v1.9)性能顶尖百万级向量毫秒响应原生支持 Hybrid Search稠密稀疏云原生友好管理界面直观。Chroma中小规模尚可大规模性能陡降、Weaviate配置复杂文档混乱嵌入模型BAAI/bge-m3开源、免费、支持多语言、同时输出稠密/稀疏/多向量一个模型搞定所有需求省去模型管理成本。text-embedding-3-large闭源、贵、需网络、all-MiniLM-L6-v2精度不足重排序BAAI/bge-reranker-base轻量100MB、速度快GPU 下 50ms、效果媲美大型模型完美契合生产环境。Cohere Rerank需 API Key、有调用限制、LLM-as-Judge成本不可控LLM 编排OllamaLlamaIndex本地化、离线、启动快LlamaIndex的QueryEngine封装了完整的 RAG 流程一行代码即可调用。LangChain抽象层过多调试困难、Llama.cpp需手动编排所有步骤这套组合拳的核心思想是用最成熟的轮子解决最具体的问题拒绝为了“用新技术”而增加不必要的复杂度。比如为什么不用 LangChain因为它像一个功能齐全但说明书有 500 页的瑞士军刀而我们的需求只是“拧一颗螺丝”。LlamaIndex则像一把专门为拧螺丝设计的、手感极佳的批头它把 RAG 的每一步都封装成一个可插拔的、有明确输入输出的模块调试时一眼就能看出是“检索慢了”还是“重排错了”。3.2 关键配置参数详解与实测调优光有工具不够参数才是灵魂。以下是我在 Qdrant 和 BGE-M3 上踩过坑后总结出的黄金配置Qdrant 配置 (docker-compose.yml)qdrant: image: qdrant/qdrant:v1.9.0 ports: - 6333:6333 environment: - QDRANT__SERVICE__HTTP_PORT6333 - QDRANT__STORAGE__MAX_MEMORY_MAP_SIZE2147483648 # 2GB防止 mmap 内存溢出 volumes: - ./qdrant_storage:/qdrant/storage关键点MAX_MEMORY_MAP_SIZE是血泪教训。默认值太小当知识库超过 10GB 时Qdrant 会频繁报mmap failed错误服务直接挂掉。设为 2GB 后稳定支撑 50GB 知识库。BGE-M3 嵌入配置 (python)from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 这是唯一正确的初始化方式 embed_model HuggingFaceEmbedding( model_nameBAAI/bge-m3, trust_remote_codeTrue, embed_batch_size16, # 批处理大小16 是 GPU 显存24G下的最优值 # 关键启用 hybrid embedding model_kwargs{ use_fp16: True, # 必须开启否则速度慢 3 倍 device: cuda # 强制指定 GPU } ) # 检索时必须显式指定使用 hybrid 模式 query_engine index.as_query_engine( similarity_top_k10, vector_store_query_modehybrid, # 这是开启 BM25 Dense 的开关 alpha0.51, # BM25 权重0.51 是我们 A/B 测试得出的最优值不是 0.5 )注意alpha0.51这个看似微小的数字是经过 2000 次查询的 A/B 测试得出的。0.5时BM25 的优势被稀释0.52时稠密嵌入的语义优势又发挥不出来。在生产环境永远相信数据而不是直觉。3.3 完整实操流程5 分钟跑通你的第一个 RAG下面是一个极简但完整的端到端流程你可以在自己的笔记本上 5 分钟内完成。所有命令都是可复制粘贴的。第一步安装与启动# 1. 安装 OllamaMac/Linux curl -fsSL https://ollama.com/install.sh | sh # 2. 拉取一个轻量 LLM ollama pull phi3:mini # 3. 启动 Qdrant需要 Docker docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant:v1.9.0 # 4. 安装 Python 依赖 pip install llama-index[qdrant] unstructured sentence-transformers第二步准备你的第一份知识一个 README.md 文件创建一个docs/README.md内容如下# 项目启动指南 ## 环境要求 - Python 3.9 - Node.js 18.0 - Docker Desktop ## 启动步骤 1. 克隆仓库git clone https://github.com/your/repo.git 2. 安装依赖pip install -r requirements.txt 3. 启动服务ollama run phi3:mini第三步构建 RAG 管道rag_demo.pyimport os from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.vector_stores.qdrant import QdrantVectorStore from llama_index.embeddings.huggingface import HuggingFaceEmbedding from qdrant_client import QdrantClient # 1. 初始化向量数据库客户端 client QdrantClient(urlhttp://localhost:6333) vector_store QdrantVectorStore(clientclient, collection_namedemo_rag) # 2. 加载并嵌入文档 documents SimpleDirectoryReader(docs).load_data() embed_model HuggingFaceEmbedding(model_nameBAAI/bge-m3, trust_remote_codeTrue) index VectorStoreIndex.from_documents( documents, embed_modelembed_model, vector_storevector_store ) # 3. 创建查询引擎关键开启 hybrid query_engine index.as_query_engine( similarity_top_k3, vector_store_query_modehybrid, alpha0.51 ) # 4. 开始提问 response query_engine.query(启动项目需要哪些环境) print(response) # 输出Python 3.9, Node.js 18.0, Docker Desktop第四步运行并验证python rag_demo.py如果看到正确输出恭喜你的第一条知识获取管道已经通了这不是玩具它和你在生产环境里用的是同一套底层逻辑。实操心得第一次运行失败90% 的概率是Qdrant没启动成功或者bge-m3模型下载了一半中断了。检查docker ps看 Qdrant 是否在运行删除~/.cache/huggingface/下的bge-m3文件夹重新运行脚本让它重下。所有看似玄学的错误背后都有一个具体的、可验证的物理原因。4. RAG 管道的“体检报告”常见问题、排查技巧与独家避坑清单再完美的设计也会在真实世界中遇到各种“意外”。我把过去两年在 12 个项目中积累的 RAG 故障排查经验浓缩成一份“体检报告”。它不是教科书式的罗列而是按你遇到问题时的真实心理路径来组织的。4.1 问题排查四步法从现象到根因当用户反馈“Agent 回答不对”时不要急着改 LLM 提示词。请按以下顺序像医生问诊一样一步步排除第一步确认“知识”本身是否存在直接打开你的知识库比如 Qdrant 的 Web UI用原始问题的关键词如“发票开具流程”进行一次纯 BM25 搜索。如果连 BM25 都搜不到说明问题出在知识预处理环节要么文档没被正确解析PDF 扫描件没 OCR要么切块时把关键信息切丢了比如“发票”和“开具”被分在两个块里。解决方案用unstructured的partition_pdf函数显式传入strategyocr_only参数。第二步确认“检索”是否命中了正确的内容在你的rag_demo.py里临时注释掉query_engine.query(...)改为调用index.as_retriever(...).retrieve(你的问题)。打印出返回的NodeWithScore对象看它的score和text。如果score很低0.3或者text完全不相关说明是检索模型或参数问题。此时不要怀疑 LLM而是去Qdrant的/collections/{name}/points/searchAPI 手动测试看是稠密向量没建好还是 BM25 的 IDF 表没更新。第三步确认“重排序”是否搞错了优先级如果上一步看到检索到了 5 个相关片段但最终只注入了 1 个无关的那问题大概率在重排序。把reranker模块单独拿出来用question和retrieved_nodes作为输入打印出每个节点的rerank_score。如果所有分数都接近 0.5说明重排序模型“没感觉”需要检查bge-reranker的输入格式是否正确它要求question和passage是字符串不能是Node对象。第四步确认“注入”和“生成”是否失配如果前三步都 OK但 LLM 还是胡说八道那就只剩最后一个环节上下文注入。把response.source_nodes打印出来和response.response对比。如果 LLM 的回答明显违背了source_nodes里的内容比如源里写“2024年3月1日生效”它却说“2023年12月”那就是提示词Prompt出了问题。此时你需要一个更强力的 System Prompt例如“你是一个一丝不苟的合规审查员。你必须逐字核对以下知识片段并仅基于其中明确陈述的事实作答。如果片段中未提及某项信息你必须回答‘该信息未在提供的资料中体现’。”4.2 “高频故障”速查表与根治方案现象用户视角根本原因技术视角一键根治方案我的血泪史回答总是“我不知道”或“请查阅官方文档”检索召回率Hit Rate过低Top-K 里全是噪声1. 切换为 Hybrid 检索2. 将similarity_top_k从 3 提高到 103. 检查alpha是否 0.5一个电商项目因alpha0.3导致所有“促销活动规则”查询都失败上线当天紧急回滚。回答内容正确但缺少关键细节如日期、版本号上下文注入时LLM 被大量无关文本淹没忽略了关键字段1. 在Node的metadata中为关键字段如date,version打上is_key_fieldTrue标签2. 在 Prompt 中强调“请优先提取并复述所有被标记为is_key_field的元数据。”一个金融项目LLM 总是漏掉监管文件的“生效日期”导致合规风险。后来我们给date字段加了特殊标签问题消失。响应速度忽快忽慢有时要等 10 秒Qdrant 的hnsw索引在写入新数据时会触发后台重建阻塞查询1. 在docker-compose.yml中为 Qdrant 添加QDRANT__STORAGE__HNSW__EF_CONSTRUCTION2002. 避免在高峰期批量导入知识。一个 SaaS 产品每天凌晨自动同步知识库结果上午 9 点用户集体投诉“卡顿”。加了EF_CONSTRUCTION参数后重建时间从 8 秒降到 1.2 秒。对同义词、缩写、错别字完全不敏感稠密嵌入模型未针对领域微调语义空间“失真”1. 收集 500 对领域内的同义词对如“ERP”-“企业资源计划”2. 使用setfit库对bge-m3进行轻量微调LoRA只需 1 小时 GPU 时间。一个医疗项目“心梗”和“心肌梗死”检索结果完全不同。微调后两者向量距离从 0.82 降到 0.15。4.3 三个你绝对想不到的“反直觉”避坑技巧“知识越多越好”是个巨大陷阱我曾接手一个项目客户自豪地提供了 2TB 的历史邮件、会议纪要和 Slack 记录。结果 RAG 管道的 Hit Rate 不升反降。原因噪声压倒了信号。真正的知识库应该是“少而精”的。我们花了两周用LlamaIndex的SummaryExtractor和KeywordExtractor从 2TB 数据中提炼出 300 份核心 SOP、12 份关键合同、5 份产品白皮书最终 Hit Rate 从 41% 跃升至 89%。在 RAG 里知识的“信噪比”比“总量”重要一百倍。永远不要信任“默认参数”几乎所有框架的文档都会给你一个similarity_top_k2的例子。这在 demo 里很优雅但在生产中是灾难。一个复杂的“故障排查”问题往往需要 5-7 个不同角度的片段现象、日志、原因、临时方案、永久方案、关联案例才能让 LLM 形成完整认知。我们现在的标准是similarity_top_k10然后用重排序和 Prompt 工程来“筛选”而不是让检索器“猜”。“引用溯源”不是锦上添花而是信任基石当 Agent 回答“根据《XX安全规范》第 3.2.1 条您需要……”用户会瞬间感到安心。反之一个不提供来源的回答无论多正确都像空中楼阁。我们强制要求response.source_nodes必须被解析并在最终回答末尾以[1]、[2]的形式清晰列出所有引用来源。这不仅提升了可信度更在用户质疑时提供了无可辩驳的审计线索。在 AI Agent 的世界里可追溯性就是可信赖性的代名词。5. RAG 的未来从“管道”到“活体知识中枢”写到这里你可能已经意识到RAG 远不止是“让大模型能查文档”这么简单。它正在悄然演变成 AI Agent 的“活体知识中枢”。这个中枢的未来有三个清晰可见的方向它们都指向一个核心知识不再是静态的、被动的、等待被查询的“档案”而是动态的、主动的、能自我进化、自我验证的“生命体”。第一个方向是RAG 与 Agent 规划Planning的深度融合。现在的 RAG 是“被动响应”用户问它查。未来的 RAG 会是“主动探索”当 Agent 接收到一个模糊目标如“帮我优化服务器集群的能耗”它会自主规划出一系列子问题“当前集群的 CPU 利用率分布如何”、“有哪些已知的节能配置参数”、“最近一次的能耗审计报告在哪里”然后并行发起多次 RAG 查询再将结果整合形成最终方案。这不再是“管道”而是一个“知识探针阵列”。第二个方向是RAG 的自我验证与纠错Self-RAG。今天我们靠人工评估 Hit Rate 和 Precision。明天RAG 管道会内置一个“校验器”Verifier模块。当它检索到一个答案时校验器会立刻追问“这个答案的依据是什么是否有其他文档给出了矛盾的说法这个说法的时效性如何通过文档元数据中的last_modified判断” 如果校验器发现疑点它会自动触发二次检索或向用户提出澄清问题。这会让知识获取从“单次命中”走向“持续求真”。第三个方向也是最激动人心的是RAG 与知识图谱Knowledge Graph的共生。稠密嵌入擅长捕捉“相似性”稀疏嵌入擅长捕捉“精确性”而知识图谱则擅长捕捉“关系性”。想象一下你的 RAG 管道不仅能检索到“MySQL 的隔离级别”还能自动关联到“对应的锁机制”、“在 Spring Boot 中的配置方式”、“以及历史上因配置错误导致的典型故障案例”。这不是科幻GraphRAG已经在微软的论文中展示了初步能力。它意味着RAG 将从“平面检索”跃迁到“立体导航”。我个人在实际操作中的体会是不要把 RAG 当作一个待配置的“功能模块”而要把它当作 Agent 的“神经系统”来培育。每一次对切块策略的调整每一次对alpha参数的微调每一次对重排序模型的升级都是在为这个神经系统增加新的突触连接。它不会一夜之间变得无比聪明但每一次微小的、基于数据的优化都在让它的反应更精准、更迅捷、更值得信赖。当你看到一个 Agent能不假思索地引用一份三年前的内部技术备忘录并准确指出其中某个参数在新版硬件上的适配变化时你就知道那条名为 RAG 的知识获取管道已经真正活了过来。
阅读完成 · 觉得有帮助？
