本文旨在用通俗易懂的方式解释 RAG（Retrieval Augmented Generation）是什么、为什么需要它，以及如何在实际工具（如 Cherry Studio）中“看到” RAG 的全流程。
1 什么是 RAG
过程描述
简单来讲，有两条链路，一个是数据的准备，一个是数据的使用。
数据准备：我们需要把文档进行切片，然后把切片后的文档通过嵌入模型进行向量化，再在向量数据库中创建索引并存储。
数据使用：首先我们需要把用户问题进行向量化，然后和向量数据库中的向量进行相似度匹配，把最相关的文档或片段作为上下文和问题拼到一起，让大模型根据问题和相关信息给出更好的回答。
向量化科普
假设我们有这么多的物品，我们希望通过距离来表示它们之间的相似性。
我们可以按照更接近三明治的这种程度放在坐标里。
我们除了根据三明治程度，还可以加上甜品程度，就开两个维度了，这样不同物品就被切分得更明显一些。
如果再加上液体程度的话，那么就三个维度了，区分度就更高了。
那么我们加上汤圆的话，它就会在图片的这个位置。
可以看到维度越多，区分度越高，我们就可以用位置的远近来代表物体之间的相似度。
详情参见：https://developers.google.com/machine-learning/crash-course/embeddings/embedding-space?hl=zh-cn
为了更直观体验，我们访问网站：https://projector.tensorflow.org/
我们只需要构造我们想要的数据：一个是它的向量，一个是对应的属性，就可以直观地在多维坐标里查看。
这里我们采用 Qoder，然后把页面的信息粘贴进去，然后把我们想构造的这些文字（最好包含名称和属性）给它描述进去。
我们把生成的两个文件导入进来，然后就可以在多维坐标里查看了。可以明显地看到含义（属性）越相似位置越近。
2 为什么需要 RAG？
那么有些同学问：为什么需要这个技术？
因为大模型训练的时候，很有可能没有你这个问题所需要的数据，比如说一些业务的信息、一些特定领域的知识等。
传统的数据库只能做精确匹配或基于字符串的模糊匹配，无法真正做到语义匹配。
有了 RAG 的话，用户提出问题，检索出“语义层面”更相关的资料，再结合这些信息回答用户问题，更容易得到准确的答案。
3 “看见”RAG 的过程
大家可以使用各种工具来体验 RAG 的过程，比如 扣子、Dify、Cherry Studio 等。
有了前面的知识之后，我们再看 Cherry Studio 中的知识库配置。
这里，嵌入模型和嵌入的维度就更好理解了。
在 Cherry Studio 中选择嵌入模型把文档“扔进去”的过程其实就是“数据准备”阶段。
对话时自动检索知识库，拼接成到上下文中，并发送给大模型得到更精确答案的过程，就是“数据使用”阶段。
4 提示词工程/RAG/微调如何选择？
选择的核心在于判断你的业务痛点是“缺数据”还是“缺技能”：
-
如果你只需要激发模型已有的通用能力，提示工程 (Prompt Engineering) 是成本最低的首选；
-
如果你需要模型回答它原本不知道的实时信息或企业私有数据（即高外部知识需求），必须选择 RAG 来外挂知识库；
-
如果你需要模型深度模仿某种特定的语气、行业黑话或输出格式（即高模型适应需求），则应选择 微调 (Fine-tuning)；
-
当你既要外挂庞大的专业知识，又要模型具备极强的特定任务表现时，就需要考虑两者的结合方案。
5 RAG 应用中常见的问题？
理想很丰满，就是我们把数据准备好，然后用户提问的时候能准确地找到，然后再很好地回答我们。
但实际上会存在很多问题：
-
缺失内容（Missing Content）
查询所需信息本身并不在检索底库中。当用户提问时系统无法检索到有效内容，LLM 只好“填空”并容易产生幻觉或错误答案.
-
未检索到高质量文档（Missed Top-Ranked Documents）
检索系统未将相关文档排名足够靠前，导致这些重要信息无法传递给LLM，最后答案可能不完整或错误.
-
上下文管理失误（Context Issues）
检索后传递给LLM的文档可能过多、冗杂或结构混乱，导致生成模型无法有效吸收和利用上下文信息.
-
正确答案未被提取（Extraction Errors）
正确答案实际在上下文中，但LLM未能准确提取，因为内容结构复杂或存在矛盾信息，影响理解.
-
答案格式错误（Wrong Format）
用户希望获得特定格式（如表格、列表、JSON等）的回答，但LLM未能按要求输出，影响可用性和用户体验.
-
细节准确度不当（Incorrect Specificity）
LLM结果过于笼统或过度细化，没有在“泛泛而谈”和“细节泛滥”之间找到合适平衡，难以满足用户需求.
-
答案不完整（Incomplete Answers）
LLM输出内容缺失部分重要信息，尽管上下文里有全部答案，但模型未能整体归纳，导致回答不全面
详情参见：Seven Failure Points When Engineering a Retrieval Augmented Generation System 论文
6 如何提升 RAG 的准确性？
6.1优化策略
数据处理策略
- 数据清洗（Data Cleaning）：确保知识库中数据的准确性与一致性，去除重复与错误项，提升下游检索和生成质量。
- 分块策略（Chunking）：合理选择分块技术、分块大小和重叠量，既保证检索的细粒度，又不丢失上下文。
- 嵌入模型选择与调优（Embedding Model Selection & Tuning）：根据场景选择最优的嵌入模型，可以针对企业数据进行微调，提高表示能力。
- 元数据利用（Metadata）：为文档添加标签、时间、主题等元数据，增强搜索过滤与排序能力。
- 多索引设计（Multi-Indexing）：将不同类型/领域数据分开索引，提升检索效率与相关性。
- 索引算法优化（Indexing Algorithm）：采用高效的 ANN 算法（如 HNSW、IVF-PQ）优化大规模向量检索。
推理与生成阶段优化
- 检索策略（Retriever Tuning）：尝试“多检索器混合”、“重排序”、“语义多样性增强”等方法，提升检索相关性。
- 生成模型微调（LLM Fine-tuning）：基于业务数据微调生成大模型，提高问答准确度和可控性。
- Prompt 工程（Prompt Engineering）：系统性优化 prompt 模板和提示策略，强化模型的指令理解与响应能力。
- 缓存与批量处理（Caching & Batch Processing）：对热点查询结果做缓存，并对批量查询做合并，提高系统吞吐与成本效率。
- 弹性伸缩与监控（Auto-scaling & Monitoring）：引入自动扩缩容（如使用 Kubernetes）和指标监控，保障高并发下的响应时延与可用性。
- 系统实验与 A/B 测试（Controlled Experimentation & A/B Testing）：通过线上实验对比不同参数组合的实时效果，实现性能的持续优化。
补充建议
- 模型压缩与推理加速（Model Compression）：采用量化、剪枝、蒸馏等技术降低模型推理延迟和成本。
- API 设计与用户反馈回路：提供流式响应和上下文感知的接口，采集用户反馈，持续闭环优化。
详情参见：https://towardsdatascience.com/a-guide-on-12-tuning-strategies-for-production-ready-rag-applications-7ca646833439/
6.2 使用更先进的 RAG 框架
如 Advanced RAG 加上前置处理（查询路由/查询改写/查询扩写）和后置处理（重排序/摘要/融合）。
如 Modular RAG 将整个RAG系统看作是一个由可插拔的“模块”组成的灵活框架。
HybridRAG 是一个框架，它通过结合知识图谱（GraphRAG）和向量数据库（VectorRAG）的检索结果来增强问答系统，旨在提供比单独使用任何一种方法都更准确的答案 。
详情参见：HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction
KAG (Knowledge Augmented Generation) 是一个面向专业领域的知识服务框架，它利用知识图谱和向量检索的互补优势，通过 LLM 友好的知识表示、逻辑形式引导的混合推理、知识对齐等关键技术，双向增强 LLM 和知识图谱的性能 。
详情参见：KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation
SELF-RAG (Self-Reflective Retrieval-Augmented Generation) 是一个通过自我反思来提升 LLM 质量和事实性的框架，它训练模型按需自适应地检索信息，并使用特殊的“反思令牌”（reflection tokens）来生成、反思和批判检索到的内容及其自身的输出。
详情参见：Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
LightRAG 是一个旨在实现简单快速的 RAG 框架，它通过将图结构纳入文本索引、采用双层（低级和高级）检索系统以及增量更新算法，来高效地检索复杂信息并快速适应数据变化 4444。
详情参见：LightRAG: Simple and Fast Retrieval-Augmented Generation
7 写在最后
RAG 弥补了“缺数据（缺知识）”的问题，但也不是“银弹”。
RAG 虽然追求语义上的匹配，但数据构造的成本高，本身的质量，嵌入模型的好坏，提取后处理等都会影响结果。
RAG 整体来说本身脱离了大模型的“控制范围”，偏“工程能力”，还不够智能。
希望未来能够有新技术出现取而代之。