过去在做搜索或者知识库相关功能时我发现最头疼的问题不是“数据不够多”而是“明明数据都在库里用户就是搜不到想要的答案”。后来逐步接触到向量数据库、Embedding、RAG 这一整套技术栈才慢慢把这块拼图补完整。这篇文章会从一个相对系统的角度帮大家理清向量数据库到底是什么、它和 AI 知识库、语义搜索、RAG 之间的关联并且会用代码带你走一遍完整的落地流程。无论是正在入门 AI 应用开发还是已经在做企业级知识库、智能客服、私有化问答系统这篇文章都能给你一条清晰的学习路径和可直接复用的工程实践。1. 为什么传统搜索满足不了 AI 时代的需求在正式介绍向量数据库之前我们先看一个很常见的业务场景。你在一家公司的内部 Wiki 里维护了大量技术文档包括接口文档、部署手册、故障排查指南。员工遇到问题时希望在搜索框里输入一句自然语言描述就能找到最相关的一段内容甚至直接得到答案。传统方案通常是这样实现的基于 MySQL 的 LIKE 模糊查询基于 Elasticsearch 的倒排索引和 BM25 相关度评分基于数据库全文索引的简单匹配。这些方案的核心都是“关键词匹配”。搜索引擎会先对文档做分词建立一个倒排索引然后根据用户输入的词去倒排索引里找包含这些词的文档再用 TF-IDF、BM25 这样的算法计算相关性。但这会带来一个很典型的痛点用户输入的表达方式和文档里的用词不一致搜索效果就直线下降。举个例子文档里写的是“无人驾驶车辆在测试道路上的安全规范”用户搜索的是“自动驾驶路测注意事项”。如果按照传统的关键词匹配“无人驾驶”“自动驾驶”“路测”“测试道路”这些词汇并不能完全对上甚至可能一点都匹配不上于是用户什么都搜不到。再比如用户问“苹果公司最新发布的手机是什么”文档里写的是“iPhone 16 系列产品参数介绍”。这里“苹果”和“iPhone”之间没有直接的关键词关联但语义上它们指向同一个实体。传统搜索解决不了这个问题因为它不理解语义。于是在 AI 时代我们需要的是一种能够理解“意思”的检索方式语义搜索。而实现语义搜索离不开两个关键技术——Embedding 和向量数据库。2. 向量数据库是什么从“查字符串”到“算距离”2.1 核心概念向量数据库简单理解就是专门用来存储、索引和查询“向量数据”的数据库。所谓向量就是把文本、图片、音频等非结构化数据通过 Embedding 模型转换成一串固定长度的浮点数数组。比如一段文本经过 Embedding 模型处理后可能会变成一个 1024 维的向量[0.023, -0.134, 0.456, ..., 0.089] # 长度是 1024接下来向量数据库做的事情和传统数据库“查准确的字符串”完全不同。它的核心查询方式是“找相似”——给定一个查询向量在数据库里找到与它最相近的一批向量。举例说明传统数据库SELECT * FROM docs WHERE title 苹果发布会 向量数据库SELECT * FROM docs ORDER BY cosine_similarity(embedding, 苹果发布会嵌入向量) DESC LIMIT 10传统数据库要求字段值精确相等向量数据库则是把每一条记录变成一个高维空间里的点查询时计算“哪个点离我最近”。2.2 向量数据库和传统数据库的区别对比项传统关系型数据库向量数据库存储对象结构化数据如数字、字符串、日期非结构化数据的向量表示核心操作精确匹配、范围查询、JOIN相似度检索、最近邻搜索索引方式B Tree、HashHNSW、IVF、PQ 等向量索引查询语义等值、模糊、排序“语义相近”典型场景交易、订单、用户管理AI 知识库、RAG、推荐、去重这样对比之后应该很清晰了传统数据库擅长处理确定的、有规则的数据向量数据库擅长处理“无法精确表达但可以通过相似度衡量”的数据。2.3 向量相似度怎么计算向量数据库之所以能实现“语义相近”的检索是因为向量之间的空间距离可以反映语义距离。常用的相似度计算方式有以下三种。余弦相似度Cosine Similarity余弦相似度衡量的是两个向量在方向上的夹角值域是[-1, 1]越接近 1 表示越相似。文本 Embedding 场景中最常使用。similarity cos(A, B) A·B / (|A| * |B|)欧氏距离Euclidean Distance欧氏距离衡量的是两个点在空间中的直线距离数值越小越相似。它受向量长度影响较大。distance sqrt(sum((A[i] - B[i])^2))内积Dot Product内积同时考虑方向和长度常用于某些特定的 Embedding 模型。有些模型建议使用内积作为检索度量。选择哪种度量方式通常取决于 Embedding 模型的推荐配置。比如 OpenAI 的text-embedding-ada-002推荐使用余弦相似度有些开源模型推荐使用内积。如果模型没有特殊说明优先用余弦相似度即可。2.4 向量数据库的索引原理简介当数据库里的向量数量达到百万甚至亿级别时逐个计算相似度是不现实的。向量数据库会构建专门的向量索引核心思路是“牺牲一点精确度换取极快的检索速度”。比较主流的索引算法包括HNSWHierarchical Navigable Small World基于图结构的近似最近邻搜索算法检索速度快、召回率高是目前很多产品默认使用的索引类型IVFInverted File先对向量做聚类比如 K-Means查询时只在最相关的几个簇里搜索PQProduct Quantization把向量压缩成更小的表示大幅减少内存占用适合超大规模场景。大多数向量数据库对用户屏蔽了这些索引的底层实现细节默认配置就能获得不错的性能。但在生产环境中理解索引原理有助于你做调优。3. Embedding让计算机理解语义的关键一步3.1 Embedding 是什么Embedding 是将离散的、非结构化的数据文字、图片、音频等映射到一个连续的高维向量空间中的过程。以文本为例早期 NLP 领域常用 One-Hot 编码把词表示成向量但 One-Hot 的问题很明显维度过高、稀疏、无法表达词与词之间的关系。“苹果”和“iPhone”在 One-Hot 空间里的距离和“苹果”“冰箱”没有区别。现代 Embedding 模型通过深度学习训练将文本映射到一个语义向量空间中。在这个空间里语义相近的文本在距离上也相近。于是“苹果公司发布新手机” ≈ “Apple 推出了新款 iPhone” “今天天气怎么样” ≈ “请问今天适合出门吗”也就是说Embedding 模型学习到的不仅是“词的出现”还有“词背后的含义”和“上下文语境”。这也是语义搜索可以实现的技术基础。3.2 常见的 Embedding 模型文本 Embedding 模型有很多选择不同模型的维度、语言能力、效果和推理成本都不一样。模型语言向量维度特点OpenAI text-embedding-ada-002多语言1536闭源 API效果好需要调用接口OpenAI text-embedding-3-small多语言1536可降维新一代模型性价比更高BAAI/bge-m3中文、英文等多语言1024开源支持中英文混合场景可本地部署BAAI/bge-large-zh中文1024中文效果强MokaAI/m3e-base中文为主768轻量适合中文场景sentence-transformers/all-MiniLM-L6-v2英文384轻量适合入门学习和英文场景这里特别注意Embedding 模型的维度是固定的。同一个向量数据库中不能混用不同模型生成的向量否则查询时维度不一致检索会直接报错。3.3 使用 Transformers 生成 Embedding本地生成 Embedding 最常用的方式是使用sentence-transformers库或 HuggingFace 的transformers库。下面是一个使用sentence-transformers生成句向量的最小示例。# 文件路径embedding_demo.py from sentence_transformers import SentenceTransformer # 下载并加载模型首次运行会自动下载权重 model SentenceTransformer(BAAI/bge-m3) # 需要进行向量化的文本 sentences [ 苹果公司发布了新一代iPhone手机, 苹果是一种很好吃的水果, 自动驾驶技术正在快速发展, 无人驾驶汽车已经进入路测阶段 ] # 生成向量 embeddings model.encode(sentences, normalize_embeddingsTrue) # 打印向量维度和第一句的向量前10个值 print(f向量维度: {embeddings.shape}) print(f第一句向量前10个值: {embeddings[0][:10]})输出类似这样数值仅为示意向量维度: (4, 1024) 第一句向量前10个值: [ 0.0123 -0.0456 0.0789 ... ]如果觉得直接加载 bge-m3 比较重入门阶段也可以先用小模型from sentence_transformers import SentenceTransformer # 轻量级英文模型适合学习 model SentenceTransformer(all-MiniLM-L6-v2) embeddings model.encode([ What is vector database?, Vector database stores embeddings for similarity search. ]) print(embeddings.shape)注意sentence-transformers在加载模型时会自动从 HuggingFace 下载权重文件。如果网络条件受限可以选择离线下载模型文件后加载本地路径或使用国内可访问的模型镜像源。4. RAG把大模型和向量数据库组合起来4.1 为什么需要 RAG大语言模型虽然能生成流畅、专业的回答但有两个核心问题知识截止时间模型训练数据有截止日期之后发生的事情它不知道幻觉问题模型遇到不知道的知识时可能一本正经地编造答案而不是承认自己不知道。RAGRetrieval-Augmented Generation检索增强生成的思路是在让大模型生成回答之前先从外部知识库中检索相关内容把检索到的内容作为上下文一起交给大模型生成回答。这样做的直接好处是回答基于真实数据大幅降低幻觉知识可以实时更新不用重新训练模型可以把企业私有文档、个人资料接入 AI构建“专属于你的 AI 助手”。RAG 也是目前落地 AI 知识库最主流的方案。4.2 RAG 的完整流程一个标准的 RAG 流程分为两个阶段离线索引阶段和在线问答阶段。离线索引阶段加载文档PDF、Word、Markdown、数据库等文档清洗去除格式噪音、无关内容文本切块Chunking把长文档切成合适大小的片段用 Embedding 模型把每个片段转成向量把向量和原始文本存储到向量数据库。在线问答阶段用户输入问题用同一个 Embedding 模型把问题转成向量在向量数据库中检索最相似的 Top-K 个文本片段把问题 检索到的片段组装成 Prompt大模型根据上下文生成回答。整个流程用文字描述就是文档 -- 切块 -- Embedding -- 向量数据库 用户问题 -- Embedding -- 相似度检索 -- 相关片段 相关片段 用户问题 -- 大模型 -- 最终回答这里有个容易被忽略的细节用户问题也必须转成向量而且必须用和索引阶段完全相同的 Embedding 模型。如果索引时用的是 bge-m3查询时却用了 OpenAI 的模型向量的语义空间不一致检索结果将完全不可用。4.3 RAG 和 Agentic RAG 的关系传统的 RAG 流程是“一次检索、一次生成”的直线结构。如果第一次检索结果不理想直接进入生成阶段回答质量可能很差。Agentic RAG智能体化 RAG则把大模型从“生成器”升级为“决策者”。模型可以判断检索结果是否充足不足则改写查询后重新检索拆解复杂问题进行多轮、多路检索调用外部工具或 API 获取实时数据综合多个来源的信息后给出最终答案。对于复杂业务场景来说Agentic RAG 更灵活、上限更高但对 Prompt 设计、工具调用、安全管控的要求也更高。入门阶段建议先把基础 RAG 跑通再逐步演进。5. 环境准备与技术选型在动手写代码之前先明确本文示例环境操作系统Windows / macOS / Linux 均可以下命令以 Linux/macOS 为主Python3.9 或更高版本向量数据库Chroma轻量、嵌入式适合学习和原型开发Embedding 模型BAAI/bge-m3也提供小模型备选方案大模型示例中使用的是本地推理接口你也可以替换成任意 OpenAI-compatible API。5.1 安装依赖建议先创建一个新的 Python 虚拟环境python3 -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate然后安装依赖pip install chromadb sentence-transformers这里简单说明一下几个库的角色chromadb向量数据库客户端提供本地持久化存储和向量检索能力sentence-transformers加载 Embedding 模型把文本转成向量。如果本机没有 GPU安装 PyTorch 时会自动安装 CPU 版本bge-m3 模型在 CPU 上运行也没有问题只是批量生成向量时稍慢。5.2 向量数据库选型建议不同阶段的选型策略可以这样概括场景推荐方案理由学习、原型验证Chroma安装简单、嵌入式、无需独立服务中等规模项目Milvus / Qdrant / Weaviate功能丰富、性能好、支持分布式PostgreSQL 用户pgvector在现有数据库上增加向量能力不用引入新组件大型生产集群Milvus 或 Elasticsearch 向量检索成熟生态、可扩展性强Milvus 是目前开源向量数据库中使用率较高的项目适合大规模生产场景。但它的部署和运维成本也更高。新手入门时先用 Chroma 把 RAG 流程跑通理解核心逻辑后再迁移到 Milvus 就能很快上手。6. 实战用 Chroma bge-m3 搭建一个 AI 知识库下面我们做一个完整的 RAG 实操项目。项目目标是给定几篇技术文档用户以自然语言提问系统检索文档内容并生成回答。6.1 创建项目结构rag_demo/ ├── data/ │ └── docs/ # 存放原始文档 ├── ingest.py # 离线索引脚本 ├── query.py # 在线问答脚本 └── requirements.txt在data/docs目录下放几份示例文档比如产品介绍、FAQ、操作手册等纯文本或 Markdown 文件。这里以 Markdown 文件为例。6.2 编写离线索引脚本# 文件路径rag_demo/ingest.py import os from pathlib import Path import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer # 定义文档目录和向量数据库存储目录 DOCS_DIR Path(data/docs) CHROMA_DIR ./chroma_store # 加载 Embedding 模型 embedding_model SentenceTransformer(BAAI/bge-m3) print(fEmbedding 模型加载完成向量维度: {embedding_model.get_sentence_embedding_dimension()}) # 初始化 Chroma 客户端持久化存储 client chromadb.PersistentClient(pathCHROMA_DIR) # 创建或获取集合 # 注意集合名称可以自定义但要保持一致 collection client.get_or_create_collection( nametech_docs, metadata{hnsw:space: cosine} ) # 读取文档并切块 def read_and_chunk(file_path: Path, chunk_size: int 200, overlap: int 20): 简单切块逻辑按字符数切分保留重叠部分避免语义断裂。 text file_path.read_text(encodingutf-8) # 清理多余空行 lines [line.strip() for line in text.splitlines() if line.strip()] content \n.join(lines) chunks [] start 0 while start len(content): end start chunk_size chunks.append(content[start:end]) start end - overlap return chunks # 遍历文档生成向量并入库 all_ids [] all_documents [] all_embeddings [] all_metadatas [] for file_path in sorted(DOCS_DIR.glob(*.md)): chunks read_and_chunk(file_path) print(f处理文件: {file_path.name}切块数量: {len(chunks)}) for idx, chunk in enumerate(chunks): doc_id f{file_path.stem}_{idx} all_ids.append(doc_id) all_documents.append(chunk) all_metadatas.append({ source: file_path.name, chunk_index: idx }) # 批量生成向量 print(f开始生成向量共 {len(all_documents)} 个文本块...) all_embeddings embedding_model.encode( all_documents, normalize_embeddingsTrue, show_progress_barTrue ).tolist() # 写入向量数据库 collection.add( idsall_ids, documentsall_documents, embeddingsall_embeddings, metadatasall_metadatas ) print(f索引完成共入库 {len(all_documents)} 条数据。)这段代码的核心逻辑有几点需要注意PersistentClient会把向量数据持久化到本地目录下次启动不用重复构建索引get_or_create_collection避免了重复运行时创建重复集合hnsw:space设置了相似度计算方式为余弦相似度与 bge-m3 模型的推荐配置一致切块时使用overlap参数让相邻文本块之间保留一部分重叠内容防止一句话被硬生生截断。6.3 编写查询脚本# 文件路径rag_demo/query.py import chromadb from sentence_transformers import SentenceTransformer # 加载模型和客户端 embedding_model SentenceTransformer(BAAI/bge-m3) client chromadb.PersistentClient(path./chroma_store) collection client.get_collection(nametech_docs) def search(query: str, top_k: int 3): 在向量数据库中检索相关文档。 query_embedding embedding_model.encode( query, normalize_embeddingsTrue ).tolist() results collection.query( query_embeddings[query_embedding], n_resultstop_k, include[documents, metadatas, distances] ) return results def build_prompt(query: str, contexts: list) - str: 组装 Prompt把检索结果作为上下文。 context_str \n\n.join( f[来源: {meta[source]}]\n{doc} for doc, meta in zip(contexts[documents][0], contexts[metadatas][0]) ) prompt f你是一个企业知识库问答助手。请根据以下参考资料回答用户问题。 参考资料 {context_str} 用户问题{query} 请用中文回答。如果参考资料中没有相关信息请直接说明不要编造答案。 return prompt if __name__ __main__: # 示例查询 question 如何部署这个系统 contexts search(question, top_k3) print(检索结果) for i, (doc, meta) in enumerate(zip(contexts[documents][0], contexts[metadatas][0])): print(f\n--- 结果 {i1} (来源: {meta[source]}) ---) print(doc[:200]) prompt build_prompt(question, contexts) print(\n Prompt 预览 \n) print(prompt)这里先不直接调用大模型而是把检索结果和 Prompt 打印出来便于理解整个流程。在生产环境中只需要把build_prompt的结果发给大模型接口即可。6.4 调用大模型生成回答下面演示如何把 Prompt 发送给大模型。为了让示例通用这里采用 OpenAI-compatible 的接口风格。如果你用的是本地模型或第三方服务只需修改base_url和api_key。# 文件路径rag_demo/query_llm.py from openai import OpenAI # 这里以兼容 OpenAI 接口的本地/云端服务为例 client OpenAI( base_urlhttp://your-llm-endpoint/v1, # 替换成你自己的服务地址 api_keyyour-api-key # 替换成你的密钥 ) def generate_answer(prompt: str) - str: response client.chat.completions.create( modelyour-model-name, # 替换成模型名称 messages[ {role: system, content: 你是一个严谨的AI知识库助手。}, {role: user, content: prompt} ], temperature0.3, max_tokens1024 ) return response.choices[0].message.content如果暂时没有大模型接口也可以先跳过这一步只运行检索脚本确认能把正确的文档片段检索出来再接生成环节。6.5 运行与验证先运行索引脚本python ingest.py预期输出示意Embedding 模型加载完成向量维度: 1024 处理文件: deployment.md切块数量: 12 处理文件: faq.md切块数量: 8 开始生成向量共 20 个文本块... 索引完成共入库 20 条数据。然后运行查询脚本python query.py预期输出示意检索结果 --- 结果 1 (来源: deployment.md) --- 系统部署要求需要一台 Linux 服务器Docker 20.10 以上版本...如果检索结果和问题相关说明 RAG 的核心链路已经跑通。7. 进阶细节切块策略、模型选型与重排7.1 切块策略对效果的影响RAG 的召回效果很大程度取决于切块Chunking策略。切得太小单个块语义不完整切得太大向量表征被稀释检索精度下降。常见策略有以下几种策略适用场景优点缺点固定长度切块格式统一的文档简单、可控可能切断语义按段落/标题切块结构化文档Markdown、HTML语义完整块大小不均递归字符切块混合文本兼顾语义和长度需要调整参数语义切块内容复杂、变化大语义完整度高计算成本高一个经验参考值面向 RAG 的中文技术文档切块大小通常在 200 到 500 个字符左右重叠 20 到 50 个字符。具体数值需要根据文档形态和检索效果调整不要照搬。7.2 中文场景如何选 Embedding 模型如果你的知识库以中文为主优先选择对中文优化过的模型。bge-m3 是目前开源模型中综合表现较好的选择之一它支持中英文混合检索并且原生支持 1024 维向量。选择模型时还要考虑检索度量方式。bge 系列模型通常建议使用余弦相似度。在 Chroma 中通过metadata{hnsw:space: cosine}设置。是否做归一化。生成 Embedding 时建议开启normalize_embeddingsTrue这样余弦相似度和内积等价可以简化检索逻辑。部署成本。大型模型效果更好但推理资源要求也更高。如果文档量不大可以用 m3e-base、bge-small-zh 这类轻量模型。7.3 重排Rerank为什么重要向量检索召回的是“语义上最接近”的候选结果但语义接近不等于“真正能回答问题”。为了进一步提升效果工程上会在向量检索后面加一个重排环节。重排阶段使用专门的 Rerank 模型对向量检索召回的 Top-50 结果逐个计算更精确的相关性分数然后重新排序只把 Top-5 输入给大模型。典型流程向量检索召回 Top 50 ↓ Rerank 模型逐个打分 ↓ 保留 Top 3-5 输入给大模型Rerank 模型比 Embedding 模型更重所以通常不用于全量数据检索只对召回结果二次精排。常见的开源 Rerank 模型包括bge-reranker-base、bge-reranker-large等。7.4 混合检索是更稳的方案向量检索适合“语义相似”的场景但在处理关键词明确、术语独特的内容时传统全文检索反而更准。比如用户搜索“HTTP 502 错误码”向量检索可能召回一堆关于 HTTP 协议的泛泛内容而全文搜索能精确匹配到包含“502”的文档。生产级知识库一般会采用混合检索同时执行关键词检索BM25和向量检索通过 RRFReciprocal Rank Fusion或 Rerank 模型合并结果把最终结果交给大模型。方案看起来复杂但实际收益很高。先用向量检索保证召回率再用 BM25 保证精确匹配最后用 Rerank 统一排序。8. 常见问题与排查思路8.1 常见问题排查表问题现象常见原因解决思路查询时报维度不一致索引和查询使用了不同 Embedding 模型统一使用同一个模型重新构建索引检索结果完全无关查询时没有用同一个模型生成向量检查查询脚本对齐模型召回结果空文档切块过少或库为空检查入库数据量打印 collection.count() 确认回答质量差切块不合理导致上下文丢失调整 chunk_size 和 overlap增加 top_k内存占用过高文档量过大、索引参数不合理减少批量大小选用更轻量模型加载模型慢首次下载权重文件提前下载使用本地模型路径8.2 Embedding 模型不一致的问题这是 RAG 项目中最常见、也最隐蔽的问题。有些团队前期用 OpenAI API 生成向量后来为了私有化部署换了开源模型但历史数据没有重新构建索引导致线上检索效果直接崩掉。解决方案是模型一旦确定所有存量数据必须用新模型重新向量化后重新入库。Embedding 模型和向量数据库之间没有“兼容层”比对不同的向量体系没有意义。8.3 向量数据库数据更新问题知识库的文档会持续更新这就要求索引系统支持增量写入。简单做法是给每条数据增加一个唯一 ID重复执行索引脚本时覆盖写入。更规范的做法是引入文档版本管理按 source 字段批量删除旧数据再写入新数据。生产环境建议把索引脚本做成可定时调度的任务并记录每次索引的版本号方便回滚。9. 工程最佳实践与生产建议9.1 数据清洗是基础向量数据库和 RAG 的效果上限由输入数据决定。文档里的页眉页脚、重复片段、乱码符号、无关广告都会污染向量空间导致检索结果偏移。进入索引流程前建议统一转成 UTF-8 纯文本去掉多余空格、空白符、HTML 标签过滤无意义内容如“本文由某某整理”等页脚对 PDF 类文档特别注意 OCR 质量。9.2 为知识库建立评测集很多团队上线 RAG 后只能靠人工感受判断“效果大概还可以”一旦迭代就容易回归。更稳妥的做法是建立一个小规模评测集准备 50 到 200 条“问题 → 期望命中的文档片段”数据每次调参后跑一遍评测集记录召回率RecallK和最终答案质量评分用评测结果驱动参数调整而不是凭感觉。9.3 安全与权限控制知识库如果包含企业内部敏感信息务必注意向量数据库的访问权限要收敛不能直接暴露在公网检索接口要做用户鉴权并校验用户的文档访问权限某些流程中需要做到“用户只能检索到有权限的文档”也就是在向量检索时通过 metadata 过滤权限字段大模型生成阶段同样需要内容安全过滤防止输出违规内容。9.4 性能优化与成本控制向量检索的性能瓶颈主要在大规模数据的索引构建和查询延迟。常用优化方向对高频查询结果做缓存使用更小的 Embedding 模型bge-small 或 m3e-small降低向量化成本将不常变化的文档固定索引只对增量数据做增量更新对于百万级以上数据考虑 Milvus 这类独立部署的向量数据库。9.5 监控与可观测性RAG 系统上线后要关注几个关键指标检索耗时向量查询的 P95 延迟召回率回归测试结果是否稳定用户反馈用户对回答的点赞/点踩数据链路日志查询、召回、生成每个环节的输入输出都要能追溯。将这些指标接入监控系统后才能持续改进系统效果。10. 写在最后向量数据库只是起点不是终点从这篇文章的完整拆解来看向量数据库本身并不神秘。它解决的问题很明确把文本、图片等内容变成向量然后通过相似度计算完成语义检索。真正让向量数据库发挥价值的是你如何设计整个 RAG 链路——文档如何切块、Embedding 模型如何选、检索结果如何重排、Prompt 怎么组装。我在做知识库项目的过程中有一个很深的体会很多问题的根因不在向量数据库而在前面的数据质量和后面的生成策略。第一次跑通 Demo 很容易难的是把检索准确率从 80% 提升到 95% 以上这需要对切块、模型、重排、训练数据的持续优化。对于还没入门的读者建议按照这篇文章的示例先跑通一个最小可用的 RAG 系统理解数据流向然后再逐步替换组件、增加重排、引入 Agentic RAG。技术栈一直在变但“召回 → 增强 → 生成”这条主干逻辑会沿用很久。希望这篇文章对你有帮助可以收藏备用也欢迎在实际项目落地过程中对照着排查问题。
