01 什么是“RAG”?
大模型很聪明，但也有“短板”
上下文长度有限
比如 deepseek-r1 满血版的上下文上限是 128K tokens不能无限输入文本，超过了它就处理不了。
知识可能过时
如果模型是基于 2024 年前的数据训练的，你问它2025年发生的事，它可能会一本正经地胡说八道，即产生“模型幻觉”。
知识面不完整
很多垂直领域的专业知识或企业内部数据本就不公开，模型没见过，自然不会答。
微调很折腾
想让模型掌握新知识，一般得微调甚至重新训练，工程复杂又费力，普通人难搞定。
所以我们需要一种方式，让模型“临时查资料再回答问题”，也就是 RAG(检索增强生成)。
它的核心思路是：
先“检索”一批相关资料，再把资料+问题一起交给大模型，生成答案。就像是：带着“小抄”去考试！
02 RAG的工作原理
关键流程包括以下几步：
文本分块(Chunking)
原始文档太长，模型“吃不下”，所以要先切成较小的段落(chunk)。
常见切分方式: 按段落、句子数量或固定字数等，具体方式因文本结构而异。
向量化(Embedding)
每个 chunk 会通过 embedding 模型(如 OpenAl 的text-embedding-ada-002)转化为向量，用数字表达其语义。
语义越相近的 chunk，其向量距离越近。
构建索引(向量数据库)
将这些向量存入向量数据库(如 Qdrant、Chroma)以便后续快速检索。
检索(Retrieve)
用户的问题也通过 embedding 模型转为向量，并与数据库中的向量进行匹配，根据相关性选出 top-k个chunk。
重排序(Reranking)
初步筛出的 chunk 可能质量不一，需用 rerank 模型重新排序，选择最贴近用户问题意图的几个 chunk。
构造提示词(Prompt 构造)
将这些精选出的 chunk 和用户问题拼成完整提示词，交给大模型生成答案。
03 什么是向量数据库？
传统数据库依赖关键词和字段匹配，适合精确查找。而向量数据库支持语义匹配: 它通过计算向量之间的相似度(如余弦相似度)，快速找出“意思差不多”的文本。
为什么速度快?
搜索算法优化: 如使用 ANN(近似最近邻)搜索算法减少遍历范围。
索引结构加速: 借助 HNSW、IVF-PQ 等结构，有效组织和检索高维向量。
计算加速: 采用 SIMD 指令并行计算，提升相似度计算效率。
常见向量数据库:
Chroma: 开源、易集成，适合小规模项目
Weaviate: 支持 REST API，内置 embedding 功能
Milvus: 高性能、分布式，适合处理海量数据
Qdrant: 开箱即用，支持payload(附加字段)检索
04 “RAG”有哪些问题?
Chunking 难度高
分块太短导致信息零散，太长又可能导致语义不集中，影响向量匹配准确性。分块方式不合理，还可能破坏上下文的语义完整性，导致指代混乱、逻辑断裂。
不适合需要“全局理解”的任务
比如你问: “这篇文档的核心观点是什么？”
但你把它拆成了100段，模型只看到了其中5段，它当然无法理解全貌。
Embedding 理解可能有偏差
像“我喜欢音乐”VS“我以前喜欢音乐”，对人类来说含义不同。但它们的向量可能很接近，检索时容易误判。
05 “RAG”的应用场景
RAG 的适用范围很广，说几个典型场景
企业知识问答系统
将内部文档构建为知识库，员工提问时，模型先检索相关内容，再生成准确答案。
代码问答助手
把工程代码转成可检索的知识库，像 Cursor 就是这样做的，支持回答项目结构、函数逻辑等开发相关问题。
设备故障诊断
将设备手册、故障记录、维修案例等资料向量化建库，遇到问题时先检索相似案例，再生成诊断与维修建议，提高维修效率。
