1. 为什么说“LLM原生回答不了实时信息”RAG存在的根本原因先抛一个反直觉的结论大语言模型本身其实什么“知识”都没有。它只是基于海量训练文本学到的统计规律在做“接龙预测”式的生成。模型内部的参数里确实编码了大量人类知识但有一个致命缺陷——它的知识边界在训练完成那一刻就被冻结了。举个例子我让模型预测某个产品的最新价格它如果训练数据只到去年它就只能靠“猜”猜出来的即使语法通顺、逻辑完整也可能是错的。更要命的是企业内部文档、个人笔记、私有知识库这些数据从来就不在公开训练语料里模型连“猜”的依据都没有。这个问题的本质是模型的参数化记忆parametric memory有容量和时效的双重瓶颈。你不可能把一个公司几千页的规章制度全部塞进Prompt里因为上下文窗口有限成本也扛不住你也没法指望模型“记住”那些它从未见过的私有数据。RAG——Retrieval-Augmented Generation检索增强生成——就是冲着这个痛点来的。它的思路很朴素模型不需要什么都记住它只需要知道“不懂的时候去哪里查”。把知识从模型的“脑子”里搬出来放进一个外部检索系统生成的时候先把相关资料捞出来再让模型基于这些资料来回答。这样带来的直接好处有三个信息时效性提高了因为外部知识库可以随时更新私有数据可控了因为知识可以授权管理幻觉减少了因为模型回答问题时有据可依。我在做某企业客服助手时用上RAG之后回答准确率从纯LLM的六成多直接升到了九成——这个提升幅度靠调Prompt是绝对做不到的。所以如果你正准备用LangChain做RAG第一步要搞清楚的不是代码怎么写而是理解这个架构为什么存在它不是为了“炫技”而是为了解决LLM的固有缺陷。搞明白这一点后面所有的技术选型你都能找到判断依据。2. LangChain在RAG体系里扮演的角色一个并不复杂的编排框架很多人一听到LangChain就觉得是个“大而全”的框架学习成本很高。我用下来最大的感受是它的核心价值就四个字——编排组装。LangChain不实现LLM本身不做向量检索的核心算法它做的事情是把RAG流水线里各个环节“粘”在一起并且把不同厂商的模型、不同种类的向量数据库、不同格式的文档加载器都统一成一套标准接口。2.1 为什么需要编排层直接手搓也不是不行其实RAG流水线自己用原生代码也能写一个文档读取函数、一个文本切分函数、一个Embedding接口、一个向量存储、一个LLM调用再加一个Prompt拼接总共几百行代码就能跑通。我最早做第一个RAG Demo时就是直接用脚本裸写的也没用任何框架。那LangChain的价值在哪里我自己的体会是生态整合省去对接成本。你要用PDF载入器、要用某个向量库、要调特定厂商的LLM接口每个都需要单独读文档、写适配代码。LangChain把这些都封装好了接口风格统一换底层实现只改一两行配置。组件可替换。今天用OpenAI的Embedding明天想换成开源的本地模型今天存FAISS明天换Milvus。标准接口让替换成本大幅下降。提供工程化参考。即使你最终决定不用LangChain阅读它的链式设计、Prompt模板管理方式对你自己设计架构也有很大启发。我见到不少团队把LangChain当成“必须用”的东西其实没必要。如果你只有一个固定场景、数据格式固定、也不打算换服务商裸写反而更轻。但如果你在探索期、需求变化快LangChain能帮你省掉大量重复劳动。2.2 RAG全流程拆解五个关键环节从宏观视角看一条标准的RAG流水线由五个环节组成LangChain都有对应的组件环节职责LangChain对应模块我的选型建议文档加载从各种数据源读取原始内容Document Loaders先按格式选再考虑容错性文本分割把长文档切成适合检索和生成的块Text Splitters优先递归字符分割器向量化存储把文本块转成向量并存入向量库Embeddings Vector Stores中小项目FAISS生产级考虑Milvus检索根据问题找出最相关的文档块Retrievers默认相似度检索进阶用重排序生成把检索结果拼入Prompt交给LLMChains / Prompt Templates注意Prompt里定好“无答案”条件这五个环节环环相扣。大多数人做RAG效果不好最根本的问题不是生成环节而是前三环——文档加载、文本分割、向量化。数据没处理好检索就捞不到好料后面LLM再强也是“巧妇难为无米之炊”。后面我就按这个全流程带着你从零搭建一个最小可用的RAG系统。我会用一套示例文档、一个开源Embedding模型、FAISS向量库和任一主流LLM接口整个过程完整可复现代码可以直接抄。3. 从零搭建一套Minimal RAG完整实操代码与参数说明这一节是整篇文章最核心的部分。我不准备用太复杂的例子而是以一个模拟项目X的知识文档为例搭建一套最小闭环的LangChain RAG系统。所有代码我都在本地跑过你可以照搬也可以根据自己数据调整。先交代一下环境版本。我使用Python 3.10LangChain的版本经历了比较大的迭代老版本用langchain.llms、langchain.embeddings这种路径到了0.1版本以上改成了langchain_community、langchain_openai这种按集成方拆分的包结构。我下面的代码用新版写法如果你还在用旧版注意路径差异。3.1 环境准备与依赖安装我的建议是先用一个干净的虚拟环境避免依赖冲突python -m venv rag_env source rag_env/bin/activate # Windows下执行 rag_env\Scripts\activate pip install langchain langchain-community langchain-openai langchain-text-splitters faiss-cpu python-dotenv这里解释一下每个包的必要性langchain核心框架包含Chain、Prompt模板、LCEL表达式语法langchain-community社区维护的集成组件包括文档加载器里的很多非官方适配langchain-openaiOpenAI系接口的封装也可以用这包接兼容OpenAI协议的其他服务langchain-text-splitters文本分割器新版本从主包独立出来了需要单独装faiss-cpuFAISS向量库的CPU版本本地验证足够用数据量大再考虑GPU版python-dotenv管理API Key避免硬编码到代码里安装完尽量确认一下版本不要差太多LangChain迭代太快了有些API经常调整。如果你装的时候已经出了新版本API有大改优先看对应版的官方文档。3.2 文档加载这一步决定了你能“看到”什么RAG的质量上限从文档加载就定下来了。加载器负责把不同来源的内容转换成统一的Document对象——一个文档里包含page_content正文文本和metadata元数据比如来源路径、页码、标题等。假设你有一批Markdown格式的产品手册最简单的加载方式是目录加载器from langchain_community.document_loaders import DirectoryLoader from langchain_community.document_loaders import TextLoader # 加载指定目录下的所有.md文件 loader DirectoryLoader( ./docs/, glob**/*.md, loader_clsTextLoader, loader_kwargs{encoding: utf-8}, # 中文文档一定注意编码 show_progressTrue, recursiveTrue, # 递归扫描子目录 ) documents loader.load() print(f共加载了 {len(documents)} 个文档) for doc in documents[:3]: print(f来源: {doc.metadata[source]}长度: {len(doc.page_content)} 字符)这里有个非常容易被忽略的坑文档加载的编码问题。中文Markdown文件如果本身是GBK编码而Loader默认按UTF-8读读出来就是乱码。我在第一次跑真实数据时就踩过这坑报错不是乱码而是UnicodeDecodeError排查了半天才想起来服务器上的文件可能是Windows编辑器保存成了GBK。PDF、Word、HTML格式分别对应PyPDFLoader、Docx2txtLoader、BSHTMLLoader它们通常需要先装对应的解析库# PDF from langchain_community.document_loaders import PyPDFLoader loader_pdf PyPDFLoader(./docs/产品说明.pdf) # Word from langchain_community.document_loaders import Docx2txtLoader loader_docx Docx2txtLoader(./docs/操作指南.docx) # HTML from langchain_community.document_loaders import BSHTMLLoader loader_html BSHTMLLoader(./docs/帮助中心.html)加载完成后一种常见做法是把同一来源的多个碎片合并或者至少打上统一的元数据标记。比如source字段统一成相对路径这样检索结果里可以明确告诉用户“这条信息来自哪个文档”。实际做知识库问答时这个来源标注除了方便溯源还能帮你分析检索质量问题——到底哪些文档频繁被命中哪些文档从未被检索到从而优化数据切分。3.3 文本分割一篇文章切成几块直接决定检索命中率文本分割是整个RAG流水线里最容易被低估却又对效果影响最大的一环。分割太粗一个 chunk 里混了多个主题检索时按向量相似度匹配不精准分割太细单个 chunk 信息量不足就算被检回来了LLM也没有足够的上下文来组织答案。LangChain提供了RecursiveCharacterTextSplitter它是通用场景下的默认之选。核心思路是用一个“候选分隔符列表”按优先级从高到低尝试切分尽量保持语义完整。from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每块目标长度按字符数算 chunk_overlap50, # 相邻块之间的重叠长度 separators[\n\n, \n, 。, , , , , ], # 按中文标点优先切 ) chunks text_splitter.split_documents(documents) print(f分割完成共得到 {len(chunks)} 个文档块)参数怎么定我给一个经验参考chunk_size在300-800之间都算合理区间。块太小检索回来的内容常常信息残缺块太大向量表示的语义会被稀释检索精度下降同时塞进Prompt的token也变多。为什么要设置chunk_overlap想想你写文章时的段落过渡——上一段的结尾往往引出了下一段的主题。要是硬生生在“企业介绍”和“产品参数”之间切断检索“企业规模”这个问题时下一块只含产品参数就不容易匹配上。重叠部分像个缓冲带能规避信息断崖。一般取chunk_size的10%-20%即可我常用的配比就是500/50。对于中文文本分隔符列表里一定要加入中文标点。默认的separators是按英文习惯设计的只含换行和空格对中文不友好。你可以在代码里把分隔符扩展成我上面写的那个列表其中“。”和“”的优先级要高于空格这样切出来的块在语义上完整得多。3.4 向量化与存储Embedding模型决定了“语义”算不算数文本块本身无法直接计算相似度需要先转成向量。这一步用的是Embedding模型它的质量直接影响检索效果——向量空间里的“远近”是否真的对应语义上的“相关”全靠它。OpenAI的text-embedding-3-small质量好、调用简单但数据要发到外部服务对隐私敏感的项目不合适。我本地测试常用BAAI/bge-small-zh-v1.5这个开源中文模型几秒钟就能下载完免联网效果也不错。from langchain_community.embeddings import HuggingFaceEmbeddings # 使用开源的bge中文Embedding模型 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, encode_kwargs{normalize_embeddings: True}, # 归一化后内积即余弦相似度 )注意normalize_embeddings这个参数官方建议设成True。归一化之后向量的内积就等于余弦相似度FAISS在做内积检索时效率更高精度不变。向量库我用FAISS原因就俩字省事。它是纯本地运行、单机部署、无需额外启动服务对中小规模文档几十万条以内检索性能完全够。安装用faiss-cpu生产环境如果量大了再换Milvus或Qdrant也不迟LangChain的接口在这些向量库之间切换通常只改一个类名。from langchain_community.vectorstores import FAISS # 建库把分割好的chunks转换并写入向量库 vectorstore FAISS.from_documents( documentschunks, embeddingembeddings, ) # 本地持久化下次直接加载 vectorstore.save_local(./faiss_index) # 重新加载 vectorstore FAISS.load_local( ./faiss_index, embeddings, allow_dangerous_deserializationTrue, # 新版需要此参数 )allow_dangerous_deserializationTrue这个参数是新版才有的因为FAISS索引文件本质是序列化对象官方出于安全考虑默认禁止加载。你自己的实验环境传True没问题但如果是团队共享的、不可信来源的索引文件就要警惕了。3.5 检索与生成把“查到的”变成“答好的”向量库建好之后检索就简单了。直接调用similarity_search传入用户问题返回最相似的top-k文档块。query 项目X的系统支持高并发吗 retrieved_docs vectorstore.similarity_search(query, k4)这里k4意味着每问一个问题会捞出4个相关块。k太小可能漏掉关键信息k太大无关内容混进来的概率上升还会白白消耗Prompt的token预算。我实测普通问答场景k取4-6比较顺手。真正体现LangChain编排能力的是下一步用一个Chain把“检索-组装Prompt-调用LLM-输出”串联起来。新版LangChain主推LCEL表达式语法用|管道符串联组件可读性非常高from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 定义检索器从向量库中检索相关文档 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 2. 定义Prompt模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个严格依据检索资料回答问题的助手。 规则 - 只回答与检索资料相关的问题资料中没有的信息不要推测。 - 如果资料不足以回答用户问题请明确说明根据现有资料无法回答。 - 回答时优先引用资料的原文措辞保持信息准确。 - 请在回答末尾标注信息来源列表。 检索资料 {context}), (human, 用户问题{question}), ]) # 3. 定义一个把检索结果拼接成上下文的函数 def format_docs(docs): return \n\n.join(f[来源: {d.metadata.get(source, 未知)}]\n{d.page_content} for d in docs) # 4. 用LCEL把组件串联成链 rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | ChatOpenAI(modelgpt-4o-mini, temperature0) | StrOutputParser() ) # 5. 调用链 result rag_chain.invoke(项目X的系统支持高并发吗) print(result)这段代码里{context: retriever | format_docs, question: RunnablePassthrough()}是关键。retriever | format_docs表示先执行检索再把检索结果传给format_docs拼成上下文字符串RunnablePassthrough()的作用是把用户原始问题原样透传到Prompt里。为什么LLM的temperature要设为0因为RAG场景下我们要的是“依据资料准确回答”不是“发挥创造力”。temperature越高模型越自由越容易脑补出资料里没有的事实。0的设定下模型几乎只从给定的context里组织语言幻觉风险大大降低。这个参数是RAG应用里最容易被忽视却影响很大的细节。跑通之后你的第一个LangChain RAG系统就成型了。你可以拿几篇自己的文档测试问几个问题看看效果。这时候大概率会发现有回答得很好的问题也有答非所问甚至瞎编的时候。别急着怀疑代码下面的实测踩坑才是真正的重头戏。4. 实测踩坑记录为什么“检索到了”却“回答不好”我的第一个RAG Demo跑通时问了三个问题两个答得不错一个完全答偏。当时我第一反应是“LLM不行”后来排查了一圈发现问题全不在LLM而是出在检索链条上。我把这些坑一一拆开讲每一个都是真实项目里会发生的情况。4.1 检索内容不相关最常见的翻车现场现象问“项目X的数据备份策略是什么”检回来的四个chunk里有两个根本没提“备份”而是讲“部署架构”LLM只能硬着头皮答答得就偏了。根因在哪让chunk之间语义太“糊”。如果原文档里“部署架构”这一节长达几千字切分后多个chunk的向量都高度相似检索前四名里就挤进来好几个。这不是Embedding模型的错而是文档里该主题的内容占比太大稀释了问题的特异性。解决办法有三个方向按效果排序第一精细切分。按文档的章节结构切而不是机械按固定字符数切。Markdown文档可以通过MarkdownHeaderTextSplitter按标题层级分割这样每个chunk天然对应一个完整小节主题聚焦。第二增加检索结果数量再重排。把k从4提到20先捞回足够多的候选再用CrossEncoder重排序模型把真正相关的排到最前取前4个进入Prompt。这种方式比单纯调k效果好得多后面我详细讲。第三问题改写扩充。有些问题表达含糊检索容易跑偏。可以先用LLM把用户问题改写成一个更详细的检索查询再做向量检索。也有的做法是把原始问题和改写后的查询都拿去检索合并结果后去重。4.2 上下文窗口挤压chunk太多反而帮倒忙现象我把k设成8想着多给点资料总没错结果LLM输出越来越冗长还开始“跑题”——因为8个chunk拼出来的context太长有些chunk主题并不相关模型被干扰了。当时我问一个具体型号的参数正确答案就在第三个chunk里但前面两个不相关chunk把Prompt开头的位置占了模型生成时更注意前后文位置靠前的信息。这有点像你看一篇文章开头几段留下的印象最深——LLM也有类似的“注意力偏置”。**这块的教训很直接不是资料越多越好关键信息在Prompt里的位置很重要。**我后来的做法是固定k4-5然后通过重排序把最相关的chunk排到最前面。这样既保证上下文不臃肿又让模型优先看到核心依据。4.3 答案“一本正经地胡说八道”幻觉从何而来你可能会想资料都检索到了LLM照着念不就行了怎么还会编实测中我发现幻觉主要来自三种情况第一种是检索结果里只有部分答案。比如资料里写了“支持每日全量备份”但没写“支持增量备份”用户问“支持增量备份吗”模型会倾向于根据常规知识脑补“支持”而不是老实说“未见明确描述”。这是Prompt规则约束不足导致的——你如果只写“根据资料回答”模型自由度就太高。解法是在Prompt里明确“无中生有”的处罚规则。我用的措辞是“检索资料中没有明确提到的信息一律不要回答统一回复现有资料未涉及该问题。”实测这个简单改动就把幻觉概率降了一大截。第二种是结论型的“合理推断”。资料上说“系统支持水平扩展”模型就推断“因此可以支撑千万级用户”——这一步推断看起来合理实际上资料里根本没有千万级这个数字。对这种“推导型幻觉”目前最有效的还是在Prompt里加“禁止推理补全只能转述资料原文”以及设置低temperature。第三种是检索到的资料本身不完整。比如某页PDF只截到了表格半截数字不全。这种情况靠Prompt措辞已经无解必须回到源头把文档质量问题解决掉。这也是我一直强调“数据优先”的原因。4.4 开源Embedding的中文表现一个需要对齐的预期刚开始我用的Embedding是text-embedding-ada-002英文模型处理中文文档时检索效果堪称灾难——明明语义相关的两句话向量距离却很远。后来换成bge-small-zh-v1.5情况立刻改善但也没有好到“完美”的程度。原因不难理解向量模型是“语义压缩器”它的能力上限取决于训练语料的覆盖程度。中文商业领域文档的专用术语、产品名、缩写开源模型往往训练得不够充分。你在跑通Demo后如果发现某些专业词汇检索总是不准可能不是代码的问题而是Embedding模型的语义覆盖有盲区。换模型是直接解法中文场景可以试bge-m3、text-embedding-3-large多语言版英文技术文档也可以试text-embedding-3-small。对比办法很简单把同一批检索问题分别用不同Embedding模型跑一遍看召回的chunk是不是你要的那几个用脚投票别信参数指标。5. 进阶调优思路让RAG从“能用”到“好用”跑通Demo只能算开始真正上线给人用还差着好几步工程优化。这一节分享我压箱底的几个进阶玩法都是我实际用过的组合。5.1 混合检索向量关键词互补向量检索擅长“语义相关”但有一个明显弱点对精确匹配不敏感。比如文档里全是“CRM系统”这个写法你搜“crm软件”向量检索一般能找到但如果你搜“CRM”全大写向量模型可能觉得和“crm”差不多但关键词检索能精确命中。反过来关键词检索的死穴是同义词和语义改写——你说“如何卸载”文档里写的是“如何移除”关键词就彻底失灵。所以混合检索的思路是向量检索和BM25关键词检索各跑一遍合并结果再去重排序。LangChain里可以用EnsembleRetriever把两者组合from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever bm25_retriever BM25Retriever.from_documents(chunks, k4) vector_retriever vectorstore.as_retriever(search_kwargs{k: 4}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6], # 关键词和语义的权重配比 )权重配比没有标准答案建议先平权重跑起来再根据你数据的特征微调。如果文档里专业术语多、缩写多关键词权重可以调高一点如果文档里口语化表达多、语义改写频繁向量权重应该更高。5.2 重排序检索的最后一道质检混合检索拿到候选集之后质量往往参差不齐。可以做一道“精筛”——用重排序模型Reranker对候选集逐条计算“与问题的相关度分数”按分数降序取top-n进入Prompt。这和Embedding检索的区别在于重排序模型是“带着问题去看文档对”它不是把两边各转成向量再比远近而是把问题和文档拼在一起过一遍交互式模型相关性判断更准代价是速度慢、成本高——所以它只做“精排”不做“粗筛”。HuggingFace上有很多现成的中文重排序模型比如BAAI/bge-reranker-base。用LangChain接入也很简单我常用的写法是from langchain.retrievers import ContextualCompressionRetriever from langchain_community.document_compressors import CrossEncoderReranker from langchain_community.cross_encoders import HuggingFaceCrossEncoder reranker HuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-base) compressor CrossEncoderReranker(modelreranker, top_n4) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrieverensemble_retriever, )top_n4表示经过重排序后只保留最相关的4个chunk进入Prompt。实测这个组合比单一向量检索的回答准确率提高了十多个百分点。代价是每次检索多一次模型推理延迟大约增加几十到几百毫秒看你用的重排序模型大小。对这种“用一点延迟换大幅准确率”的取舍我的倾向是值得的——用户对多等半秒的容忍度远高于对答非所问的容忍度。5.3 多路召回与问题改写小技巧大收益RAG检索失败的一大原因是用户问题太短太含糊。比如用户问“多少钱”如果知识库里的文档写的是“定价方案”向量检索可能匹配不到。最简单的处理是加一个“问题理解”前置步骤把原始问题喂给LLM让它扩写成更明确的检索语句。LangChain里可以用一个子链实现rewrite_prompt ChatPromptTemplate.from_template( 请将用户的模糊问题改写成适合检索的清晰查询。 原始问题{question} 改写要求补全关键实体明确检索的核心主题保持简洁。 改写结果 ) rewrite_chain rewrite_prompt | ChatOpenAI(modelgpt-4o-mini, temperature0)用户问“多少钱”改写后可能是“项目X企业版的定价方案和收费标准”。这样检索时命中率会高很多。建议把改写后的query和原始query分别检索一次合并结果。还有一个容易被忽略的优化是元数据过滤。如果知识库里有多个产品线的文档检索时可以先用元数据比如产品线、文档类型、时间范围把候选集缩小。这样既提高了效率也避免了“问A产品答B产品”的串线问题。LangChain的MultiQueryRetriever、SelfQueryRetriever都是干这类事情的前者用LLM生成多个不同表述的查询后者根据文档元数据自动构造过滤条件值得你深入了解。5.4 关于“向量库选型”的一点个人看法很多教程一上来就推荐Milvus、Weaviate之类的生产级向量库我觉得对绝大多数刚入门的人是个负担。FAISS本地跑够用数据量到了百万级再考虑分布式向量库也不迟。原因很简单RAG的瓶颈通常不在向量检索的吞吐而在数据质量和检索策略。先搞定数据切分、Embedding选择、重排序这些“软功夫”向量库只是存储介质换起来最省事。如果你确实要上生产环境我的建议排序是Qdrant部署简单、Milvus功能全但重、Elasticsearch团队如果本来就有ES加个向量插件就行。选型核心看团队运维能力和数据规模别盲目跟风。写在后面从“跑通Demo”到“上生产”的几道坎最后分享几个我反复踩过、不忍心看你再踩的坑。第一道坎是数据清洗。知识库文档里如果有乱码、重复段落、空章节直接扔进切分器垃圾进垃圾出。我有一回检索“退款政策”结果捞回来一个“退款政策”标题下内容是空的chunkLLM拿着空内容一本正经地编了一百多字政策说明。后来我在加载环节前加了两个预处理去掉HTML标签残留、合并连续空行。第二道坎是评估体系。RAG的效果没法靠“感觉”判断。我建议每个项目都准备三五十条问答作为测试集每次改动后用同一套测试集跑一遍对比检索命中率和回答准确率。没有评估你所有的“优化”都是盲人摸象你根本不知道哪个改动是真正有效还是自我安慰。第三道坎是成本控制。RAG跑起来有两个成本大头Embedding调用和LLM生成。如果查询量很大可以把Embedding模型换成开源本地版省掉每百万token的按量计费如果context太长可以控制chunk数量和大小降低LLM的token消耗。成本控制属于“后置优化”但别等账单炸了才想起这回事。我自己的习惯是LangChain版本升级后先跑一遍回归测试——这个框架迭代是真的快今天能跑的代码半年后可能就有新写法了。给项目留好测试集哪天API变了你能快速知道问题出在哪了。RAG这个方向内容的厚度远超一篇基础文能覆盖的。把基础的流水线跑通、把上面的坑挨个踩明白你就已经超过了大多数停留在“看完教程觉得会了”的人。剩下的就是拿着自己的真实数据去折磨你的RAG系统——它越脆弱你学到的东西越多。
