向量数据库选型、向量化与检索调优，结合大模型搭建私有文档检索增强完整应用实践23.6

一、前言

很多朋友接触大模型之后都会遇到一个非常现实的痛点：通用大模型知识存在时间截断，不懂企业内部文档、业务资料、私有知识库，直接提问很容易出现幻觉，编造不存在的答案。微调可以让模型学习私有知识，但微调成本高、数据更新麻烦、版本迭代繁琐，小样本场景效果并不理想。

这个时候RAG检索增强生成技术就走进了大家的视野。简单来说RAG就是检索 + 生成，不改动大模型本身权重，先从私有文档库里检索相关片段，把检索到的上下文塞进Prompt，交给大模型做总结回答。而整个RAG链路里面，向量数据库就是整套系统的底座，文档切分、向量化存储、相似度检索、召回过滤，几乎全部依赖向量数据库完成。

通常很容易把RAG简单理解成 "文档转向量存进去，查的时候搜一下"，真正上手做项目才发现，召回效果差、答案跑偏、噪声太多、上下文溢出、检索速shen度慢等一堆问题。看似简单的链路，每一个环节都有大量工程细节。实际在构建RAG应用之前，必须先搞懂RAG底层逻辑，理解向量数据库在里面承担的角色，具备独立设计向量化检索解决方案的能力，能够识别项目中常见坑点，才能更好的上手搭建属于自己的RAG原型系统。

二、RAG 基础认知

1. RAG基础概念

RAG全称Retrieval‑Augmented Generation，检索增强生成。它的核心思想，是外部知识库检索补充上下文，大模型负责理解与生成。

传统大模型的知识全部固化在模型参数权重之中，训练结束之后知识就固定下来。想要新增知识，要么重新训练微调，要么直接把知识写在prompt里面。prompt直接塞全部文档，会出现token超限，大量无关内容干扰模型输出。

RAG 把整个流程拆分成两大块：检索模块、生成模块。

检索模块：用户提问，把问题转为向量，去外部知识库检索和问题语义最匹配的文档片段；
生成模块：把用户原始问题 + 检索回来的文档片段组装成提示词，送入大模型，让模型基于检索到的真实资料输出答案。

RAG 最大优势非常突出：

不需要修改大模型权重，知识库更新只需要更新向量库，不用重新训练模型；
极大缓解大模型幻觉，答案有原始文档作为来源依据，可以做溯源引用；
适配私有业务数据、本地文档、实时资讯，成本远低于微调。

但 RAG 并不是万能银弹。整套系统的上限由检索质量决定。检索拿不到正确文档，再好的大模型也无法输出正确答案。很多人RAG项目效果差，问题不出在大模型，而是检索链路，尤其是向量数据库、切片策略、向量模型选择。

RAG分为简单Naive‑RAG朴素检索增强，以及高级的Advanced‑RAG，包含查询重写、重排序、自我校验、多轮检索等能力。绝大多数业务场景，都是从朴素RAG 起步，再迭代高级能力。

2. RAG完整基础链路

一套朴素RAG 分为两大阶段：索引构建阶段、推理查询阶段。

索引构建阶段：离线，只做一次，知识库更新时执行

1. 原始文档加载：PDF、markdown、word、网页文本等各类数据源读取；
1. 文档切片切分：长文档拆分成合适大小文本块chunk；
1. 文本向量化：调用Embedding嵌入模型，把每一段文本转为高维向量；
1. 向量入库：向量数据库存储文本向量，同时保存原始文本、元数据。

推理查询阶段：线上用户提问实时执行

1. 用户输入问题；
1. 问题向量化：把用户提问转为向量；
1. 向量检索：向量数据库执行相似度搜索，召回top‑N相似文本片段；
1. 过滤重排：对召回结果过滤、重排序，剔除噪声；
1. Prompt 组装：把检索片段和用户问题拼接；
1. LLM 生成：大模型接收prompt输出回答。

这里很容易只关注大模型，忽略前面5步。检索链路任何一步出问题，最终回答质量直接崩盘。向量数据库承担存储向量、高效相似度检索的核心任务，是整个RAG系统的存储引擎。

3. RAG与微调的区别

为了不会混淆 RAG 和微调，不清楚业务场景该选哪一个，这里先做一个清晰区分。

RAG 适用场景：

知识频繁更新，文档会新增、修改、删除；
需要答案溯源，需要展示回答来自哪一份原始文档；
私有知识库问答，文档体量较大；
不想投入大量算力做模型训练。

微调适用场景：

想要改变模型输出风格、输出格式，对齐业务话术；
少量样本，需要学习特定输出范式；
知识固定，几乎不会频繁变动。

工程落地中大量项目采用 RAG + 微调组合方案：RAG 负责提供真实外部知识，微调负责规范模型输出格式。

4. RAG基础流程示例

python 复制代码

"""
RAG基础流程伪代码，理解完整链路逻辑
"""
# ========== 离线构建索引 ==========
documents = load_documents("./docs/")          # 加载文档
chunks = split_documents(documents, chunk_size=512) # 文档切片
embeddings = embedding_model.encode(chunks)    # 文本向量化
vector_db.insert(embeddings, chunks)          # 写入向量数据库

# ========== 线上问答推理 ==========
user_query = "RAG技术的核心优势是什么？"
query_vec = embedding_model.encode(user_query) # 问题向量化
retrieved_docs = vector_db.search(query_vec, top_k=3) # 向量检索召回
prompt = build_prompt(user_query, retrieved_docs)     # 组装提示词
answer = llm.chat(prompt)                     # 大模型生成答案
print(answer)

三、向量数据库核心原理

1. 向量数据库的价值

普通数据库 MySQL、PostgreSQL 擅长精确匹配、关键词检索，处理文本语义搜索能力很差。关键词匹配只能匹配字面相同词汇，无法理解语义。

举个例子：文档里写 "检索增强可以降低大模型幻觉现象"，用户提问 "怎么减少大模型胡说八道"。字面词汇几乎没有重合，关键词检索会直接漏召回。但是两段文本语义高度接近，Embedding 模型可以把语义相近文本映射到空间距离很近的向量。

向量就是一组浮点数数组，Embedding 模型把自然语言映射到高维向量空间，语义越接近，向量空间距离越近。我们想要实现语义检索，本质就是找距离用户问题向量最近的一批文档向量。如果使用普通数据库，每一次查询，都需要把库里面全部向量拿出来暴力计算距离。向量数量几十万、上百万的时候，暴力遍历速度完全无法满足线上业务。

向量数据库就是专门为高维向量设计的数据库：

支持向量高效存储；
提供向量索引算法，实现近似最近邻搜索 ANN；
支持向量相似度查询，元数据过滤，增删改查；
针对海量向量做查询加速，牺牲极小精度换取查询速度。

向量数据库≠普通数据库加向量字段。普通数据库可以扩展向量能力，但面向百万、千万级别向量场景，性能、索引优化能力远不如专业向量数据库。

2. 向量核心概念

**Embedding 向量：**文本经过嵌入模型输出的浮点数组，常见维度512、768、1024维。相同语义文本，向量空间距离更小。
**距离度量方式：**用来判断两个向量相似度。
- 余弦相似度：最常用，适合文本 Embedding，衡量向量夹角，不受向量长度影响；
- L2欧氏距离：计算向量空间直线距离；
- 内积距离，多用于归一化后的向量。 RAG 项目绝大多数场景优先选择余弦相似度。
ANN 近似最近邻算法：
- 暴力搜索KNN是精确计算全部向量距离，结果100准确，海量数据速度极慢。
- ANN 近似最近邻，通过构建特殊索引结构，跳过大部分向量，只计算部分候选向量，用少量召回精度损失，换取百倍千倍查询速度。
- 主流索引类型：HNSW、IVF_FLAT、IVF_SQ8等。HNSW 综合性能优秀，RAG项目使用最多。
**元数据：**向量数据库除了存储向量、原始文本，还可以存储元数据，文档来源、时间、文档类型、文档 ID。线上检索的时候，可以结合元数据做过滤，例如只检索某一份文档、某一个时间范围的资料。

3. 主流向量数据库选型

目前开源向量数据库有很多，不同数据库在部署难度、性能、资源消耗、生态各有差异。

Chroma：轻量级，本地内存文件存储，无需额外部署服务，适合原型验证、demo 开发，不适合大规模线上生产；
FAISS：Meta 开源向量检索库，只有检索能力，不是完整数据库，没有持久化、元数据管理，需要自己封装上层逻辑；
Milvus：开源生产级向量数据库，功能完整，支持海量向量，丰富索引，支持元数据过滤，RAG 生产落地高频选择；
Qdrant：开源向量库，性能优秀，API 友好，资源占用可控，文档完善；
PGVector：PostgreSQL 扩展插件，如果你业务已经重度依赖 PostgreSQL，可以直接复用现有数据库，向量规模千万以内可以考虑。

选型参考建议：

原型调试、本地 demo：Chroma；
生产环境，百万及以上向量，需要稳定服务：Milvus/Qdrant；
不想新增数据库组件，已有PG库：PGVector。

4. Chroma 简易向量库示例

python 复制代码

"""
安装依赖：pip install chroma sentence-transformers
简易向量数据库demo，直观理解向量入库和检索
"""
import chroma
from chroma import Client
from sentence_transformers import SentenceTransformer

# 加载开源embedding模型
embedding_model = SentenceTransformer("all‑mps‑base‑v2")

# 初始化本地向量库
client = Client()
collection = client.create_collection(name="rag_demo")

# 原始文档片段
text_list = [
    "RAG检索增强生成，不修改大模型权重，借助外部文档补充知识",
    "向量数据库用来存储文本向量，实现语义相似度检索",
    "大模型幻觉指模型输出看起来合理，但不符合事实的编造内容"
]
# 生成向量
vecs = embedding_model.encode(text_list).tolist()

# 写入向量库
collection.add(
    embeddings=vecs,
    documents=text_list,
    ids=["doc_1","doc_2","doc_3"]
)

# 用户提问，向量化检索
query = "什么手段可以缓解大模型产生虚假内容？"
query_vec = embedding_model.encode(query).tolist()

res = collection.query(
    query_embeddings=[query_vec],
    n_results=2
)
print("检索召回结果：", res["documents"])

四、RAG核心重点

1. 文档切片策略

通常如果做RAG效果差，第一个问题就是文档切片。chunk大小不是固定万能值，切片直接影响向量质量、召回效果。

如果chunk设置过大：单个片段包含大量无关信息，向量语义混杂，检索的时候容易带入噪声，同时后续送入大模型会占用大量token。
如果chunk设置过小：语义被强行切断，一个完整语义被拆分多个chunk，单条向量信息不足，语义碎片化，检索很难召回完整上下文。

常见切片方式：

1. 固定长度切片：最简单，按字符数切割。缺点很明显，会把完整句子、完整段落从中间切断，破坏语义完整性。适合纯简单文本场景。
1. 递归字符切片：优先按照换行、句号、逗号等分隔符切割，尽量保证句子完整，达到阈值再截断，LangChain默认方案，业务最常用。
1. 语义切片：基于向量相似度，语义发生明显变化的地方切分，按照语义边界切割，效果更好，但计算开销更大。
1. Markdown 结构化切片：识别标题层级，按照文档天然标题结构切分，针对markdown文档效果极佳。

应用实践经验：

通用中文场景，递归切片，chunk_size300‑800字符，重叠overlap设置为chunk的 10%‑20%。重叠的意义，避免完整语义被切分到两个chunk边界，造成信息丢失。
技术文档、说明书：chunk_size偏小300‑500；
合同、长段落业务文档：chunk_size 600‑800。

切片不是一套参数通吃所有文档类型，实际项目中，需要针对自己文档做测试调参。

2. Embedding嵌入模型选择

Embedding模型决定向量质量，向量质量差，再好的向量数据库索引也救不回检索效果。Embedding 模型分为开源模型、闭源 API。

闭源：OpenAI‑Embedding，调用简单，效果优秀，但有调用费用，内网隔离环境无法使用。
开源中文 Embedding：bge‑系列、m3e 系列，是国内 RAG 落地主流选择，可以本地部署，离线可用。

选型要点：

输入长度：注意模型支持最大上下文长度，如果文档chunk超过模型最大输入，会直接截断，向量效果大幅下降；
向量维度：维度越高，携带信息越多，同时向量存储占用内存、磁盘空间会变大；
语言适配：中文业务优先选择中文训练的Embedding，不要直接使用英文预训练模型；
检索场景：注意区分检索型Embedding，不是文本生成模型。

查询的向量化，必须和入库文档使用完全同一个Embedding模型。入库用bge，查询用 m3e，向量空间完全不匹配，检索结果完全失效。

3. 检索与重排序

向量数据库返回top‑k候选片段，这里会出现一个问题：语义相似不等于真正对问题有用。向量召回会出现语义相近但是无关的噪声片段。

重排序Rerank就是第二步过滤。Rerank模型接收用户问题和召回出来的文档片段，计算每一段文本和问题相关性分数，重新排序，过滤掉低分无关片段。

实践流程：向量数据库粗召回 top‑8~top‑10，再送入 Rerank 模型，筛选 top‑3‑top‑5 送入大模型。粗召回多拿一些候选，重排序做精准筛选，是提升 RAG 效果性价比极高的手段。

Rerank同样有开源模型 bge‑reranker，可以本地部署。线上要注意开销，rerank会增加推理耗时。
元数据过滤也是检索环节重要手段。向量检索同时带上过滤条件，例如只检索某部门文档、某时间之后的资料，缩小检索范围，减少无关召回。

4. Prompt工程设计

检索拿到正确文档，不代表大模型就可以输出好答案，Prompt 的设计至关重要。

RAG 场景 Prompt 基础组成：

系统提示词：约束大模型行为，告知模型只能参考给定上下文回答，不知道就如实说不知道，禁止编造；
检索回来的参考文档片段；
用户原始问题。

非常关键的约束指令：如果参考资料没有对应答案，请直接告知没有找到相关信息，禁止编造内容。这条指令可以进一步压制幻觉。同时要控制送入大模型的总token，检索回来的片段不能无限制全部塞进去，防止上下文窗口溢出。

5. RAG项目部署架构

RAG部署架构面向生产环境，划分用户接入、网关业务、核心引擎、存储、运维观测五大层级。包含在线问答、离线文档入库两条解耦链路，支持多格式文档解析、分块向量化，采用向量 + BM25 混合检索搭配重排序优化召回效果。依托多类存储组件分别管理向量、元数据与原始文件，配套监控、链路追踪与问答日志，兼顾业务能力、数据可靠性与可观测性，可落地企业知识库类大模型应用。

架构图分点说明：

两条链路相互解耦，文档入库为离线异步流程，问答是在线实时流程，互不阻塞。

1. 用户接入层
- 承载各类终端访问入口，包含Web页面、API接口、业务客户端。
- 用户问答、文档上传请求统一从这一层流入整个系统，是系统对外交互的入口。
2. 网关与业务服务层
- API 网关：承担流量管控，实现鉴权、限流、请求日志记录，拦截非法请求，保护后端核心服务。
- RAG 业务服务：整个RAG流程的编排中枢，串联检索、Prompt构造、大模型调用、结果返回，调度各个子模块协同工作。
3. RAG 核心引擎层‑文档处理模块
- 属于离线数据流水线，用于知识库构建。完成原始文档解析、脏数据清洗、文本分块、Embedding 向量化，处理完成的数据送入底层存储，为检索提供数据基础。
4. RAG 核心引擎层‑检索模块
- 实现混合检索能力：向量相似度检索 + BM25关键词检索；
- 经过Reranker重排序后融合多源结果。核心目标是从知识库中召回和用户问题最相关的文本片段，减少无关内容。
5. RAG 核心引擎层‑生成模块
- 将用户提问与检索得到的上下文片段组装成Prompt，调用大模型服务生成回答，再对输出做过滤、格式整理等后处理，输出最终答案。
6. 存储层
- 向量数据库：存储文档片段的向量，提供向量相似度查询；
- 元数据库 (MySQL)：保存分块信息、文档ID、权限、版本等元数据；
- 对象存储：保存PDF、Word等原始文档文件，用于溯源与重新解析。
7. 运维观测层
- 采集全链路运行信息：服务性能指标、调用链路追踪、RAG问答全量日志。
- 用于定位检索异常、大模型输出问题，支撑知识库迭代与系统运维。
8. 两条核心业务链路
- 问答请求链路：用户发起提问，经过网关、业务服务，执行检索‑Prompt组装‑大模型生成，将答案回传给用户；
- 文档入库链路：读取对象存储原始文件，经过文档处理流水线，向量写入向量库、元信息写入数据库，完成知识库更新。

6. 切片 + prompt组装示例

python 复制代码

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 原始长文本
long_text = """
RAG检索增强生成技术，主要分为索引构建阶段与查询阶段。
索引阶段对原始文档做加载、切片、向量化存入向量数据库。
查询阶段用户问题向量化，向量库检索相关片段，组装prompt交给大模型生成回答。
向量数据库是RAG系统的底层存储，决定检索召回质量。
文档切片大小会直接影响后续向量语义表达效果。
"""

# 递归字符切片
splitter = RecursiveCharacterTextSplitter(
    chunk_size=200,
    chunk_overlap=30,
    separators=["\n\n","\n","。","，"]
)
chunks = splitter.split_text(long_text)
print("切片结果：",chunks)

# 组装RAG提示词
def build_rag_prompt(query, context_list):
    context_str = "\n====文档片段====\n".join(context_list)
    prompt = f"""
你是知识库问答助手，请严格基于下面参考文档片段回答用户问题。
如果参考文档没有相关信息，直接回复未查询到相关内容，不要编造。

【参考文档片段】
{context_str}

用户问题：{query}
你的回答：
"""
    return prompt

user_question = "RAG包含哪些阶段？"
final_prompt = build_rag_prompt(user_question, chunks[:2])
print("\n组装完成Prompt:\n",final_prompt)

五、RAG系统调优

1. 常见问题分析

做RAG项目，经常遇到几类典型问题，我们逐个拆解。

现象 1：明明知识库里面有答案，但是检索召回不到正确片段。排查方向：

1. Embedding模型是否统一，入库和查询是不是同一个模型；
1. 文档切片是否把完整语义切碎，关键信息被拆分；
1. chunk过大，片段混杂大量无关内容，向量语义被稀释；
1. 向量数据库索引参数不合理，ANN索引召回精度不足；
1. 问题和文档表达方式差异大，没有做查询改写。

现象 2：检索召回了正确文档，但是大模型回答依旧错误，出现幻觉。排查方向：

1. Prompt没有强制约束模型不能编造，模型习惯自由发挥；
1. 检索回来的片段太多，token超限，部分上下文被截断丢失；
1. 多个召回片段里面存在互相冲突的信息，模型混淆；
1. 大模型本身能力不足，无法理解长参考上下文。

现象 3：召回大量无关文档，噪声很高。排查方向：

1. chunk设置过大，单块文本语义混杂；
1. 缺少rerank重排序环节，只依靠向量相似度；
1. 没有利用元数据过滤，检索范围过大。

现象 4：向量数据库查询慢，线上QPS上不去。排查方向：

1. 索引类型选择错误，海量向量使用暴力KNN；
1. 索引参数配置不合理；
1. 向量维度太高，向量数量巨大，硬件资源不足。

2. RAG优化手段

查询改写/查询扩展：

用户提问口语化、简短，直接向量化效果差。可以调用大模型，把原始问题改写为多个候选查询，多轮检索。
比如用户问 "这个系统怎么部署"，扩写成 "系统部署步骤、系统安装教程"，多向量同时检索，合并召回结果。

文档摘要索引：

长文档除了原始chunk，同时存储文档摘要向量。
检索的时候先检索摘要，定位对应文档，再拿文档内部片段，适合超长文档。

父‑子检索：

子块做检索，使用小chunk，保证检索精度，检索命中子块之后，取出对应的父完整大 chunk 送入大模型。兼顾检索精度和上下文完整性。

自我校验：

大模型回答完成之后，校验回答内容是否和参考文档一致，识别幻觉，做二次修正。

并不是所有项目都要一次性上全部高级能力，按需求应用实践顺序：先把基础链路调通，切片、embedding、rerank 调优，基础版本效果达标之后，再逐步叠加高级策略。

3. 应用实践细节

知识库更新机制：文档新增、修改、删除。向量数据库需要支持向量的删除更新。直接删除旧向量，写入新向量，要维护文档‑向量映射关系。不要简单重复追加，会产生大量重复噪声数据。
来源溯源：每一条回答，需要记录参考了哪些文档片段，输出文档来源 ID，方便校验答案可靠性。
资源开销：Embedding、Rerank、LLM都有算力消耗，要评估并发、GPU 资源。
评估体系：RAG 效果不能靠肉眼主观感受，需要做量化评估。数据集包含问题、期望参考文档，统计召回率、精确率，迭代参数的时候可以客观对比效果。
告警监控：监控向量库查询耗时、召回数量、token 消耗，异常告警。

4. 简易检索改写示例

python 复制代码

"""
查询改写简单示例，大模型生成多个候选query，提升召回
"""
def expand_query(llm, origin_query):
    prompt = f"""
请针对用户问题，生成2‑3个不同表达方式的查询，用于知识库检索，只输出查询，每行一个。
原始问题：{origin_query}
"""
    resp = llm.chat(prompt)
    query_list = [q.strip() for q in resp.split("\n") if len(q.strip())>0]
    query_list.append(origin_query)
    return list(set(query_list))

# 使用：多个query分别检索，合并去重结果
# multi_queries = expand_query(llm, "向量数据库如何优化RAG检索速度")

六、完整RAG应用示例

以下示例实现了一个带Rerank重排序的完整 RAG 问答流程：离线阶段用bge-small-zh将文档切片向量化存入Chroma；在线阶段先粗召回Top10，再用bge-reranker交叉编码器精排取Top3，最后组装Prompt送入大模型，显著提升检索精度与回答质量。

python 复制代码

from langchain.text_splitter import RecursiveCharacterTextSplitter
import chroma
from chroma import Client
from sentence_transformers import SentenceTransformer
from sentence_transformers import CrossEncoder

# ---------------------- 1.初始化模型 ----------------------
# 文档&查询嵌入模型
embedding_model = SentenceTransformer("BAAI/bge‑small‑zh‑v1.5")
# rerank重排序模型
rerank_model = CrossEncoder("BAAI/bge‑reranker‑small‑zh‑v2")

# 向量库初始化
chroma_client = Client()
try:
    chroma_client.delete_collection("rag_full_demo")
except:
    pass
coll = chroma_client.create_collection(name="rag_full_demo")

# ---------------------- 2.离线构建索引 ----------------------
raw_docs = [
    "RAG检索增强生成，不改动大模型权重，通过检索外部私有文档，补充模型上下文，缓解幻觉问题。",
    "向量数据库专门存储高维文本向量，提供高效ANN近似检索，是RAG系统的底层存储组件。",
    "文档切片是RAG关键步骤，切片过大过小都会损害检索效果，中文业务常用300‑800字符区间。",
    "Rerank重排序模型可以对向量粗召回结果做二次筛选，过滤无关噪声，显著提升RAG回答质量。"
]

# 文档切片
splitter = RecursiveCharacterTextSplitter(
    chunk_size=350,
    chunk_overlap=40,
    separators=["\n","。","，"]
)
all_chunks = []
for doc in raw_docs:
    chunks = splitter.split_text(doc)
    all_chunks.extend(chunks)

# 向量化入库
vec_list = embedding_model.encode(all_chunks).tolist()
ids = [f"chunk_{i}" for i in range(len(all_chunks))]
coll.add(embeddings=vec_list, documents=all_chunks, ids=ids)

# ----------------------3.RAG问答推理流程 ----------------------
def rag_answer(user_input:str):
    # 1.问题向量化，向量库粗召回top10
    q_vec = embedding_model.encode(user_input).tolist()
    res = coll.query(query_embeddings=[q_vec], n_results=10)
    recall_texts = res["documents"][0]

    # 2.rerank重排序
    rerank_inputs = [(user_input,text) for text in recall_texts]
    scores = rerank_model.predict(rerank_inputs)
    scored = list(zip(scores, recall_texts))
    scored.sort(key=lambda x:x[0], reverse=True)
    top_context = [item[1] for item in scored[:3]]

    # 3.组装prompt
    context_join = "\n---参考片段---\n".join(top_context)
    prompt = f"""
你是知识库问答助手，请严格依据下面参考片段回答用户问题。
如果参考片段没有对应信息，直接回复【未找到相关资料】，禁止编造任何内容。

参考片段：
{context_join}

用户问题：{user_input}
回答：
"""
    # 这里替换为你的大模型调用，示例直接打印prompt
    return prompt, top_context

if __name__ == "__main__":
    question = "RAG怎么缓解大模型幻觉？"
    final_prompt, context = rag_answer(question)
    print("===检索到的上下文===")
    for t in context:
        print("-",t)
    print("\n===送入LLM的Prompt===")
    print(final_prompt)

七、总结

总的来说，向量数据库、文档切片、Embedding、检索重排这些检索链路组件，才是决定RAG效果的基石。RAG不是一套复制粘贴就可以直接万能生效的模板。没有万能的chunk大小，没有万能Embedding，没有一套参数适配全部业务。真正落地，需要理解每一个环节的影响，针对自己业务文档做调试、对比、迭代。

向量数据库作为整套检索增强系统底座，它的选型、索引配置、向量存储、检索策略，直接决定整套系统的上限。掌握向量数据库实践，理解向量化检索完整逻辑，我们就可以独立设计、落地适配业务的高效向量化检索解决方案，把大模型知识库真正落地到业务场景之中。