这道题问的是[[RAG]]的[[向量化]]过程,其实本质是在问:怎么把非结构化文本转成机器能高效检索的语义表示,并且这个转换要能支撑实际业务。我不会去背一遍原理,而是按我理解的技术选型和工程落地说一下。
先说嵌入模型选型。很多人觉得直接拿个通用模型就行,但真正落地会发现,场景不同,选择差异很大。比如通用中文场景,我会用BGE-large-zh或者M3E,它们开源、能私有化部署,维度一般是768到1024,上下文长度够用。但如果业务是多语言,比如要检索中英文混合的文档,那E5-multilingual或者OpenAI的text-embedding-3更合适,跨语言对齐能力更强。再一个,如果是垂直领域,比如法律合同或者医疗报告,通用模型效果会打折扣,我倾向拿领域数据微调一下,哪怕只微调几百条,语义匹配的精度提升也很明显。这里有个边界:如果文档本身是结构化或者关键词密集的,比如订单号、错误码,那向量搜索不一定比[[BM25]]好,[[混合检索]]才是正解。
然后说文本[[分块]]策略,这是最容易被低估的坑。固定长度分块最简单,但具体token数要作为候选变量;它经常把一句话或者一个逻辑段切两半,导致检索时上下文不完整。递归分块会好一些,先按段落切,超长了再细分,尽量保持语义边界。还有语义分块,用模型判断边界,精度最高但计算成本也高。我的做法是:先比较递归分块、结构分块以及零重叠、短窗口、较长窗口,用同一评测集判断边界证据是否更完整。举个例子,客服退款场景下,一个退款政策文档里,不同条款之间有引用关系,如果分块切断了,检索到一半政策,模型可能误解。还有,我会保留元数据,比如标题、章节号,这样在[[重排]]时能辅助过滤。
向量归一化这块,很简单,L2归一化把向量长度变成1,这样余弦相似度等价于点积,计算能直接走矩阵乘法,在[[Faiss]]里批量检索快很多。
接下来是向量匹配。余弦相似度公式大家都知道,但归一化后就是点积,所以实际计算我用点积。精确检索适合万级以下数据,再大就必须上[[ANN]]。我常用的是[[HNSW]],图索引结构,召回率高,延迟低,适合线上服务。如果数据量到了亿级,内存扛不住,就加[[IVF-PQ]]做量化压缩,牺牲一点精度换内存。工程上,我会先走ANN粗排,取Top-100,再用[[Cross-Encoder]]精排,最后按相关性阈值过滤。这个流程在电商场景里做满减政策检索,效果很稳。
这里有个延伸点:分块策略和嵌入模型其实是耦合的。比如你用了长上下文模型,分块可以更大,但检索精度可能会因为噪声增加而下降。怎么调这个平衡,我觉得要看具体业务对召回率和准确率的要求。
落地风险方面,我特别关注三点:一是分块不合理导致检索结果碎片化;二是嵌入模型和业务语言不匹配,比如金融术语通用模型没学好;三是阈值设置太严或太松,影响用户体验。上线前我会用一批真实query回放,对比Recall@K和延迟,通过才切换。
所以,我更倾向把向量化看成一条流水线,每个环节都要根据业务场景做选择,没有银弹。