1. 为什么Embeddings是LLM开发的分水岭1.1 从文字接龙到语义空间的认知跃迁很多人学LLM开发前几天都在跟API调用、Prompt模板、Token计费打交道感觉无非就是调个接口、拼个字符串。到了第七天接触Embeddings才第一次真正触碰到大模型的内脏——原来机器不是靠字面匹配来理解世界的它把每个词、每句话都塞进了一个高维坐标系里用距离远近表达语义亲疏。这件事的意义在哪儿你想想传统搜索是怎么做的关键词匹配。用户搜苹果手机电池不耐用系统就去找包含苹果手机电池这些字眼的文档。但用户真正想问的可能是iPhone续航差怎么办字面上一个词都对不上传统方案直接歇菜。Embeddings干的事情就是把苹果手机电池不耐用和iPhone续航差怎么办这两句话映射到向量空间里相近的位置让机器算出它们说的是同一件事。这就是语义检索的底层逻辑也是RAG检索增强生成、知识库问答、推荐系统、聚类分析、去重、分类等一大票应用的基石。你后面要做的LLM Wiki知识库、向量数据库集成、GraphRAG、本体RAG全都建立在Embeddings之上。所以我说它是分水岭——前面六天你在学怎么用LLM从今天开始你在学怎么喂LLM。1.2 谁需要认真搞懂这一块如果你只是想做个聊天机器人调个API套个壳Embeddings你可以先跳过。但只要你的需求里出现了下面任何一个词这块就必须啃下来知识库问答用户问的问题和文档里的表述不一样怎么找到最相关的段落语义搜索不想只匹配关键词想按意思搜。去重与聚类一万条用户反馈怎么自动归类成几十个主题推荐系统给用户推荐相似的内容相似怎么定义RAG检索增强生成检索这一步靠的就是Embeddings。零基础也能看懂但前提是你得接受一个反直觉的事实文字变成一串数字之后反而更能表达它的意思。这听起来像玄学但背后是扎实的数学和工程。1.3 本篇要解决的核心问题我会带你搞清楚四件事第一Embeddings到底是什么向量里的每个数字代表什么第二怎么选模型、怎么调API、怎么算相似度第三怎么把它接进向量数据库做成一个能用的语义检索demo第四实际开发中那些文档不会写的坑比如维度选择、归一化、批量处理、成本控制。全程用可复现的代码和参数不玩虚的。你跟着敲一遍就能拥有一个属于自己的语义检索小系统。2. Embeddings到底是什么把语义塞进坐标系2.1 一个生活化的类比图书馆的坐标系统想象一个巨大的图书馆每本书都要放在某个位置上。传统做法是按书名首字母排架A开头的放一起B开头的放一起。但这样有个问题《Python编程》和《蟒蛇养殖手册》会被放在一起因为它们都以P开头可内容八竿子打不着。Embeddings的做法是给每本书算一组坐标比如0.8, -0.3, 0.5, ...这组坐标不是按字母算的而是按内容含义算的。讲编程的书坐标会聚在一块讲动物的书坐标聚在另一块讲烹饪的又在另一块。你拿一本新书进来算出它的坐标看看它离哪一堆最近就知道它该放哪儿。这组坐标就是向量Vector把文字转成向量的过程就是Embedding。向量的维度通常是几百到几千比如OpenAI的text-embedding-3-small是1536维BGE-M3是1024维。每一维都代表某种抽象的语义特征单看某一维你解释不了它是什么意思但整体组合起来就能表达语义。2.2 向量里的数字到底代表什么这是新手最容易懵的地方。我拿一个简化到3维的例子来说明真实模型是上千维原理一样假设我们训练了一个极简模型三个维度分别对应科技感情感色彩正式程度。那么词语维度1科技感维度2情感维度3正式度计算机0.90.10.7电脑0.880.120.68爱情0.10.950.3喜欢0.150.90.2你看计算机和电脑的坐标几乎重合因为它们是同义词爱情和喜欢靠得近因为语义相关而计算机和爱情离得很远。真实模型里没有这么明确的维度含义它是通过海量文本训练自动学出来的但效果是一样的语义相近的词向量距离就近。这里要澄清一个常见误解向量里的数字不是概率不是权重也不是某种可解释的标签。它就是一组坐标唯一的意义在于相对位置。单独看(0.9, 0.1, 0.7)这组数你啥也看不出来但把它和别的向量放一起比距离语义关系就浮现了。2.3 相似度怎么算余弦相似度是主力有了向量怎么判断两句话像不像最常用的是余弦相似度Cosine Similarity。它算的是两个向量夹角的余弦值范围从-1到1越接近1越相似。公式是这样的cosine_similarity(A, B) (A · B) / (||A|| * ||B||)其中A·B是点积||A||是向量A的范数长度。为什么用余弦而不是欧氏距离因为余弦只看方向不看长度。文本长度不同会导致向量长度不同但方向语义可能一致余弦能消除长度干扰。我实测下来绝大多数Embedding模型输出的向量都做了归一化长度为1这时候余弦相似度就等于点积计算更快。所以你在代码里经常看到直接算点积的写法不是偷懒是数学上等价。注意如果你用的模型没做归一化一定要手动归一化否则相似度算出来会偏。判断方法很简单算一下向量的L2范数接近1就是归一化过了。2.4 从词向量到句向量粒度问题早期的Word2Vec、GloVe是词级别的一个词一个向量。但实际应用里我们要处理的是句子、段落、整篇文档。于是有了句向量模型比如Sentence-BERT、BGE、GTE、M3E这些。句向量不是简单把词向量加起来平均那样会丢失语序和语法信息。它是用Transformer编码整句话取[CLS]标记的输出或者做池化Pooling得到固定长度的向量。所以狗咬人和人咬狗的句向量是不一样的而词向量平均法会得到相同结果。选模型的时候要注意这个粒度你要做短文本检索选句向量模型要做长文档检索选支持长上下文的模型比如BGE-M3支持8192 token。粒度选错效果直接打折。3. 模型选型与API调用实操3.1 主流Embedding模型对比与选择逻辑市面上的Embedding模型分两大类闭源API和开源本地模型。选哪个不是拍脑袋要看你的场景。模型类型维度最大长度中文效果成本适用场景text-embedding-3-small闭源API15368191良好按量付费快速原型、英文为主text-embedding-3-large闭源API30728191优秀较贵高精度检索BGE-M3开源本地10248192优秀免费中文知识库、多语言BGE-large-zh开源本地1024512优秀免费纯中文短文本GTE-large开源本地1024512良好免费中英文混合M3E-base开源本地768512良好免费轻量级部署选择逻辑我总结成三条第一数据敏感度。如果你的文档涉及内部资料、客户数据别往闭源API送老老实实本地部署开源模型。数据出不了自己的服务器这是底线。第二中文占比。中文为主就选BGE系列或M3E它们在中文语料上训练充分。英文为主可以选OpenAI的模型。中英混合选BGE-M3它支持多语言。第三成本与性能平衡。原型阶段用API快速验证验证通过后如果量大换成开源本地模型省钱。我算过一笔账100万条文档每条500字用text-embedding-3-small大概几美元用本地模型就是电费但需要一张能跑的显卡。3.2 用Ollama本地跑Embedding模型很多人装了Ollama之后不知道怎么用它的向量模型这里给一个完整流程。Ollama的好处是把模型下载、加载、推理全封装好了一条命令搞定。先拉模型ollama pull bge-m3拉完之后确认一下ollama list你会看到bge-m3出现在列表里。然后就可以通过HTTP接口调用了curl http://localhost:11434/api/embeddings -d { model: bge-m3, prompt: 什么是向量数据库 }返回的JSON里有个embedding字段就是1024维的向量。Python里更简单import requests def get_embedding(text, modelbge-m3): resp requests.post( http://localhost:11434/api/embeddings, json{model: model, prompt: text} ) return resp.json()[embedding] vec get_embedding(什么是向量数据库) print(len(vec)) # 1024提示Ollama的embeddings接口一次只能处理一条文本批量处理要自己写循环。如果量大建议用transformers库直接加载模型支持batch推理速度快好几倍。3.3 用OpenAI API的注意事项如果你用OpenAI的接口代码是这样的from openai import OpenAI client OpenAI(api_key你的key) def get_embedding(text, modeltext-embedding-3-small): resp client.embeddings.create(inputtext, modelmodel) return resp.data[0].embedding几个坑要注意第一输入有token上限超了会报错长文档要先切分。第二一次请求可以传一个列表批量处理比循环单条快得多也省钱虽然单价一样但省网络往返。第三返回的向量默认已经归一化可以直接算点积。# 批量处理 texts [文本1, 文本2, 文本3] resp client.embeddings.create(inputtexts, modeltext-embedding-3-small) vectors [d.embedding for d in resp.data]3.4 维度选择不是越高越好新手容易有个误区觉得维度越高越好。其实不然。维度高确实能表达更细的语义但代价是存储和计算成本线性增长。1536维的向量100万条就是1536 * 4字节 * 100万 ≈ 6GBfloat323072维直接翻倍。而且高维还有个维度灾难问题维度越高向量之间的区分度反而可能下降检索精度不一定提升。实践中1024维对大多数中文场景已经够用。如果非要降维可以用PCA或者Matryoshka模型OpenAI的3系列支持截断维度把1536维截到512维精度损失很小存储省三分之二。我的建议先用模型默认维度跑通效果不够再考虑升维成本敏感就考虑降维。别一上来就追求最高维度。4. 从向量到检索搭建你的第一个语义搜索系统4.1 向量数据库选型Chroma、FAISS还是Milvus有了向量下一步是存起来并能快速检索。你不可能每次查询都遍历所有向量算一遍相似度100万条数据这么干要等到天荒地老。向量数据库就是干这个的它用近似最近邻ANN算法把检索复杂度从O(n)降到O(log n)级别。主流选择数据库部署难度适用规模特点Chroma极低小到中型嵌入式pip装完就能用适合原型FAISS低中型Facebook出品纯库不是服务性能强Milvus中大型分布式支持亿级向量运维成本高Qdrant中中大型Rust写的性能好API友好pgvector低中小型PostgreSQL插件已有PG就直接用零基础入门我强烈建议从Chroma开始。它不需要单独起服务pip install chromadb就能用数据存本地文件代码几行就能跑通。等你数据量上来了再迁移到Milvus或Qdrant。4.2 完整实操用Chroma搭一个知识库检索下面是一个能直接跑的完整例子。假设我们有一个小知识库存了几条关于LLM的问答用户输入问题系统返回最相关的条目。import chromadb from chromadb.utils import embedding_functions # 1. 初始化客户端数据存本地 client chromadb.PersistentClient(path./my_kb) # 2. 指定embedding函数这里用Ollama的bge-m3 # 注意Chroma内置了OllamaEmbeddingFunction ollama_ef embedding_functions.OllamaEmbeddingFunction( urlhttp://localhost:11434/api/embeddings, model_namebge-m3 ) # 3. 创建集合 collection client.get_or_create_collection( namellm_knowledge, embedding_functionollama_ef ) # 4. 添加文档 documents [ Embedding是把文本映射到高维向量的技术, 向量数据库用于高效存储和检索向量, RAG是检索增强生成结合了检索和生成, Token是模型处理文本的最小单位, 余弦相似度衡量两个向量的方向接近程度 ] ids [fdoc_{i} for i in range(len(documents))] collection.add(documentsdocuments, idsids) # 5. 查询 results collection.query( query_texts[怎么判断两句话意思相近], n_results2 ) print(results[documents])跑出来你会发现虽然查询里没有余弦相似度这些词但返回的第一条就是余弦相似度衡量两个向量的方向接近程度。这就是语义检索的威力。4.3 相似度计算的代码实现如果你想自己算不依赖数据库也很简单import numpy as np def cosine_similarity(a, b): a np.array(a) b np.array(b) return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) # 假设vec1, vec2是两个embedding sim cosine_similarity(vec1, vec2) print(f相似度: {sim:.4f})如果向量已经归一化直接np.dot(a, b)就行。批量算的话用矩阵运算def batch_similarity(query_vec, doc_vecs): query_vec np.array(query_vec) doc_vecs np.array(doc_vecs) # 归一化 query_norm query_vec / np.linalg.norm(query_vec) doc_norms doc_vecs / np.linalg.norm(doc_vecs, axis1, keepdimsTrue) # 矩阵乘法一次算完 return doc_norms query_norm这个批量版本比循环快几十倍数据量大的时候必须用。4.4 分块策略长文档怎么处理实际文档往往很长一篇文章几千字直接embedding会超出模型长度限制而且语义会被稀释。所以要分块Chunking。分块策略直接影响检索效果我踩过的坑按固定长度切简单但会切断句子语义不完整。适合对精度要求不高的场景。按句子/段落切保留语义完整性但块大小不均。推荐用这个。重叠切分相邻块之间留50-100字重叠避免边界信息丢失。这个最稳。递归切分先按段落段落太长再按句子句子还长再按字符。LangChain的RecursiveCharacterTextSplitter就是这个思路。参数上块大小建议256-512 token重叠50-100 token。太小检索碎片化太大语义不聚焦。这个没有标准答案要拿你的数据实测调优。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(long_document)5. 常见问题与避坑实录5.1 检索结果不准的排查思路这是最高频的问题。用户觉得明明有相关文档怎么没检索出来。排查顺序第一检查embedding模型是否一致。入库用的模型和查询用的模型必须是同一个否则向量空间对不上相似度全是乱的。我见过有人入库用bge-m3查询用text-embedding-3结果惨不忍睹。第二检查归一化。如果入库时归一化了查询时没归一化相似度会偏。统一处理。第三检查分块。如果相关答案被切成了两半分别存在两个块里检索时可能两个块都不够相关。这时候要调整分块策略或者用重叠切分。第四检查top_k。默认返回前几条如果相关文档排在第5条你只取前3条就漏了。适当调大top_k再用重排序Rerank精排。第五考虑加Rerank。Embedding检索是粗排速度快但精度有限。加一个Cross-Encoder重排序模型比如bge-reranker先召回20条再精排出前5条效果提升明显。5.2 性能与成本优化技巧批量处理无论API还是本地模型批量永远比单条快。API批量省网络往返本地批量能充分利用GPU并行。缓存相同文本的embedding结果缓存起来避免重复计算。用字典或者Redis都行。文档没变就不用重新算。降维存储吃紧就用Matryoshka截断或者PCA降维1024维降到512维精度损失通常小于2%。量化float32存不下就存float16甚至int8存储省一半到四分之三精度损失可控。FAISS和Milvus都支持量化索引。异步批量入库时用异步请求别一条条等。Python的asyncio配合aiohttp吞吐量能翻好几倍。5.3 常见问题速查表问题现象可能原因解决方法相似度全是0.9以上向量未归一化或模型退化检查归一化换模型检索结果完全不相关入库查询模型不一致统一模型长文档检索效果差分块不合理调整块大小和重叠内存爆了向量维度太高或数据量大降维、量化、分批加载查询很慢没用ANN索引建HNSW或IVF索引中文效果差模型不支持中文换BGE或M3EAPI报错超长输入超token限制先切分再embedding5.4 几个我踩过的坑坑一以为维度越高越好。早期我用3072维模型存储爆炸检索还慢后来降到1024维效果几乎没差别。维度够用就行。坑二忽略token限制。有次直接拿一篇5000字的文章去embeddingAPI直接报错。后来老老实实分块每块500字。坑三没做归一化。自己实现的相似度函数忘了归一化结果相似度算出来大于1排查半天才发现。坑四top_k设太小。默认取1条结果相关文档排第2直接漏掉。现在我都取10条再重排。坑五忘了缓存。开发阶段反复跑同样的文本每次都重新算embedding浪费时间和钱。加个缓存字典立竿见影。6. 从Embedding到RAG下一步怎么走6.1 Embedding在RAG中的位置你现在应该明白了RAG的RRetrieval就是靠Embedding实现的。完整流程是文档分块 → 每块算Embedding → 存入向量数据库 → 用户提问 → 问题算Embedding → 检索最相似的块 → 把块作为上下文喂给LLM → LLM生成答案。Embedding是这条链路的咽喉。它检索得准LLM才能答得对它检索得偏LLM再强也是巧妇难为无米之炊。所以第七天这个内容是后面所有高级应用的地基。6.2 进阶方向混合检索与重排序纯向量检索有个短板对精确匹配不敏感。比如用户搜一个产品型号XYZ-1234向量检索可能返回一堆语义相近但型号不对的文档。解决办法是混合检索向量检索 关键词检索BM25两路结果融合。这样既有语义理解又有精确匹配。再往上走是重排序。粗排召回50条用Cross-Encoder精排把最相关的5条挑出来。Cross-Encoder把query和doc拼在一起过模型精度比双塔的Embedding高但速度慢所以只用在精排阶段。6.3 知识库场景的实战建议如果你要做LLM Wiki知识库或者企业知识库我的建议是第一元数据要存。除了向量把文档来源、标题、时间、作者这些元数据一起存检索时可以按元数据过滤比如只搜最近一年的文档。第二分块要带上下文。每个块前面加上它所属的章节标题这样检索出来的块自带语境LLM理解更准。第三定期重建索引。文档更新了对应的向量要重新算。别用旧向量配新文档会出乱子。第四监控检索质量。记录用户的查询和点击分析哪些查询没检索到好结果针对性优化分块和模型。Embedding这块内容理论不复杂但工程细节特别多。我建议你别光看动手把上面的代码跑一遍用自己的数据试试踩几个坑比看十篇文章都管用。后面做RAG的时候你会感谢今天打下的基础。 Embeddings：LLM开发分水岭，语义检索与向量数据库实战
1. 为什么Embeddings是LLM开发的分水岭1.1 从文字接龙到语义空间的认知跃迁很多人学LLM开发前几天都在跟API调用、Prompt模板、Token计费打交道感觉无非就是调个接口、拼个字符串。到了第七天接触Embeddings才第一次真正触碰到大模型的内脏——原来机器不是靠字面匹配来理解世界的它把每个词、每句话都塞进了一个高维坐标系里用距离远近表达语义亲疏。这件事的意义在哪儿你想想传统搜索是怎么做的关键词匹配。用户搜苹果手机电池不耐用系统就去找包含苹果手机电池这些字眼的文档。但用户真正想问的可能是iPhone续航差怎么办字面上一个词都对不上传统方案直接歇菜。Embeddings干的事情就是把苹果手机电池不耐用和iPhone续航差怎么办这两句话映射到向量空间里相近的位置让机器算出它们说的是同一件事。这就是语义检索的底层逻辑也是RAG检索增强生成、知识库问答、推荐系统、聚类分析、去重、分类等一大票应用的基石。你后面要做的LLM Wiki知识库、向量数据库集成、GraphRAG、本体RAG全都建立在Embeddings之上。所以我说它是分水岭——前面六天你在学怎么用LLM从今天开始你在学怎么喂LLM。1.2 谁需要认真搞懂这一块如果你只是想做个聊天机器人调个API套个壳Embeddings你可以先跳过。但只要你的需求里出现了下面任何一个词这块就必须啃下来知识库问答用户问的问题和文档里的表述不一样怎么找到最相关的段落语义搜索不想只匹配关键词想按意思搜。去重与聚类一万条用户反馈怎么自动归类成几十个主题推荐系统给用户推荐相似的内容相似怎么定义RAG检索增强生成检索这一步靠的就是Embeddings。零基础也能看懂但前提是你得接受一个反直觉的事实文字变成一串数字之后反而更能表达它的意思。这听起来像玄学但背后是扎实的数学和工程。1.3 本篇要解决的核心问题我会带你搞清楚四件事第一Embeddings到底是什么向量里的每个数字代表什么第二怎么选模型、怎么调API、怎么算相似度第三怎么把它接进向量数据库做成一个能用的语义检索demo第四实际开发中那些文档不会写的坑比如维度选择、归一化、批量处理、成本控制。全程用可复现的代码和参数不玩虚的。你跟着敲一遍就能拥有一个属于自己的语义检索小系统。2. Embeddings到底是什么把语义塞进坐标系2.1 一个生活化的类比图书馆的坐标系统想象一个巨大的图书馆每本书都要放在某个位置上。传统做法是按书名首字母排架A开头的放一起B开头的放一起。但这样有个问题《Python编程》和《蟒蛇养殖手册》会被放在一起因为它们都以P开头可内容八竿子打不着。Embeddings的做法是给每本书算一组坐标比如0.8, -0.3, 0.5, ...这组坐标不是按字母算的而是按内容含义算的。讲编程的书坐标会聚在一块讲动物的书坐标聚在另一块讲烹饪的又在另一块。你拿一本新书进来算出它的坐标看看它离哪一堆最近就知道它该放哪儿。这组坐标就是向量Vector把文字转成向量的过程就是Embedding。向量的维度通常是几百到几千比如OpenAI的text-embedding-3-small是1536维BGE-M3是1024维。每一维都代表某种抽象的语义特征单看某一维你解释不了它是什么意思但整体组合起来就能表达语义。2.2 向量里的数字到底代表什么这是新手最容易懵的地方。我拿一个简化到3维的例子来说明真实模型是上千维原理一样假设我们训练了一个极简模型三个维度分别对应科技感情感色彩正式程度。那么词语维度1科技感维度2情感维度3正式度计算机0.90.10.7电脑0.880.120.68爱情0.10.950.3喜欢0.150.90.2你看计算机和电脑的坐标几乎重合因为它们是同义词爱情和喜欢靠得近因为语义相关而计算机和爱情离得很远。真实模型里没有这么明确的维度含义它是通过海量文本训练自动学出来的但效果是一样的语义相近的词向量距离就近。这里要澄清一个常见误解向量里的数字不是概率不是权重也不是某种可解释的标签。它就是一组坐标唯一的意义在于相对位置。单独看(0.9, 0.1, 0.7)这组数你啥也看不出来但把它和别的向量放一起比距离语义关系就浮现了。2.3 相似度怎么算余弦相似度是主力有了向量怎么判断两句话像不像最常用的是余弦相似度Cosine Similarity。它算的是两个向量夹角的余弦值范围从-1到1越接近1越相似。公式是这样的cosine_similarity(A, B) (A · B) / (||A|| * ||B||)其中A·B是点积||A||是向量A的范数长度。为什么用余弦而不是欧氏距离因为余弦只看方向不看长度。文本长度不同会导致向量长度不同但方向语义可能一致余弦能消除长度干扰。我实测下来绝大多数Embedding模型输出的向量都做了归一化长度为1这时候余弦相似度就等于点积计算更快。所以你在代码里经常看到直接算点积的写法不是偷懒是数学上等价。注意如果你用的模型没做归一化一定要手动归一化否则相似度算出来会偏。判断方法很简单算一下向量的L2范数接近1就是归一化过了。2.4 从词向量到句向量粒度问题早期的Word2Vec、GloVe是词级别的一个词一个向量。但实际应用里我们要处理的是句子、段落、整篇文档。于是有了句向量模型比如Sentence-BERT、BGE、GTE、M3E这些。句向量不是简单把词向量加起来平均那样会丢失语序和语法信息。它是用Transformer编码整句话取[CLS]标记的输出或者做池化Pooling得到固定长度的向量。所以狗咬人和人咬狗的句向量是不一样的而词向量平均法会得到相同结果。选模型的时候要注意这个粒度你要做短文本检索选句向量模型要做长文档检索选支持长上下文的模型比如BGE-M3支持8192 token。粒度选错效果直接打折。3. 模型选型与API调用实操3.1 主流Embedding模型对比与选择逻辑市面上的Embedding模型分两大类闭源API和开源本地模型。选哪个不是拍脑袋要看你的场景。模型类型维度最大长度中文效果成本适用场景text-embedding-3-small闭源API15368191良好按量付费快速原型、英文为主text-embedding-3-large闭源API30728191优秀较贵高精度检索BGE-M3开源本地10248192优秀免费中文知识库、多语言BGE-large-zh开源本地1024512优秀免费纯中文短文本GTE-large开源本地1024512良好免费中英文混合M3E-base开源本地768512良好免费轻量级部署选择逻辑我总结成三条第一数据敏感度。如果你的文档涉及内部资料、客户数据别往闭源API送老老实实本地部署开源模型。数据出不了自己的服务器这是底线。第二中文占比。中文为主就选BGE系列或M3E它们在中文语料上训练充分。英文为主可以选OpenAI的模型。中英混合选BGE-M3它支持多语言。第三成本与性能平衡。原型阶段用API快速验证验证通过后如果量大换成开源本地模型省钱。我算过一笔账100万条文档每条500字用text-embedding-3-small大概几美元用本地模型就是电费但需要一张能跑的显卡。3.2 用Ollama本地跑Embedding模型很多人装了Ollama之后不知道怎么用它的向量模型这里给一个完整流程。Ollama的好处是把模型下载、加载、推理全封装好了一条命令搞定。先拉模型ollama pull bge-m3拉完之后确认一下ollama list你会看到bge-m3出现在列表里。然后就可以通过HTTP接口调用了curl http://localhost:11434/api/embeddings -d { model: bge-m3, prompt: 什么是向量数据库 }返回的JSON里有个embedding字段就是1024维的向量。Python里更简单import requests def get_embedding(text, modelbge-m3): resp requests.post( http://localhost:11434/api/embeddings, json{model: model, prompt: text} ) return resp.json()[embedding] vec get_embedding(什么是向量数据库) print(len(vec)) # 1024提示Ollama的embeddings接口一次只能处理一条文本批量处理要自己写循环。如果量大建议用transformers库直接加载模型支持batch推理速度快好几倍。3.3 用OpenAI API的注意事项如果你用OpenAI的接口代码是这样的from openai import OpenAI client OpenAI(api_key你的key) def get_embedding(text, modeltext-embedding-3-small): resp client.embeddings.create(inputtext, modelmodel) return resp.data[0].embedding几个坑要注意第一输入有token上限超了会报错长文档要先切分。第二一次请求可以传一个列表批量处理比循环单条快得多也省钱虽然单价一样但省网络往返。第三返回的向量默认已经归一化可以直接算点积。# 批量处理 texts [文本1, 文本2, 文本3] resp client.embeddings.create(inputtexts, modeltext-embedding-3-small) vectors [d.embedding for d in resp.data]3.4 维度选择不是越高越好新手容易有个误区觉得维度越高越好。其实不然。维度高确实能表达更细的语义但代价是存储和计算成本线性增长。1536维的向量100万条就是1536 * 4字节 * 100万 ≈ 6GBfloat323072维直接翻倍。而且高维还有个维度灾难问题维度越高向量之间的区分度反而可能下降检索精度不一定提升。实践中1024维对大多数中文场景已经够用。如果非要降维可以用PCA或者Matryoshka模型OpenAI的3系列支持截断维度把1536维截到512维精度损失很小存储省三分之二。我的建议先用模型默认维度跑通效果不够再考虑升维成本敏感就考虑降维。别一上来就追求最高维度。4. 从向量到检索搭建你的第一个语义搜索系统4.1 向量数据库选型Chroma、FAISS还是Milvus有了向量下一步是存起来并能快速检索。你不可能每次查询都遍历所有向量算一遍相似度100万条数据这么干要等到天荒地老。向量数据库就是干这个的它用近似最近邻ANN算法把检索复杂度从O(n)降到O(log n)级别。主流选择数据库部署难度适用规模特点Chroma极低小到中型嵌入式pip装完就能用适合原型FAISS低中型Facebook出品纯库不是服务性能强Milvus中大型分布式支持亿级向量运维成本高Qdrant中中大型Rust写的性能好API友好pgvector低中小型PostgreSQL插件已有PG就直接用零基础入门我强烈建议从Chroma开始。它不需要单独起服务pip install chromadb就能用数据存本地文件代码几行就能跑通。等你数据量上来了再迁移到Milvus或Qdrant。4.2 完整实操用Chroma搭一个知识库检索下面是一个能直接跑的完整例子。假设我们有一个小知识库存了几条关于LLM的问答用户输入问题系统返回最相关的条目。import chromadb from chromadb.utils import embedding_functions # 1. 初始化客户端数据存本地 client chromadb.PersistentClient(path./my_kb) # 2. 指定embedding函数这里用Ollama的bge-m3 # 注意Chroma内置了OllamaEmbeddingFunction ollama_ef embedding_functions.OllamaEmbeddingFunction( urlhttp://localhost:11434/api/embeddings, model_namebge-m3 ) # 3. 创建集合 collection client.get_or_create_collection( namellm_knowledge, embedding_functionollama_ef ) # 4. 添加文档 documents [ Embedding是把文本映射到高维向量的技术, 向量数据库用于高效存储和检索向量, RAG是检索增强生成结合了检索和生成, Token是模型处理文本的最小单位, 余弦相似度衡量两个向量的方向接近程度 ] ids [fdoc_{i} for i in range(len(documents))] collection.add(documentsdocuments, idsids) # 5. 查询 results collection.query( query_texts[怎么判断两句话意思相近], n_results2 ) print(results[documents])跑出来你会发现虽然查询里没有余弦相似度这些词但返回的第一条就是余弦相似度衡量两个向量的方向接近程度。这就是语义检索的威力。4.3 相似度计算的代码实现如果你想自己算不依赖数据库也很简单import numpy as np def cosine_similarity(a, b): a np.array(a) b np.array(b) return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) # 假设vec1, vec2是两个embedding sim cosine_similarity(vec1, vec2) print(f相似度: {sim:.4f})如果向量已经归一化直接np.dot(a, b)就行。批量算的话用矩阵运算def batch_similarity(query_vec, doc_vecs): query_vec np.array(query_vec) doc_vecs np.array(doc_vecs) # 归一化 query_norm query_vec / np.linalg.norm(query_vec) doc_norms doc_vecs / np.linalg.norm(doc_vecs, axis1, keepdimsTrue) # 矩阵乘法一次算完 return doc_norms query_norm这个批量版本比循环快几十倍数据量大的时候必须用。4.4 分块策略长文档怎么处理实际文档往往很长一篇文章几千字直接embedding会超出模型长度限制而且语义会被稀释。所以要分块Chunking。分块策略直接影响检索效果我踩过的坑按固定长度切简单但会切断句子语义不完整。适合对精度要求不高的场景。按句子/段落切保留语义完整性但块大小不均。推荐用这个。重叠切分相邻块之间留50-100字重叠避免边界信息丢失。这个最稳。递归切分先按段落段落太长再按句子句子还长再按字符。LangChain的RecursiveCharacterTextSplitter就是这个思路。参数上块大小建议256-512 token重叠50-100 token。太小检索碎片化太大语义不聚焦。这个没有标准答案要拿你的数据实测调优。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(long_document)5. 常见问题与避坑实录5.1 检索结果不准的排查思路这是最高频的问题。用户觉得明明有相关文档怎么没检索出来。排查顺序第一检查embedding模型是否一致。入库用的模型和查询用的模型必须是同一个否则向量空间对不上相似度全是乱的。我见过有人入库用bge-m3查询用text-embedding-3结果惨不忍睹。第二检查归一化。如果入库时归一化了查询时没归一化相似度会偏。统一处理。第三检查分块。如果相关答案被切成了两半分别存在两个块里检索时可能两个块都不够相关。这时候要调整分块策略或者用重叠切分。第四检查top_k。默认返回前几条如果相关文档排在第5条你只取前3条就漏了。适当调大top_k再用重排序Rerank精排。第五考虑加Rerank。Embedding检索是粗排速度快但精度有限。加一个Cross-Encoder重排序模型比如bge-reranker先召回20条再精排出前5条效果提升明显。5.2 性能与成本优化技巧批量处理无论API还是本地模型批量永远比单条快。API批量省网络往返本地批量能充分利用GPU并行。缓存相同文本的embedding结果缓存起来避免重复计算。用字典或者Redis都行。文档没变就不用重新算。降维存储吃紧就用Matryoshka截断或者PCA降维1024维降到512维精度损失通常小于2%。量化float32存不下就存float16甚至int8存储省一半到四分之三精度损失可控。FAISS和Milvus都支持量化索引。异步批量入库时用异步请求别一条条等。Python的asyncio配合aiohttp吞吐量能翻好几倍。5.3 常见问题速查表问题现象可能原因解决方法相似度全是0.9以上向量未归一化或模型退化检查归一化换模型检索结果完全不相关入库查询模型不一致统一模型长文档检索效果差分块不合理调整块大小和重叠内存爆了向量维度太高或数据量大降维、量化、分批加载查询很慢没用ANN索引建HNSW或IVF索引中文效果差模型不支持中文换BGE或M3EAPI报错超长输入超token限制先切分再embedding5.4 几个我踩过的坑坑一以为维度越高越好。早期我用3072维模型存储爆炸检索还慢后来降到1024维效果几乎没差别。维度够用就行。坑二忽略token限制。有次直接拿一篇5000字的文章去embeddingAPI直接报错。后来老老实实分块每块500字。坑三没做归一化。自己实现的相似度函数忘了归一化结果相似度算出来大于1排查半天才发现。坑四top_k设太小。默认取1条结果相关文档排第2直接漏掉。现在我都取10条再重排。坑五忘了缓存。开发阶段反复跑同样的文本每次都重新算embedding浪费时间和钱。加个缓存字典立竿见影。6. 从Embedding到RAG下一步怎么走6.1 Embedding在RAG中的位置你现在应该明白了RAG的RRetrieval就是靠Embedding实现的。完整流程是文档分块 → 每块算Embedding → 存入向量数据库 → 用户提问 → 问题算Embedding → 检索最相似的块 → 把块作为上下文喂给LLM → LLM生成答案。Embedding是这条链路的咽喉。它检索得准LLM才能答得对它检索得偏LLM再强也是巧妇难为无米之炊。所以第七天这个内容是后面所有高级应用的地基。6.2 进阶方向混合检索与重排序纯向量检索有个短板对精确匹配不敏感。比如用户搜一个产品型号XYZ-1234向量检索可能返回一堆语义相近但型号不对的文档。解决办法是混合检索向量检索 关键词检索BM25两路结果融合。这样既有语义理解又有精确匹配。再往上走是重排序。粗排召回50条用Cross-Encoder精排把最相关的5条挑出来。Cross-Encoder把query和doc拼在一起过模型精度比双塔的Embedding高但速度慢所以只用在精排阶段。6.3 知识库场景的实战建议如果你要做LLM Wiki知识库或者企业知识库我的建议是第一元数据要存。除了向量把文档来源、标题、时间、作者这些元数据一起存检索时可以按元数据过滤比如只搜最近一年的文档。第二分块要带上下文。每个块前面加上它所属的章节标题这样检索出来的块自带语境LLM理解更准。第三定期重建索引。文档更新了对应的向量要重新算。别用旧向量配新文档会出乱子。第四监控检索质量。记录用户的查询和点击分析哪些查询没检索到好结果针对性优化分块和模型。Embedding这块内容理论不复杂但工程细节特别多。我建议你别光看动手把上面的代码跑一遍用自己的数据试试踩几个坑比看十篇文章都管用。后面做RAG的时候你会感谢今天打下的基础。