RAG原理和知识库构建
现在各家公司都在如火如荼的构建AI时代自己的知识库，RAG正是实现AI知识库问答的一个通用实现方式。很多人对RAG的认知只停留在“检索+生成”的概念层面，但真正落地到项目，核心拼的并不是大模型，而是切片质量、向量匹配精度、检索筛选策略、工程选型适配。
为什么需要RAG
大模型的固有缺陷是上下文有限、知识滞后、容易幻觉，且无法读取私有业务数据。
RAG的核心逻辑非常简单：提前把私有文档处理成机器可检索的格式，用户提问时，先精准捞出相关原文，再让大模型基于真实原文作答。
整体分为两大阶段：离线建库（一次性/定时更新）、在线问答（实时执行），全程5个核心步骤，每一步对应固定工程组件。
简单表述步骤
- 原始文档 → 切分 → Embedding → 向量库；
- 用户问题 → Embedding → 向量检索 → rerank 筛选 → 拼 prompt 喂大模型 → 输出答案。
第一步：文档预处理 & 切片分块（Chunking）—— 地基环节
这是RAG效果好坏的决定性步骤，比换大模型、换向量库影响更大。很多RAG答非所问、信息缺失，大多数都是切片不合格导致的。
核心工作
1、文档解析：读取PDF、Word、Markdown、网页、知识库等各类格式文件，清洗水印、空行、乱码、重复无效内容，统一转为纯文本；
2、语义分块：不按固定字数暴力切割，优先按照段落、标题、语义边界拆分，保证每一块文本语义完整、逻辑独立；
3、块级优化：给每一块添加上下文前缀、文档来源、章节信息，避免单块内容缺失语境导致检索失效。
技术选型
1、基础切片工具（通用首选）
框架：LangChain / LlamaIndex 内置切片器
策略：优先 递归字符切片，适配绝大多数普通文档，兼容中英文，容错性高
参数参考（生产通用）：块大小512-1024字符，重叠率10%-20%，避免上下文断裂
2、高质量语义切片（企业复杂文档首选）
工具：BGE-Slicer、Qwen-Splitter
优势：基于模型语义识别切片，能精准识别标题、段落、表格边界，适合合同、手册、技术文档、长文本论文
3、文档解析专用工具
PDF/复杂版式：PyMuPDF、pdfplumber（保留排版，解析精准）
Word/Excel：python-docx
网页数据：BeautifulSoup
落地避坑
- 忌固定字数暴力切片：容易切断句子、打断逻辑，导致检索出无效片段；
- 忌无重叠切片：上下文断层，关键信息丢失；
- 简单文档用递归切片，复杂结构化文档必须用语义切片。
第二步：文本向量化（Embedding）—— 翻译机器语言
机器无法直接理解文本语义，需要把每一个文本块，转化为固定维度的数值向量，语义相似的文本，向量距离更近，这是检索匹配的核心依据。
重点：建库、提问必须使用同一个Embedding模型，否则向量维度、语义编码规则不一致，完全检索不到有效内容。
技术选型
1、开源私有化部署
通用中文场景：bge-large-zh-v1.5（工业级标配，语义匹配精度最高）
多语言/混合场景：bge-m3（支持多语言、多粒度检索，适配跨境、多语种文档）
轻量化低配置设备：gte-small、bge-small-zh（速度快、资源占用低，精度够用）
2、商用API（快速上线、无需运维模型）
高质量场景：OpenAI text-embedding-3-large、Voyage-3
性价比场景：阿里通义Embedding、百度文心Embedding
落地参数
通用维度：1024维（主流标配，精度与速度平衡）
批量处理：单次批量编码，避免逐条请求，提升建库效率
第三步：向量库存储 —— 数据持久化核心
将「文本片段+对应向量+文档元数据（来源、时间、标签）」持久化存储，为后续实时检索提供查询能力。选型核心看：数据量级、运维成本、QPS、是否需要混合检索。
技术选型（场景化精准匹配）
1、个人开发/原型验证/小项目（百万级数据内）
选型：Chroma、FAISS
优势：开箱即用、零部署、轻量化、代码接入简单
缺点：不支持分布式、高并发弱，仅适合测试和Demo
2、中小型生产项目（百万-千万级，低运维需求）
选型：pgvector（PostgreSQL插件）
优势：复用现有PG数据库生态，无需新增中间件，支持向量+条件筛选混合查询，稳定可靠
适配场景：传统业务系统集成RAG、数据量不大、不想增加运维成本的项目
3、中大型企业生产（千万-亿级向量、高并发）
选型1：Qdrant（首选）
优势：Rust编写、性能极高、单机稳定性强、支持复杂过滤、运维简单、QPS表现优秀
选型2：Milvus
优势：分布式能力成熟、海量数据写入和检索性能顶级，行业标准级向量库
缺点：部署复杂、依赖K8s，运维成本高，适合大规模集群场景
4、已有搜索生态的企业
选型：Elasticsearch / OpenSearch
优势：天然支持关键词+向量混合检索，无需重构搜索架构
第四步：实时检索 + 重排序（Rerank）—— 精准降噪
用户提问后，先对问题向量化，再从向量库捞出相似片段，这一步是过滤无效信息、提升答案精度的关键，也是初级RAG和生产级RAG的核心差距。
核心流程
1、用户问题向量化（同建库Embedding模型）；
2、向量粗召回：检索Top10-Top20相似文本片段（向量检索擅长语义匹配，但容易出现“语义像、内容无关”的结果）；
3、重排序精筛：用Rerank模型对召回结果重新打分，保留Top3-Top5最贴合问题的真实有效片段；
4、（可选）混合检索：向量语义检索 + 关键词检索，互补短板，避免漏检关键信息。
技术选型
1、开源Rerank模型（生产首选、免费私有化）
中文场景：BGE-Reranker-base/large（国内工业级标配，精度碾压传统检索）
多语言场景：bge-m3-rerank、cohere-cross
2、商用Rerank服务（极致精度、免部署）
选型：Cohere Rerank、火山Rerank API
适配场景：对答案准确率要求极高、无机器资源部署模型的项目
落地关键规则
粗召回多捞、精排少留：粗召回尽量多拿结果，Rerank精准过滤，最大化避免漏信息、减少噪音；
绝对不能省略Rerank：单纯向量检索的错误率极高，生产环境必须标配重排序。
第五步：Prompt组装 + LLM生成 —— 最终输出答案
检索、筛选完成后，将用户问题+高质量参考片段+约束规则组装成标准Prompt，交给大模型生成最终答案。这一步核心不是模型能力，是约束模型不乱编。
核心工作
1、过滤无效片段：剔除重复、无关、过期内容；
2、规范Prompt格式：明确告知模型“仅基于参考资料作答，无对应内容直接告知未知，禁止编造信息”；
3、拼接上下文：整合有效片段，保证信息连贯；
4、模型推理输出：返回结构化、通顺的答案。
Prompt核心约束
1、严格基于参考文档回答，禁止拓展无关知识；
2、参考文档无答案时，直接回复“暂无相关信息”，杜绝幻觉；
3、回答内容标注对应文档来源，便于溯源核对。
RAG落地效果差原因
绝大多数RAG效果差，不是大模型不够强，而是工程细节不到位：切片混乱、Embedding不匹配、检索无降噪、Prompt无约束。
- chunk 切太大：噪音多；切太小：丢失上下文，片段看不懂。
- embedding 前后模型不一致：检索不到有效内容。
- 只向量检索不加 rerank：会召回很多 “语义像但是无关” 的垃圾片段。
- 没有约束 prompt：模型无视参考文档，依旧幻觉乱编。
- 没有文档更新机制：文档改了，向量库还是旧内容，答出过时信息。