★ FEATURED ARTICLE 先说一个我在圈子里观察到的现象RAG相关的教程、开源项目、峰会分享越来越多但大部分人学完之后依然卡在“能跑 demo做不了产品”的阶段。原因很简单多数教程在讲检索增强生成的基本链路——向量化、召回、拼接提示词——然后就结束了真正决定线上效果的工程细节比如知识库类型怎么选、分块参数怎么调、召回结果怎么重排、置信度怎么评估几乎没有涉及。这正是我想把《RAG进阶实战》做成一个系统专栏的原因不是教大家认识 RAG而是带着大家把 RAG 真正用起来解决实际业务里的问题。这个专栏面向的是已经入门 RAG、希望在真实项目中做出稳定效果的开发者、算法工程师和技术负责人。内容会把“进阶”拆成两条线一条是技术深度线涵盖知识库选型、解析分块、召回重排、评估调优、性能优化这些硬核环节另一条是场景落地线针对知识库存图片、Ontology RAG、Mac 本地搭建、框架选型这类高频真实需求给出可直接复现的解决方案。如果你工作里正在被“检索不准、回答幻觉、知识更新不及时”折磨这个专栏的大纲和执行思路应该能帮上大忙。1. 为什么要做 RAG 进阶实战专栏1.1 从 Demo 到生产RAG 落地的真实瓶颈先泼一盆冷水。RAG 的入门链路确实短调一个 OpenAI Embedding 接口把文档切一切塞进向量库再写几十行检索代码一个看起来像模像样的问答系统就能跑起来。但一旦放到生产环境你很快就会撞上一连串问题检索召回的结果和问题不相关top_k 拉高之后混进来大量噪音片段切分方式不当把一个完整的知识点拦腰截断生成阶段根本拼不出正确答案多个知识片段之间存在矛盾模型不知道该信谁知识库更新后旧向量没有及时清理检索结果出现明显“过期信息”系统延迟太高一次问答要等四五秒完全没法上线缺少评估手段每次改参数都靠感觉不知道效果是变好还是变坏。这些问题单独拿出来每一个都不算“高深”但它们组合在一起就是大家常说的“RAG 瓶颈”。进阶实战不是去学一个新框架、新模型而是把这些瓶颈逐个拆开搞清楚背后的原理再用工程手段把它们一一解决。专栏的核心任务就在于此。1.2 专栏定位写给谁、解决什么问题在规划《RAG进阶实战》内容的时候我给自己定了一个很明确的读者画像已经跑通过一个基础 RAG 项目但正在为效果不稳定、上线困难而头疼的人。具体来说大致有三类读者第一种是在业务系统里集成 RAG 功能的研发需要处理大量内部文档、客服知识库最关心召回准确率和系统稳定性第二种是算法工程师研究重点在 Embedding 微调、重排模型、Agent 与 RAG 结合这类偏深度的问题第三种是技术决策者需要做知识库方案选型比如到底用向量库、图数据库还是传统关系型数据库以及评估 RAG 投入产出比。针对这三类读者专栏采用了“问题驱动 项目实战”的编排思路。每一篇都从一个真实场景的问题切入比如“知识库里的图片能不能被检索到”再把背后的原理讲透最后给出一套可以照着做的工程方案。这样做的好处是读者不需要按顺序从头读到尾遇到问题可以直接跳到自己关心的章节找答案每篇文章本身就是一个可以独立落地的项目。1.3 专栏内容与当前社区热点的呼应我重新梳理了近期大家在搜索引擎和社区里反复提问的关键词发现几个非常集中的关注方向RAG 瓶颈怎么破、知识库与结构知识库怎么区分和应用、RAG 知识库能不能存图片、RAG 框架怎么选、如何用 Mac 搭建本地 RAG 知识库、Ontology RAG 是什么。这些不是凭空出现的疑问而是大家在实践中遇到的共性问题。专栏的内容编排和这些热点做了明确呼应知识库类型辨析会被放在开篇作为整个选型的地基Multimodal RAG 和图片存储会单独成篇Mac 本地部署会作为实战章节的一篇完整教程RAG 框架选型会结合 LangChain、LlamaIndex、RAGFlow 等主流方案做对比。专栏不是站在高处讲概念而是把你搜过的问题都变成一章一章实实在在的内容这一点从大纲就能看出来。2. 专栏整体架构与内容编排思路2.1 九周进阶路线图从索引构建到在线服务设计专栏大纲时我参考了企业落地 RAG 的完整生命周期将整个进阶过程拆分成了九个阶段对应九周的内容输出。每周一个主题前五周偏技术基建后四周偏工程交付周次主题核心内容产出物Week 1知识库选型向量库、结构库、知识图谱的区分与场景选择选型决策表Week 2文档解析与分块PDF/Word/HTML 解析、chunk 策略与参数调优分块工具与实验报告Week 3Embedding 选型与调优开源/商用模型对比、领域微调、维度选择Embedding 评测结果Week 4召回与重排混合检索、Rerank 模型、融合策略混合检索模块Week 5生成与提示工程Prompt 模板优化、引用溯源、幻觉抑制高质量生成模板Week 6评估体系搭建命中率、忠实度、答案相关性等指标与评测集离线评估脚本Week 7多模态与图谱增强图片/表格检索、Ontology RAG、GraphRAG多模态检索 DemoWeek 8性能优化与缓存向量索引优化、语义缓存、并发控制性能测试报告Week 9部署与监控Docker 化、日志追踪、线上效果回归部署方案文档这个路线图不是随意排的它遵循了一个逻辑先解决“知识怎么存”再解决“知识怎么找”接着解决“答案怎么生成”最后解决“系统怎么稳定跑”。很多人在进阶时走弯路就是因为跳过了第一步在没想清楚知识库类型的情况下直接开始做向量化后面做再多优化都像在沙地上盖楼。专栏的第一个模块把知识库选型单独拎出来也是这个原因。2.2 每篇文章的标准结构问题场景、原理拆解、实操步骤、调参经验、工程化注意点专栏文章不是想到哪儿写到哪儿我提前定了一套统一的内容框架每篇文章都包含六个模块。第一个模块是问题场景描述真实业务里会遇到的具体问题第二个模块讲解核心原理把机制和逻辑讲透第三个模块给实操步骤包括环境准备、代码和配置第四个模块是调参经验记录参数变化对效果的实际影响第五个模块专门写工程化注意点讨论和线上部署相关的坑最后一个模块是思考题帮助读者巩固理解。以“分块策略”这篇文章为例场景部分会描述“为什么把文档切分成 512 字的片段后很多回答变得支离破碎”原理部分会解释 token 限制、语义完整性和检索粒度之间的关系实操部分会给出字符切分、递归切分、语义切分三种方式的代码调参部分会对比 chunk_size 在 128、256、512、1024 下的检索命中率工程化部分会讨论分块结果如何缓存、增量文档如何更新思考题部分会让读者结合自己的文档类型设计一个分块实验。这种结构让每篇文章既有深度又保持可操作性。2.3 为什么把知识库类型辨析作为开篇第一周的内容是整个专栏里最“不性感”但最关键的一篇。热搜词里反复出现的“知识库和结构知识库区分以及应用场景”说明很多人连最基础的概念都还没有完全理清。作为进阶专栏开篇必须帮大家把地基夯实。知识库类型辨析的核心在于回答三个问题数据以什么形态存在用户以什么方式提问答案需要什么粒度的推理如果数据是产品说明书、技术文档这种非结构化文本用户的问题是开放式的语义搜索答案需要对多个段落进行综合那么向量知识库是首选如果数据是订单记录、用户信息这种高度结构化的表格查询模式是精确匹配和聚合统计那么关系型数据库或者专门的表格检索方案更合适如果数据涉及复杂的实体关系例如“某供应商的某零件应用于某型号设备”需要多跳推理那么知识图谱就派上了用场。这三类知识库不冲突实际系统中经常配合使用。开篇把这层关系讲清楚后面所有涉及检索、重排、混合方案的内容才有一个统一的出发点。3. 热词背后的核心技术点拆解3.1 向量知识库、结构知识库与知识图谱到底怎么选很多人把“RAG 知识库”和“向量数据库”画等号这是最常见的认知误区。我见过不止一个团队把所有数据都塞进向量库结果面对精确查询时效果一塌糊涂。先把三类知识库的区别搞清楚比多调几个参数重要得多。从数据形态、查询方式、优势场景三个维度来看它们的差异非常明显。向量知识库处理的是非结构化数据通过 Embedding 模型把文本变成向量再通过近似最近邻搜索找到语义相似的片段。它的优势在于不需要预定义 schema接进来就能用适合 FAQ、文档问答、语义搜索这类场景。但它对精确匹配无能为力你说“查询订单 OF20240015 的状态”向量检索大概率会返回一堆包含这个数字但语义不相关的段落。结构知识库处理的是有明确字段定义的数据核心特征是结构化查询。业务系统中的 MySQL、PostgreSQL 都属于这一类。在 RAG 场景里结构知识库不是直接替代码生成而是通过 Text2SQL 把自然语言转换成 SQL 查询再去数据库里精确取数。它的优势是准确、可控、支持复杂条件过滤适合报表查询、经营分析、用户信息检索等场景。知识图谱以实体和关系为基本单元存储的是结构化的语义网络。它和结构知识库的区别在于图结构特别擅长多跳关系推理。比如用户问“哪些供应商供应的原材料被用于 A 型号产品且这些供应商位于华东地区”这种问题在关系型数据库里需要多次 Join而图谱可以用一条路径查询完成。知识图谱的短板是构建成本高需要本体设计、实体抽取和关系抽取冷启动周期长。选型的核心判断依据就一句话看你的问题和数据最匹配哪种查询模式。以我自己的实践经验多数企业内部知识库是混合形态文档类内容用向量库指标类内容用结构库关系推理类内容用图谱。进阶实战中的关键能力其实是能把多种知识源组合到一个 RAG 流程里。3.2 Ontology RAG用本体约束检索告别纯向量匹配Ontology RAG 是这轮热搜里含金量比较高的一个方向。简单理解Ontology 是对某一领域内实体、概念、关系、属性的显式规范定义。它不同于传统的知识图谱实例数据Ontology 更像是一个“元模型”用来约束“这个领域里有哪些重要概念、概念之间允许哪些关系、每个概念有哪些属性”。在 RAG 流程里引入 Ontology本质是给检索加了一层约束。举个实际场景医疗领域的知识库里有药品、疾病、症状、检查指标等实体如果只做向量检索用户问“服用阿司匹林后出现胃部不适怎么办”系统可能召回一堆关于阿司匹林药理学、胃溃疡治疗等知识片段相关性参差不齐。但如果建立了 Ontology定义了“药品-不良反应-症状”这个关系路径检索就不只是语义相似度的较量而是会优先沿着合法关系路径查找与该患者问题最相关的片段。具体实现上Ontology 可以作用于多个环节。在查询理解阶段用 Ontology 识别问题中的实体类型把“胃部不适”映射到“症状”类实体在召回阶段向量检索之外增加基于实体关系路径的图遍历召回把结果合并去重在排序阶段用 Ontology 定义的关系距离辅助重排缩短与查询实体关系路径的片段得分更高。从实践成本来看Ontology RAG 门槛不低因为要把领域知识抽象成本体需要领域专家参与。但凡是知识结构稳定的垂直场景比如医疗、法律、工业制造它带来的收益非常显著能大幅减少纯向量检索导致的低相关片段混入。进阶专栏会把 Ontology 和 GraphRAG 的构建方法放在同一章里讲便于读者对照区分。3.3 RAG 知识库能存图片吗多模态 RAG 的落地思路“RAG 知识库能存储图片嘛”是大家高频搜索的问题背后的真实需求是我有大量带图片的产品手册、技术文档希望用户问一个问题时系统不仅返回文字答案还能把相关的图和结构一起找回来。答案是能而且已经有比较成熟的技术路线但要注意它和普通文本 RAG 的区别。先明确一点这里说的图片不是指用 OCR 把图片里的文字识别出来塞进向量库那是伪多模态。真正的图片语义检索靠的是多模态 Embedding 模型例如 CLIP 或者更现代的图文对齐模型它们可以把图片和文字映射到同一个向量空间文本查询“发电机组冷却系统结构图”和对应的图片向量在空间里距离很近可以直接用相似度检索。实际落地的多模态 RAG 数据流程通常是这样的文档解析阶段把嵌入的图片抽取出来用多模态模型生成图片的描述信息并同步生成图片向量索引阶段图片向量和文本向量存放在同一个向量库中通过 metadata 区分数据类型检索阶段文本查询向量分别和文本索引、图片索引做检索再把两类结果合并重排生成阶段把召回的图片路径或者 Base64 数据放进提示词让多模态 LLM 生成带图引用答案。这套流程在前面的路线图里对应 Week 7 的多模态增强模块。需要注意的坑有几个多模态 Embedding 模型对图片的语义理解仍然有限复杂的图表可能需要额外的表格结构解析图片检索的召回和文本检索的融合排序没有统一标准通常要针对场景调权重大模型对多张图片同时理解和引用图片中具体位置的能力还比较弱生成环节的提示词设计需要特别留意。总体而言图片存储在 RAG 知识库里技术上可行但它依赖整套多模态链路不是简单改一个字段就能完成的。4. 亲手搭建一套 RAG 知识库Mac 本地实操4.1 方案选型为什么用 Ollama LlamaIndex Chroma提到“怎么在 Mac 上搭建 RAG 知识库”很多人第一反应是装 Elasticsearch 和 Milvus但那是过重的方案。本地开发调试阶段我更推荐一套轻量组合Ollama 负责本地运行开源 LLM 和 Embedding 模型Chroma 作为轻量向量库LlamaIndex 负责文档加载、分块、索引和检索流程编排。选这套组合有三个理由资源占用低Mac 笔记本完全可以跑起来零成本不需要云服务或付费 API 密钥切换生产环境时LlamaIndex 的抽象层能平滑替换成 Milvus 或 pgvector迁移成本低。如果只装一个 Python 库来搭 RAG我可以拍胸脯推荐 LlamaIndex。它对数据接入和索引构建的封装比 LangChain 更直接一个VectorStoreIndex就能完成从文档到检索器的构建。配合 Chroma 这个嵌入式向量库数据落在本地磁盘重启不丢性能和隐私都够用。Ollama 则把模型管理简化成几条命令无需手动配置 Python 环境跑模型推理。4.2 从零到一的操作清单下面按顺序演示在 Mac 上搭建一套最小可用 RAG 知识库的全过程从安装依赖到检索完整走通。第一步安装 Ollama 并拉取模型。# 安装 ollama brew install ollama # 启动服务 ollama serve # 拉取 chat 模型和 embedding 模型 ollama pull qwen2.5:7b ollama pull nomic-embed-text这里我把qwen2.5:7b用作生成模型nomic-embed-text用作文本向量化模型。如果你的 Mac 内存只有 16G7B 模型可以正常跑但建议关闭其他大型软件32G 内存跑起来会更从容。如果只有 8G 内存换成qwen2.5:3b会更稳妥。第二步创建 Python 项目并安装依赖。mkdir rag-lab cd rag-lab python3 -m venv venv source venv/bin/activate pip install llama-index chromadb这里我建议用虚拟环境避免污染系统 Python。llama-index会自动拉起很多依赖安装过程可能需要几分钟。第三步准备测试文档并建立索引。先放一个简单的知识文件handbook.md内容可以是你自己的产品说明、笔记或者调研报告。然后运行这段 Python 代码来构建索引from llama_index.core import SimpleDirectoryReader, VectorStoreIndex from llama_index.core import Settings from llama_index.embeddings.ollama import OllamaEmbedding from llama_index.llms.ollama import Ollama # 配置本地模型 Settings.embed_model OllamaEmbedding(model_namenomic-embed-text) Settings.llm Ollama(modelqwen2.5:7b, request_timeout120.0) # 读取文档构建索引 documents SimpleDirectoryReader(input_dir./data).load_data() index VectorStoreIndex.from_documents(documents) # 持久化索引 index.storage_context.persist(persist_dir./storage)这一步有几个容易踩坑的地方Ollama 服务没启动会导致连接报错需要先确认ollama serve在运行模型名称打错会导致拉取失败用ollama list检查已拉模型input_dir路径不对会导致读不到文档注意相对路径的问题。第四步加载持久化索引并完成问答。from llama_index.core import StorageContext, load_index_from_storage # 从本地加载索引 storage_context StorageContext.from_defaults(persist_dir./storage) index load_index_from_storage(storage_context) # 创建问答引擎 query_engine index.as_query_engine(similarity_top_k4) # 提问 response query_engine.query(你的知识库里有哪些关键要点) print(response)这一步会触发完整链路问题向量化、向量检索、拼接上下文、LLM 生成。如果首次运行速度偏慢是因为 7B 模型在 CPU 推理本来就慢这是正常的。可以观察打印出来的回答是否基于知识库内容而不是模型自身记忆。4.3 分块与召回参数的工程调优经验在基础版本跑通之后就需要面对进阶调优问题了。我总结几个关键参数这些参数我在真实项目里反复调整过chunk_size决定每个知识块包含多少字符。128 太小知识被切碎1024 太大检索粒度粗糙。我常用 512 作为起点再根据文档特征调整。chunk_overlap相邻片段之间的重叠字符数。设置为 50-100 可以缓解切分造成的信息断裂。similarity_top_k召回片段数量。问答场景一般取 4-6 个太多会把无关内容塞进上下文太少则信息不足。similarity_cutoff相似度阈值。低于阈值的片段不进入提示词防止噪音干扰。embed_model不同 Embedding 模型对中文支持差异极大实测中建议对比nomic-embed-text、bge-m3和商用 API 的效果。在 LlamaIndex 里调整这些参数非常方便创建查询引擎时可以这样设置query_engine index.as_query_engine( similarity_top_k6, similarity_cutoff0.3, node_postprocessors[SimilarityPostprocessor(similarity_cutoff0.3)] )从工程角度看调参不能靠拍脑袋。我建议每次都记录同一批测试问题的命中率用一个月度评测集来回归。如果调了参数后评测指标不变甚至下降多半是问题出在数据质量或者 Embedding 模型本身而不是这些超参数。4.4 从本地到生产需要补哪些课本地跑通只是第一步专栏在本地实战之后还会专门讨论上生产的问题。从我的经验来看至少需要补齐四个方面资源层、存储层、模型层、监控层。资源层上本地方案用 Ollama 跑 CPU 推理生产环境推荐换成 GPU 推理服务例如 vLLM 或专门的推理平台否则延迟和吞吐根本扛不住。存储层上Chroma 适合单机原型生产环境建议替换为 Milvus、Qdrant 或 pgvector并提供高可用部署。模型层上开源模型和商用 API 的取舍要看数据隐私、成本预算和效果需求一般建议通过离线评测对比再决定是 API 调用还是内网私有化部署。监控层上必须要记录每个问题的检索命中片段、生成结果、用户反馈形成闭环数据才能持续定位问题。这四层全部落地才算一个合格的 RAG 产品。专栏每个模块都会尽可能给到生产级建议本地演示和生产方案不会混为一谈。5. 避坑指南与常见问题速查5.1 RAG 六大高频翻车场景与排查思路在多年的实际项目中我把 RAG 最常见的失败场景整理成了一个速查表方便大家遇到问题的时候快速定位问题表现可能原因排查思路推荐解法召回结果和问题不相关内容多分块太粗或 Embedding 模型不匹配抽样查看召回片段检查相似度分数调整分块参数更换/对比 Embedding 模型回答逻辑混乱、前后矛盾多个知识片段之间有冲突检查 top_k 召回片段内容增加重排模型调整段落权重建立冲突消解规则回答依赖模型记忆而非知识库提示词引导不足或上下文没拼进去检查回答是否引用了知识库原文强化提示词要求引用原文检查检索是否成功返回知识库更新后回答仍是旧内容向量索引未同步更新检查索引构建时间和数据源变更建立增量索引机制清理旧向量回答总是找不到相关内容文档解析有问题或查询表达过短用可视化工具检查文档分块结果优化解析流程对查询做改写和扩展线上延迟高、资源占用大向量检索和 LLM 推理都在 CPU监控请求链路耗时分布加语义缓存上 GPU 推理优化向量索引类型这张表是专栏调试篇的浓缩版。我特别想强调一点很多“玄学问题”最后发现都是数据解析阶段的低级错误比如 PDF 里的文本没有正确抽取、表格被错误切分、图片没有被识别。所以在做任何高级优化之前先把文档解析这一步做扎实能少走一半弯路。5.2 对热搜问题给出直接回答结合热搜词我把大家最关心的几个问题在这里提前给出结论省得再翻遍全网找答案。Q1RAG 知识库能存储图片吗能。但需要走多模态 Embedding 链路用 CLIP 类模型把图片映射到向量空间并且生成阶段需要多模态 LLM 支持。不能简单地把图片路径当文本塞进去。Q2RAG 知识库和结构知识库如何区分各适合什么场景核心看数据和查询的形态。非结构化文本、语义检索场景选 RAG 向量知识库精确筛选、统计报表场景选结构知识库配合 Text2SQL实体多跳关系推理场景选知识图谱。实际系统常混合使用。Q3如何在 Mac 上搭建 RAG 知识库推荐 Ollama 运行本地模型、LlamaIndex 做流程编排、Chroma 做向量存储。具体步骤见第 4 章的完整实操注意内存配置和模型选择。Q4RAG 的瓶颈到底是什么不是模型不够强而是工程链路不完善解析质量、分块策略、召回精度、重排逻辑、评估闭环、性能优化每一环出问题都会导致最终效果打折。进阶实战就是逐项补齐这些环节。5.3 专栏内容制作的质检流程为了让《RAG进阶实战》的内容对读者真正负责我在专栏制作流程中也引入了内容质检环节。每篇文章在发布前都要经过五个步骤的校验代码是否在干净环境里完整跑通教程中的效果指标是否真实记录问题场景是否足够典型、能否引起读者共鸣步骤表述是否能让一个新手无歧义地复现文末的问题是否值得读者花时间思考。这个认证流程也提醒读者不要盲目信任网上的 RAG 教程。一个好的实战教程至少应该提供完整可运行的代码、清晰的运行环境说明、真实的效果数据以及足够的坑点总结。如果缺少其中任何一项复现时大概率会遇到问题。6. 专栏内容制作与运营建议6.1 内容生产节奏与互动选题机制专栏内容规划好之后节奏和互动机制往往决定最终效果。以我自己的运营经验固定节奏输出比一次性全部发布更有利于读者消化吸收也更容易沉淀出高质量反馈。我计划每周输出一篇深度长文配合一个可以直接运行的代码仓库确保读者每周都能完成一个可感知的进阶里程碑。交互设计上我建议采用“问题驱动”的选题机制。每篇文章末尾留一个开放式思考题让读者结合自己的业务场景提交问题每次专栏更新后集中收集评论区和社群中的问题作为后续补充内容或专题直播的主题。通过这种双向互动专栏内容会更加贴近真实场景而不会变成作者单方面的技术自嗨。6.2 配套代码仓库与实验数据的组织方式作为一个实操型专栏配套代码仓库的管理直接影响读者的复现体验。我的建议是用一个 GitHub 仓库统一管理所有示例代码目录按周划分每篇文章对应一个独立目录包含 README、完整代码、测试数据和运行结果记录。其中 README 一定要写清楚环境依赖、模型下载方式、执行步骤和已知问题否则读者很难把代码跑起来。rag-advanced-practice/ ├── week1-knowledge-base-selection/ │ ├── README.md │ ├── comparison.md │ └── decision_table.pdf ├── week2-chunking-strategy/ │ ├── chunk_demo.py │ ├── test_docs.pdf │ └── experiments/ ├── week3-embedding-tuning/ │ ├── embed_compare.py │ └── results/ └── week9-monitoring/ ├── logs/ └── dashboard_demo.py对于实验数据不仅要保存成功结果也要保留失败案例。我发现很多开发者排障时缺少对照实验数据因此在专栏实践中每个调优实验都会记录参数、检索结果、生成结果和问题分析形成一个完整的实验日志体系。这套体系对长期优化 RAG 系统尤其重要。6.3 把专栏沉淀为社群资产最后想说的是专栏的终点不是文章本身而是以专栏为起点形成一个持续的交流社群。RAG 的发展速度很快框架更新频繁模型迭代周期越来越短一篇文章在发布半年后可能部分信息就会过时但社群里的实践讨论和经验沉淀会持续生长。专栏可以作为社群的知识底座在社群中开展打卡学习、案例征集和知识库共创不断补充新的实战案例让这个知识体系始终和社区的真实需求保持同步。最后分享一点我规划这个专栏时的心得如果你也想策划一个技术专栏或者正在带团队做 RAG 技术沉淀我有几个亲测有效的建议。内容选题一定不要从自身擅长领域出发而要从用户真实搜索和提问的问题出发热搜词和研究用户痛点是我认为最有效的选题来源。其次每个实践案例都要写出“失败过程”而不仅仅是展示一个漂亮的结果。读者从错误中学到的东西往往比从正确答案中学到更多这是我写专栏最深的体会。最后RAG 进阶不是一蹴而就的事情它需要把知识库选型、文档解析、分块策略、向量检索、重排优化、评估体系这些环节一个一个做扎实。我在实际项目中踩过很多坑才慢慢梳理出这套方法论。这个专栏的初衷就是希望把这些方法系统地传递出去让更多人不用再经历一遍相同的曲折。
阅读完成 · 觉得有帮助？
