RAG入门实战：从原理到企业级知识库搭建

大模型虽然强大，但它只知道训练时见过的数据。企业内部的业务文档、产品手册、客户记录，这些“私域知识”大模型一概不知。想让大模型回答基于企业内部资料的问题，目前主流的技术路线就是检索增强生成（RAG）。B站上这套保姆级课程从零讲起，把RAG的底层逻辑、工作流程和落地边界拆解得相当清楚。

RAG到底在解决什么问题

RAG全称Retrieval-Augmented Generation，检索增强生成。它的核心思路很直白：用户提问后，系统先从企业知识库里检索出与问题相关的内容片段，再把这些片段连同原始问题一起塞进大模型的提示词，让模型基于这些“参考资料”来作答。

对比另一种常见做法——用工具（Function Calling）直接查数据库再塞进上下文——RAG的优势在于精准匹配。工具方式检索出的内容量大，多轮对话下容易撑爆上下文窗口，后续回答质量直线下降。RAG则是针对用户问题精准召回相关片段，上下文占用可控得多。

不过课程也提醒，即便RAG做得好，回复准确率也很难做到百分之百。大模型本质是概率模型，加上RAG流程环节众多，任何一环出问题都会影响最终答案。

RAG工作原理：一条完整的流水线

课程用一张流程图把RAG的工作机制串了起来，虽然粗略，但对初学者建立整体认知足够用。

知识入库阶段

企业内部的文档（PDF、Word、Markdown、HTML、Text等）先经过格式转换和预处理，然后被切分成一个个小块，课程里叫“串客”（chunk）。切分粒度通常按段落来，但具体怎么切涉及切分策略——切得太大检索不精准，切得太小语义容易断裂。

每个chunk通过嵌入模型（Embedding Model）转成数学向量，存入向量数据库。课程提到目前大模型领域最常用的是Milvus，当然ES、PGVector、Victoria等也有各自的使用场景。

嵌入模型（Embedding Model） 是将文本映射为高维向量的神经网络模型。它的核心能力是让语义相近的文本在向量空间中距离更近，从而支持基于相似度的检索。主流嵌入模型包括OpenAI的text-embedding-3系列、开源的BGE、M3E、Sentence-BERT等。选择嵌入模型时需关注其支持的向量维度、最大输入长度、多语言能力以及在特定领域（如法律、医疗）上的表现。通常建议在实际业务数据上做小规模评测，而不是盲目追求排行榜高分。

向量数据库 是专门为高效存储和检索向量设计的系统，核心能力是近似最近邻搜索（ANN）。Milvus是开源领域最流行的选择之一，支持十亿级向量规模；PGVector将向量能力集成到PostgreSQL中，适合已使用PG的团队；Elasticsearch和Victoria则分别在全文检索和轻量级场景中有优势。选型时需综合考虑数据规模、查询延迟、运维成本和生态集成。

检索生成阶段

用户提问后，用同一个嵌入模型把问题也转成向量，在向量库中做相似度计算（最常见的是余弦相似度），找出与问题向量最接近的若干chunk。这些chunk结合提示词模板和用户原问题，一起交给大模型推理生成回复。

这个流程的关键在于“检索”环节的质量——召回的内容是否真正相关，直接决定了大模型能否答对。

余弦相似度 是衡量两个向量方向一致性的指标，取值范围为-1到1，值越大表示越相似。在RAG中，由于嵌入模型通常将文本向量归一化，余弦相似度等价于内积计算，效率较高。除余弦相似度外，内积（Dot Product）和欧氏距离（L2）也是常见选择，具体取决于嵌入模型的训练方式。实际检索时，向量数据库会使用近似最近邻算法（如HNSW、IVF）在召回率和速度之间做权衡，而非暴力计算所有向量。

影响RAG准确度的五个关键因素

课程花了相当篇幅拆解RAG回复不准的原因，这些也是面试中高频被问到的点。

原始资料的处理质量。 如果文档里有图片、表格但没做解析和转换，这些信息在检索阶段就丢了。用户想查的恰好是表格里的数据，系统根本召不回来。

文本切分策略。 语义强相关的内容被切到两个不同chunk里，检索时只召回一半，答案自然残缺。切分边界的设计需要结合业务语义来定。

嵌入模型的能力。 向量化质量直接影响相似度计算的准确性。模型对语义的理解能力越强，召回的相关性越高。

检索策略。 只召回最相似的1个片段还是Top-3、Top-5？要不要把相邻chunk也带上以避免语义丢失？这些策略选择会显著影响召回效果。

提示词与生成模型能力。 检索对了但提示词组织不当，或者模型本身推理能力不足，照样答错。课程特别提到，通过评估指标可以区分到底是检索环节出了问题还是生成环节出了问题，这在工程排查中非常实用。

数据量极大时，RAG未必是最优解

课程给出了一个务实的判断：RAG适合几篇到几百篇文档规模的知识库。如果企业数据量达到TB甚至PB级别，RAG的检索成本和效果都会面临挑战。这时候更值得考虑的是微调（Fine-tuning）——让模型直接把领域知识内化到参数里。

这个观点值得重视。很多团队一上来就堆RAG，但没想清楚数据规模和业务场景是否匹配。数据量小、更新频繁、需要溯源引用的场景，RAG是首选；数据量极大、模式相对固定、对推理延迟敏感的场景，微调可能更合适。两者也不是互斥的，实际项目中经常组合使用。

微调（Fine-tuning） 是指在预训练大模型的基础上，用领域数据继续训练，使模型参数适配特定任务或知识。与RAG的“外挂知识库”不同，微调将知识内化到模型权重中，推理时无需额外检索，延迟更低，但更新知识需要重新训练，成本较高且难以溯源。常见的微调方法包括全参数微调和参数高效微调（如LoRA、QLoRA）。RAG与微调并非对立：RAG擅长动态、可溯源的知识查询，微调擅长固定风格、格式和推理模式的塑造，实际项目中常采用“微调模型 + RAG检索”的组合方案。

给入门者的实践建议

这套课程的价值在于把RAG从概念到落地的链路讲透了。对于想动手搭建私有知识库的开发者，建议按以下顺序推进：先跑通最小闭环（文档解析→切分→向量化→检索→生成），再针对每个环节做优化。切分策略和检索策略是最容易见效的调优点，嵌入模型和生成模型的选择则取决于预算和场景要求。评估环节不要省——没有评估指标，优化就是盲人摸象。