Embedding模型选择
根据MTEB榜单做初步的模型筛选
MTEB是几个全面的评测基准，可以查看不同模型在不同任务类型的表现（重排序，相关性，分类，聚类，检索）
- 明确业务场景与评估指标：核心任务是什么？衡量业务成功的指标是什么？
- 构建黄金测试集。
- 小范围对比测试。
向量数据库特点及选型
- Faiss：由Meta AI开发。提供最广泛、最前沿的ANN索引算法。支持CPU与GPU。核心算法库，非数据库。
- Milvus:支持多种ANN索引和丰富的调优参数。开源领导者，功能全面。云原生架构，高度可扩展。
- Pinecone：全托管的商业先驱，主打severless和易用性，API设计简介，性能稳定，专注于提供极致的低延迟检索。
- Weaviate：开源，内置数据向量化模块。能够连接各种embedding模型，实现数据的自动向量化，简化了开发流程
- Qdrant：开源，以性能和安全著称，使用Rust开发，过滤查询能力强大且高效
- ElasticSearch：通用搜索巨头，扩展向量检索能力。将向量检索KNN作为功能之一。可以无缝结合强大的全文检索，聚合分析能力。
2.性能表现
- Faiss：纯粹的性能标杆
- Milvus：在大规模数据集表现优异，吞吐量和延迟控制很好
- Pinecone：性能出色，低延迟方面有优势
- Weaviate：性能良好，自动化向量在开发效率上是亮点
- Qdrant：性能强劲，尤其是过滤条件复杂的混合查询下表现突出，内存使用率高
- ElasticSearch：向量检索性能弱于专门的向量数据库，但混合检索（关键词+向量）场景下，表现优异
3.适用场景
- Faiss：算法研究者，需要将向量检索能力深度集成到现有系统中的团队
- milvus：需要处理海量数据，对性能和扩展性有高要求的企业级应用
- Pinecone：追求快速上线
- Weaviate：希望简化ETL的，希望快速构建从数据到向量到检索的全链路应用的开发者
- Qdrant：对检索性能和资源利用率有极致要求的场景。金融，电商需要复杂的过滤规则的 应用
- ElasticSearch：业务需求以文本为主，向量搜索为辅。
切块策略
专有名词解释
- token：AI眼里的字，1个汉字=1～1.5个token。英文大约4个字母=1个token。512token≈300/400个汉字
- overlap：相邻两块重叠的部分。
方法
- 固定长度切：500token一切，容易把句子，表格，代码切断。
- 递归字符切：Langchain的RecursiveCharacterTextSplitter：先试着按段落切，切不动按换行、空格、单字退而求其次。会尽量保住自然边界，零额外成本。通用场景首选。
- 结构感知切：按Md标题，合同条款好、PDF页面切。技术文档、法律合同、财报最适用
- 语义切：靠embedding算相邻句子的相似度，语义断裂处吓到。成本高，容易切的太岁。
- 代码感知切：语法树按照函数或者类切，保证代码块完整，代码库专用
权衡
1.语义完整性vs检索精度
| 块太小 | 块太大 | |
|---|---|---|
| 检索 | 很准 | 看起来相关但说不清 |
| 生成答案 | 信息被切断，AI答不全 | 上下文完整但夹杂无用内容 |
| 成本 | 向量多，存储和检索变贵 | 向量少但是给LLM的内容长 |
经验表明：极端值通常不行，512～1024token切通常效果不错。事实问答篇小块，复杂分析偏大。
2.召回率vs噪声
切得细。召回高，但容易召回到重复的。切的粗召回低，但信息量大
overlap
一般10%～20% 法律条款和医疗参数这类高密度参数可以25%～30%
只要用overlap必须开启去重和多样性控制。
overlap不是越大越好，会导致向量数量多，索引重建时间变长。费用高。topk出现近亲，重排序负载大。改overlap导致缓存失效。
向量检索 · 关键词检索 · 混合检索 · Rerank
- BM25：基于词频（TF）逆文档频率IDF+长度归一化打分。适合精确匹配
- 向量检索：做余弦相似度计算排序返回。适合理解语义
- 重排序：embedding是Bi-encoder。query与文档独立编码。检索只需要矩阵运算。Rerank是cros-encoder。把query-doc拼一起，让子注意力逐字逐词交互，直接输出相关性得分，慢但是判断深，，复杂度高，适用于小规模数据集。
- 如何混合。向量检索额结果0～1.bm25结果分布不确定，没有固定范围。加权融合需要归一化，随着数据集语料变化就要调权重。RRF只看名次，k不敏感。
多模态Embedding
主要处理办法
- OCR：便宜且快，但布局颜色丢失
- 描述化：VLM生成文字描述，再走文本RAG。自然语言检索增强，复用现有文本线。缺点是贵且慢。丢失关键数据
- 视觉向量化：CLIP/SigLIP/统一多模态直接出向量。以图搜图，跨模态检索，版面信息部分保留。但全局池化后逻辑关系被平均掉。
为什么选统一多模态：补充1，2的盲区。OCR丢布局，描述丢精度且不稳定。但代价是存储和延迟更大、纯文本检索能力弱于专用文本模型。
企业级落地默认混合检索：1+2做语义向量，同时保留3的视觉向量，三路召回后再融合。
图片的处理
图片与文字不能分开储存。以视觉元素为中心、当前追溯标题、向后绝壑解释段落，打包成图文共生chunk。
- 表格必须使用Mineru/unstructured/LlamaParse转换为Markdown或者HTML，保住行列关系。
- 分层索引（表粒度、行粒度）
- 表头字段单独建倒排索引（BM25），数字字段建范围索引。
视频处理
三层漏斗索引
| 层级 | 粒度 | 内容 | 作用 |
|---|---|---|---|
| 视频级 | 整个视频 | VLM 生成的整体摘要，或全局特征池化 | 快速粗筛，先把候选视频从 1 万部压到 10 部 |
| 片段级 | 10--60 秒（按场景/语义切） | 片段摘要 + ASR 转写文本 + 时序特征 | 定位时间区间，主力检索层 |
| 关键帧级 | 片段内 1--3 帧 | 视觉向量（CLIP 类） | 只在问题涉及具体画面时触发，做最终确认 |
检索时不必三层全部搜索。现在视频层召回Top-k。再做片段级精排。只有当query明显指向具体画面，才触发关键帧验证。
统一多模态还是分离多路索引
| 统一多模态 embedding | 分离多路索引 | |
|---|---|---|
| 代表 | Qwen3-VL-Embedding（2B/8B，2048/4096 维，支持图文视频，MMEB-v2 上 8B 得 77.8）、Gemini Embedding 2（文本/图像/视频/音频/PDF 统一空间，3072 维默认、MRL 可截断到 768，视频≤120s、音频≤80s、图≤6 张、PDF≤6 页）、EmbeddingGemma 2（7.4 亿参数、Apache 2.0、全模态量化后约 567MB 内存，可端侧离线） | 文本走 BGE/BM25，图片走 CLIP/Chinese-CLIP，音频走 ASR→文本 |
| 优点 | 一个模型、一个索引、一条查询，跨模态搜索天然成立，不用自己写融合层，还能一次传入图文组合拿联合语义 | 各模态用各自最强的模型；文本检索能力不打折；可独立升级某一路；成本低、可控、可私有化 |
| 缺点 | 纯文本检索能力略逊于同规模专用文本模型（评测报告普遍提到这点）；维度大、推理贵；换模型要重算全库 | 要自己处理融合（RRF/加权）、要保证多路 document_id 对齐、工程复杂度高 |
| 建议 | 语料规模中等、团队不想维护多条管线、或需要端侧/离线隐私场景 | 大多数企业知识库的默认选择 |