1. 项目缘起为什么企业级RAG绕不开向量数据库最近两年但凡和AI应用沾点边的技术讨论RAG检索增强生成这个词的出镜率都高得吓人。从技术沙龙到产品发布会似乎不提RAG就显得不够前沿。但说实话我见过太多团队兴致勃勃地启动RAG项目最后却卡在了一个看似基础、实则决定成败的环节如何高效、稳定地管理海量的文档向量。这就像你要建一座现代化的图书馆藏书文档有了图书管理员大语言模型也请来了但图书的索引卡片系统向量检索却还是手工抄写、按拼音排序。当读者用户来查询时管理员得花半天时间在一堆卡片里翻找效率低下不说一旦数据量上到百万、千万级别整个系统直接就瘫痪了。企业级应用面临的正是这种挑战数据规模大、查询并发高、对准确性和响应速度有严苛要求。这时候一个专用的向量数据库就不再是“可选项”而是“必选项”。它就是这个现代化图书馆的自动化索引与检索中枢。在众多选择中Milvus之所以能脱颖而出成为很多团队的首选不是没有道理的。它原生为向量搜索设计从底层架构上就考虑到了高维向量的相似性计算、大规模数据的分布式存储与检索。你可以把它理解为一个为“向量”这种特殊数据类型量身定制的“搜索引擎”其核心能力就是在亿级甚至十亿级的向量集合中以毫秒级的速度找到与查询向量最相似的那一小撮。所以当我们谈论“基于Milvus构建企业级RAG问答系统”时我们本质上是在讨论如何为RAG这个“大脑”配上一个强大的“海马体”记忆与检索系统。本文将抛开那些浮于表面的概念直接切入实战从系统架构的核心原理讲起一步步拆解如何利用Milvus搭建一个真正能扛住企业级压力的RAG问答后台。我会结合我最近在一个金融知识库项目中的实战经验分享从环境部署、数据处理、检索优化到工程化落地的完整链条以及那些官方文档里不会写的“坑”和应对技巧。2. 核心架构拆解一个企业级RAG系统的五脏六腑在动手写第一行代码之前我们必须先搞清楚我们要建造的究竟是个什么东西。一个完整的企业级RAG问答系统远不止是“切文本、转向量、存起来、查一下”这么简单。它是一个精密的流水线每个环节的设计都直接影响最终的回答质量与系统性能。2.1 从用户问题到精准答案的完整旅程让我们跟随一个用户提问走一遍数据在系统中的完整生命周期用户提问用户在界面上输入“公司债券和金融债券的主要区别是什么”查询理解与向量化系统首先对这个问题进行“理解”。这不仅仅是分词更关键的是将其转化为一个能代表其语义的“向量”。我们使用与大模型配套的嵌入模型Embedding Model将文本“公司债券和金融债券的主要区别”转换成一个高维空间中的点例如一个768维或1536维的向量。这个点就是我们在向量海洋中要寻找的“灯塔”。向量检索召回这个查询向量被送入Milvus。Milvus的工作是在它管理的、早已存储好的海量文档片段向量中快速找出与这个“灯塔”距离最近即最相似的Top K个向量。这个过程叫做“召回”。这里Milvus的索引算法如IVF_FLAT, HNSW和搜索参数决定了召回的速度和精度。多路召回与混合检索可选但重要为了提升召回结果的相关性和覆盖率高级系统不会只依赖向量检索。它可能并行发起多路召回向量检索路如上所述基于语义相似度。关键词检索路如BM25同时用传统搜索引擎的技术查找包含“公司债券”、“金融债券”、“区别”等关键词的文档。这能有效补充单纯语义检索可能遗漏的关键信息。元数据过滤路结合业务标签如“文档类型产品说明书”、“部门金融市场部”对召回结果进行预过滤。 Milvus自身支持标量过滤即基于元数据的过滤可以很好地与向量搜索结合实现高效的混合查询。重排序Rerank从各召回通道得到的结果可能多达上百条质量参差不齐。直接扔给大模型会引入噪音。因此需要一个更精细的“重排序”模型对所有这些候选文档片段进行相关性打分只保留分数最高的前3-5条。这一步能显著提升最终注入上下文的文档质量。上下文构建与提示工程将精挑细选出来的文档片段按照相关性顺序组合成一个结构化的“上下文”。然后将其与用户的原始问题一起填充到一个设计好的提示词模板中。例如“请基于以下知识库内容回答问题{context}。问题{question}。请确保答案严格依据提供的内容。”大模型生成将组装好的提示词发送给大语言模型如GPT-4、Claude或开源的Qwen、ChatGLM。模型基于给定的上下文生成最终答案。答案返回与可能的后处理将生成的答案返回给用户。有时还会进行后处理如格式化、添加引用来源具体到哪段文档等。2.2 Milvus在其中扮演的关键角色在整个流程中Milvus的核心职责聚焦在第3步并对第4步提供基础支持。它的性能、稳定性和易用性直接决定了系统检索环节的天花板。海量向量管理企业文档库轻松达到百万、千万级文本片段每个片段对应一个向量。Milvus的分布式架构可以水平扩展轻松应对这个规模。高性能相似性搜索这是Milvus的看家本领。它支持多种近似最近邻搜索算法在精度和速度之间取得平衡确保即使在海量数据中也能实现毫秒级响应。标量过滤与混合查询允许在向量搜索的同时附加诸如doc_type 年报 and publish_year 2020这样的过滤条件实现基于业务规则的精准召回。动态数据管理支持数据的实时插入、删除和更新这对于需要频繁更新知识库的企业场景至关重要。理解了这套架构我们就能明白搭建RAG系统Milvus是基石但绝不是全部。我们需要围绕它搭建起数据预处理、嵌入模型服务、重排序服务、大模型网关等一系列组件。接下来我们就从最基础的环节开始——让Milvus跑起来。3. 实战第一步Milvus的部署与选型避坑指南“万事开头难”在Milvus这里开头就是部署。官方提供了多种部署方式从最简单的Docker Compose到完整的Kubernetes集群。对于大多数企业级开发测试甚至中小规模生产环境我强烈推荐从Docker Compose方式开始。它简单、清晰、易于理解和排错。3.1 基于Docker Compose的单机部署详解为什么首选Docker Compose因为它把Milvus依赖的所有组件元数据存储、对象存储、消息队列等都打包在了一个编排文件里一键拉起环境高度一致完美复现。步骤1环境准备确保你的服务器可以是本地开发机、云服务器满足操作系统Linux (Ubuntu 18.04 CentOS 7.5) macOS 或 Windows (通过WSL2)。对于生产环境Linux是唯一推荐。Docker Engine: 19.03Docker Compose: 1.25.1硬件至少4核CPU8GB内存。向量搜索是CPU密集型操作CPU性能直接影响搜索速度。注意很多人在CentOS 7.5等旧系统上安装Docker会踩坑。务必按照Docker官方文档配置稳定的镜像源并关闭SELinux。如果是为了快速验证使用Ubuntu系统会省心很多。步骤2获取配置文件不用自己从头写直接从Milvus的GitHub仓库获取对应版本的docker-compose.yml。# 创建一个项目目录 mkdir milvus-rag cd milvus-rag # 下载最新稳定版的docker-compose文件以2.3.x为例 wget https://github.com/milvus-io/milvus/releases/download/v2.3.3/milvus-standalone-docker-compose.yml -O docker-compose.yml步骤3启动Milvus一条命令启动所有服务sudo docker-compose up -d使用docker-compose ps命令查看所有容器是否都正常启动状态为Up。关键容器包括milvus-standalone: Milvus核心服务。etcd: 元数据存储。minio: 对象存储用于存储向量索引文件。步骤4验证安装安装完成后如何验证Milvus在正常工作我们可以使用其自带的Python SDK进行连接测试。# 安装Milvus Python SDK pip install pymilvus2.3.3然后创建一个简单的Python测试脚本test_connection.pyfrom pymilvus import connections, utility # 连接到本地的Milvus服务 connections.connect(hostlocalhost, port19530) # 检查连接是否成功并列出已有的集合类似数据库的表 print(utility.list_collections())运行这个脚本如果没有报错并输出一个空列表[]恭喜你Milvus服务已经成功运行。3.2 生产环境选型Standalone vs. Cluster上面的Docker Compose启动的是Standalone单机模式。它把所有组件都部署在一个节点上适合开发、测试和小规模数据场景向量数量在千万级以下。当你的数据量达到亿级或者对高可用、负载均衡有严格要求时就必须考虑Cluster集群模式。集群模式将Milvus的组件查询节点、数据节点、索引节点等进行分布式部署可以实现水平扩展通过增加节点来提升存储和计算能力。高可用单个节点故障不会导致整个服务不可用。资源隔离将读写负载分配到不同节点。部署集群通常采用KubernetesK8s方案利用Milvus官方提供的Helm Chart。这对于运维团队有较高的K8s能力要求。我的建议是初期从Standalone开始快速验证业务逻辑当业务数据和并发量增长到单机瓶颈时再平滑迁移到集群架构。Milvus的数据格式和API在两种模式下是兼容的这大大降低了迁移成本。3.3 你可能遇到的“坑”与解决方案端口冲突Milvus默认使用19530端口。如果该端口被占用需要在docker-compose.yml中修改映射端口。磁盘空间不足向量索引文件可能非常大。确保Minio容器挂载的宿主机目录有充足空间数百GB甚至TB级。内存不足导致容器崩溃向量加载和搜索非常吃内存。如果容器频繁重启请检查系统内存和Docker内存限制。可以在docker-compose.yml中为milvus-standalone服务增加资源限制milvus-standalone: mem_limit: 8g # 限制最大内存8GB mem_reservation: 4g # 保留内存4GB客户端连接超时确保防火墙放行了19530端口。在云服务器上还需要检查安全组规则。部署只是万里长征第一步。一个空的Milvus实例就像一座空的图书馆大楼。接下来我们要为它建立“藏书体系”也就是定义数据结构和灌入数据。4. 数据建模与处理为知识库打造高效的“书架”在Milvus中数据组织的基本单位是Collection集合可以类比为关系数据库中的“表”。每个Collection包含多个Field字段其中必须有一个且只能有一个是Vector Field向量字段用来存储文档的嵌入向量。其他字段可以是标量如文档ID、标题、段落原文、所属类别等用于辅助过滤和检索。4.1 设计你的第一个Collection SchemaSchema定义了Collection的结构。一个好的Schema设计是高效检索的基础。假设我们要构建一个金融产品知识库一个经典的Schema设计如下from pymilvus import CollectionSchema, FieldSchema, DataType # 1. 定义字段 # 主键字段必须是整数或字符串 fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), # 向量字段假设我们使用768维的向量 FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim768), # 标量字段存储原文用于最终返回给大模型 FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), # 标量字段文档来源如文件名 FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), # 标量字段文档类型用于过滤 FieldSchema(namedoc_type, dtypeDataType.VARCHAR, max_length50), # 标量字段该片段在原文中的页码或位置 FieldSchema(namepage_no, dtypeDataType.INT64), ] # 2. 创建Collection Schema schema CollectionSchema(fields, description金融知识库文档片段集合) # 3. 创建Collection from pymilvus import Collection collection_name financial_knowledge_base collection Collection(namecollection_name, schemaschema)设计要点解析auto_idTrue让Milvus自动生成递增的ID避免自己维护ID冲突非常省心。dim768这个维度必须与你选用的嵌入模型输出的向量维度严格一致。例如text-embedding-ada-002是1536维bge-large-zh是1024维。这里是设计时最容易出错的地方之一。text字段务必存储原始文本Milvus返回的是向量ID你需要根据ID查到对应的原文才能拼装上下文。很多人忘了存原文导致检索出向量后找不到对应的文本。标量字段像doc_type,source这样的字段是为后续的混合查询准备的。你可以轻松地执行诸如“在‘年报’类型的文档中搜索”这样的查询。4.2 文档预处理与向量化从PDF到向量这是RAG流水线的“原料加工厂”其质量直接决定最终答案的准确性。核心步骤包括步骤1文档加载与解析使用像PyPDF2,pdfplumber,langchain的文档加载器将PDF、Word、HTML等格式的文档转换成纯文本。步骤2文本分割Chunking这是最关键也最讲究经验的一步。你不能把整篇100页的PDF存成一个向量那样检索精度会极差。也不能切得太碎会丢失上下文信息。常用策略按固定长度重叠滑动窗口。例如每段文本500个字符下一段从前一段的250字符后开始重叠250字符。这保证了上下文连续性。高级策略按语义分割。使用自然语言处理技术识别段落、标题在语义边界处进行分割。这需要更复杂的模型但效果更好。我的经验对于金融、法律等强逻辑文档优先尝试按章节/标题分割。对于普通文章固定长度重叠如512 token重叠128 token是一个稳健的起点。务必根据你的文档类型进行测试和调整。步骤3向量化Embedding将分割好的文本片段通过嵌入模型转化为向量。本地模型如BAAI/bge-large-zh中文效果好使用sentence-transformers库。from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-large-zh) embeddings model.encode(text_chunks)云服务API如OpenAI的text-embedding-3-smallAzure OpenAI的嵌入服务。优势是省事但会产生API调用费用和网络延迟。选择建议对数据隐私要求高、希望控制成本的选本地模型。追求极致效果和开发效率的可以选用云服务。务必统一不能一部分数据用A模型另一部分用B模型因为不同模型生成的向量空间不同无法直接比较相似度。步骤4数据灌入Milvus将向量和对应的元数据文本、来源等批量插入到Collection中。# 假设我们已有数据列表 # entities [ [id1, id2,...], [vec1, vec2,...], [text1, text2,...], ... ] # 注意entities中各个字段的数据必须严格对齐且顺序与schema定义一致。 # 批量插入每次插入数万条为宜避免单次太大 insert_result collection.insert(entities) # 插入后务必执行flush将数据持久化 collection.flush() print(f已插入 {collection.num_entities} 条数据。)4.3 索引创建为高速检索铺路数据插入后还不能直接进行高效搜索。你需要为向量字段创建索引。索引是牺牲少量精度和存储空间换取搜索速度的巨大提升。# 定义索引参数 index_params { metric_type: IP, # 相似度度量方式IP内积或 L2欧氏距离。通常嵌入向量归一化后IP等价于余弦相似度。 index_type: IVF_FLAT, # 索引类型IVF_FLAT是精度和速度的平衡选择。HNSW速度更快内存占用稍高。 params: {nlist: 1024} # IVF_FLAT的参数将向量空间划分为1024个单元。数据量越大这个值可以适当增大。 } # 在embedding字段上创建索引 collection.create_index(field_nameembedding, index_paramsindex_params) # 将集合加载到内存对于Standalone这步是必须的否则无法搜索 collection.load()索引选型经验谈IVF_FLAT通用性最好在精度和速度之间取得了很好的平衡支持标量过滤。如果你的场景没有特殊要求首选它。HNSW搜索速度极快尤其适合超高维向量但构建索引较慢内存占用高且早期版本对标量过滤支持不如IVF_FLAT。适合对延迟极度敏感、数据量不是特别大的场景。SCANN更注重召回率Recall的场景。参数调优nlistIVF系列或M/efConstructionHNSW等参数需要根据数据量调整。一个粗略的原则nlist可以设置为sqrt(向量总数)左右然后通过实际查询测试进行微调。至此你的“图书馆”已经藏书就绪索引卡片系统也已建立完毕。接下来就是最激动人心的环节如何从这座图书馆里快速准确地找到用户想要的“那本书”5. 检索、优化与工程化让RAG系统真正“智能”起来有了数据和索引检索看似只是一句collection.search()的调用但其中门道很深。一个未经优化的检索很可能返回一堆相关但不精确的结果导致大模型生成“幻觉”答案或答非所问。5.1 基础检索与混合查询让我们先看一个最基础的向量检索示例# 1. 将用户问题转化为向量 question 公司债券的发行主体有哪些 question_vector embedding_model.encode([question])[0] # 得到一个向量 # 2. 定义搜索参数 search_params {metric_type: IP, params: {nprobe: 10}} # nprobe是搜索时探查的单元数越大越准越慢 # 3. 执行搜索 results collection.search( data[question_vector], # 搜索向量 anns_fieldembedding, # 在哪个字段上搜索 paramsearch_params, limit10, # 返回最相似的10条结果 output_fields[id, text, source, doc_type] # 指定返回哪些标量字段 ) # 4. 解析结果 for hits in results: for hit in hits: print(fID: {hit.id}, 距离: {hit.distance}, 文本: {hit.entity.get(text)[:100]}...)这实现了纯语义搜索。但在企业场景我们往往需要混合查询即结合语义和业务规则。# 在搜索时增加标量过滤表达式 results collection.search( data[question_vector], anns_fieldembedding, paramsearch_params, limit10, exprdoc_type 债券产品说明书, # 关键过滤表达式 output_fields[id, text, source] )这个查询的意思是“在债券产品说明书这类文档里进行语义搜索”。这能极大地提升检索的精准度避免从无关的文档类型如新闻稿中召回信息。5.2 多路召回与重排序提升召回质量的黄金组合单一向量检索在应对复杂、多义词或需要精确匹配的场景时可能力有不逮。多路召回是工业级RAG的标配。方案设计并行发起查询路A语义路使用Milvus向量检索limit50。路B关键词路使用Elasticsearch或数据库的全文索引进行BM25关键词检索limit50。可以提取用户问题中的实体和关键词进行查询。结果去重与合并根据文档ID对两路结果进行去重。重排序将合并后的所有候选文档可能80-100条送入一个重排序模型。这个模型比嵌入模型更精细能计算查询与每个文档之间的相关性分数。模型选择可以使用交叉编码器Cross-Encoder如BAAI/bge-reranker-large。它虽然比双编码器慢但精度高适合对少量候选进行精排。调用方式将(query, document)对批量输入重排序模型得到分数。Top-N筛选根据重排序分数选取最高的3-5个文档片段作为最终上下文。# 伪代码示例重排序流程 import torch from transformers import AutoModelForSequenceClassification, AutoTokenizer reranker_model_name BAAI/bge-reranker-large tokenizer AutoTokenizer.from_pretrained(reranker_model_name) model AutoModelForSequenceClassification.from_pretrained(reranker_model_name) candidate_pairs [(question, doc[text]) for doc in merged_candidates] inputs tokenizer(candidate_pairs, paddingTrue, truncationTrue, return_tensorspt, max_length512) with torch.no_grad(): scores model(**inputs).logits.squeeze(-1) # 得到相关性分数 # 根据分数对候选文档排序 ranked_indices scores.argsort(descendingTrue) final_contexts [merged_candidates[i] for i in ranked_indices[:5]]为什么重排序如此重要向量检索的“距离”或“相似度”是一个相对粗糙的度量。重排序模型通过更深入的交互注意力机制能更准确地判断一段文本是否真正回答了问题。实测中引入重排序能将答案的准确率提升15%-30%。5.3 性能调优与监控应对企业级流量当你的RAG服务从Demo走向生产面对成百上千的并发查询时性能调优就至关重要。1. 索引参数调优nprobe(IVF索引)这是搜索时最重要的参数之一。它决定了搜索需要探查的单元数量。值越大搜索越精确但耗时越长。你需要根据业务对延迟和召回率的要求找到一个平衡点。可以从sqrt(nlist)开始测试。ef(HNSW索引)HNSW的动态搜索参数作用类似nprobe。2. 批量搜索如果同时有多个查询务必使用批量搜索而不是循环单条查询。Milvus对批量搜索有深度优化。question_vectors [vec1, vec2, vec3] # 多个查询向量 results collection.search(dataquestion_vectors, anns_fieldembedding, paramsearch_params, limit10)3. 缓存策略查询缓存对高频、热点问题如“公司简介”的查询结果进行缓存直接返回避免重复的向量化和检索计算。嵌入缓存对常见的文档片段或问题文本的嵌入向量进行缓存避免重复调用嵌入模型。4. 监控与告警关键指标QPS每秒查询数、P99/P95延迟、召回率、错误率。Milvus指标通过Prometheus Grafana监控Milvus集群状态如节点资源使用率、查询队列长度、插入速率等。业务指标记录每次问答的查询文本、返回的文档ID、最终答案用于后续分析和效果评估。5.4 一个常见的“坑”向量维度不匹配与模型版本管理这是我踩过的一个实实在在的坑。项目初期使用了text-embedding-ada-002(1536维)后来为了降低成本切换为开源的bge-large-zh(1024维)。直接切换后新的数据用新模型嵌入维度是1024但Milvus Collection的Schema定义还是1536维导致数据无法插入。更糟糕的是旧数据1536维和新数据1024维存在于两个不同的向量空间中彼此无法进行有意义的相似度比较。解决方案严格模型版本管理将嵌入模型名称和版本作为Collection元数据的一部分记录下来。任何模型变更都视为重大变更。数据迁移方案如果必须切换模型需要创建一个新的、维度匹配的Collection。将所有历史数据用新模型重新嵌入一遍灌入新Collection。将流量逐步切换到新Collection并废弃旧Collection。这是一个重操作需要仔细规划和测试。6. 系统集成与效果评估从模块到服务Milvus搭建的检索核心需要被集成到一个完整的Web服务或API中。通常我们会构建一个RAG服务后端它对外提供统一的问答接口。6.1 构建RAG服务API可以使用FastAPI、Flask等框架快速搭建。一个简化的服务流程如下from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str filter_conditions: dict None # 可选的过滤条件 top_k: int 5 app.post(/ask) async def ask_question(request: QueryRequest): try: # 1. 查询理解可选如关键词提取 # 2. 向量化 query_vector embed(request.question) # 3. 构建Milvus查询表达式 expr build_expression(request.filter_conditions) # 4. 检索 search_results collection.search(data[query_vector], ..., exprexpr) # 5. 重排序如果有 ranked_results rerank(request.question, search_results) # 6. 构建Prompt调用LLM context \n\n.join([r.text for r in ranked_results[:3]]) prompt f基于以下信息\n{context}\n\n请回答问题{request.question} answer call_llm_api(prompt) # 调用OpenAI/Azure/本地LLM # 7. 返回结果可附带引用来源 return { answer: answer, sources: [{id: r.id, source: r.source} for r in ranked_results[:3]] } except Exception as e: raise HTTPException(status_code500, detailstr(e))6.2 效果评估如何判断你的RAG系统是好是坏上线不是终点。你需要一套评估体系来衡量RAG系统的效果。评估可以从多个维度进行检索阶段评估召回率RecallK对于一组标准问题系统返回的前K个结果中包含正确答案文档的比例。这是衡量检索能力的基础指标。平均排名Mean Reciprocal Rank, MRR正确答案在返回结果列表中的排名的倒数平均值。衡量系统把正确答案排在前面的能力。生成阶段评估答案准确性人工或通过LLM-as-a-Judge判断生成的答案是否准确。可以设计测试集进行批量评估。幻觉率答案中是否包含了知识库中不存在的信息。引用准确性答案中声称引用的来源是否真的支持该说法。端到端评估人工评测定期抽样一批真实用户问题由领域专家对答案质量进行打分如1-5分。A/B测试如果对系统做了优化如调整分块策略、更换嵌入模型可以通过A/B测试对比新旧版本在关键业务指标如用户满意度、问题解决率上的差异。一个实用的技巧构建“问题-标准答案-相关文档”测试集。在开发阶段就积累一批典型问题并标注好标准答案和相关的文档ID。每次代码更新或模型变更后跑一遍这个测试集自动化计算召回率和答案准确性能快速发现回归问题。6.3 持续迭代RAG系统是一个活系统企业知识是不断更新的。因此RAG系统也需要支持数据的增量更新和实时索引。增量更新定期如每天扫描新的文档经过相同的预处理和向量化流程后插入到Milvus Collection中。Milvus支持实时插入新数据在flush()和load()后即可被检索到。索引重建当数据量发生巨大变化如增长10倍后原有的索引参数可能不再最优。可以考虑在业务低峰期重建索引以优化性能。算法迭代关注嵌入模型、重排序模型、大模型等领域的最新进展。适时升级核心组件可以带来效果的显著提升。从我实际落地的经验来看基于Milvus构建RAG系统最难的不是让它跑起来而是让它跑得“准”、“快”、“稳”。这需要我们在数据预处理、检索策略、系统架构和效果评估上持续打磨。它不是一个一劳永逸的项目而是一个需要不断喂养数据、观察效果、进行调优的“智能生命体”。希望这篇从原理到实践的长文能为你启动自己的企业级RAG项目提供一张可靠的路线图避开我曾经踩过的那些坑。记住扎实的向量检索基础是上层智能应用大厦的地基这个地基值得你花时间打好。
