XlongLab 围绕 AI 产品、技术原理与工程实践发布的全部内容。
查看所有作者企业案例最容易出现两种问题：要么变成品牌宣传，要么把内部系统的局部做法包装成通用架构。更有价值的分析方式，是明确区分三层信息：公开资料已经披露的事实、根据事实做出的工程推断、以及可以用公开数据独立验证的设计取舍。
本文基于 Zilliz 在 2025 年发布的滴滴 Grocery 案例，拆解一个商超语义搜索系统。文中的规模、收益和内部实现均来自该公开文章，XlongLab 未接触滴滴内部系统，也未独立验证其业务指标。
Embedding 模型正在快速分化：有的强调中文与多语言，有的面向长文本，有的支持图像、视频或 PDF，还有的允许通过 Matryoshka Representation Learning（MRL）裁剪向量维度。面对几十个模型，最危险的做法是直接抄一张排行榜，然后把第一名接进生产系统。
更可靠的结论只有一句话：先建立评测流程，再选择模型。 模型会更新，业务数据也会变化；一套能反复运行的评测流程，比一次性的“冠军模型”更有长期价值。
多模态检索 Demo 很容易让人产生错觉：输入“红色汽车”，系统返回几张红色汽车图片，看起来就已经成功了。但真正的产品会遇到中文查询、细粒度属性、相似但错误的图片、元数据过滤、增量图片和版权边界。
本文从一个可连接自有授权图片的图文检索基线开始，再演示如何把检索结果交给 OpenAI 兼容的视觉语言模型。重点不是展示成功截图，也不公布未经执行的跑分，而是说明如何准备数据、评价系统、分析失败和逐步走向生产。
几十行代码就能把文档、向量数据库和大模型连成一个 RAG Demo，但企业知识库真正困难的部分不是“跑起来”，而是回答三个问题：为什么召回了这些内容？回答是否真的有依据？系统变更之后，质量到底变好还是变坏？
本文构建一个以 Qwen3 Embedding 和 Milvus Lite 为基础的知识库参考基线。重点不是追求组件数量，而是把数据处理、检索、重排、生成和评估拆开，让每一层都可以独立检查。本文提供的是可连接自有文档与模型服务的实现骨架，不宣称已经给出适用于所有企业数据的质量结果。
“哪个向量数据库最快”是一个容易提问、却很难诚实回答的问题。Milvus、Qdrant 和 Chroma 的产品边界并不完全相同：它们面向的数据规模、部署方式、扩展模型和运维要求都有差异。只比较一组 QPS，往往会把不同定位的产品拉进一场不公平的比赛。
本文不复用某次旧版本跑分，也不宣布一个永久冠军，而是给出一套可以在自己的硬件和数据上重复运行的比较方法。
向量数据库变慢时，最常见的反应是修改索引参数或增加机器。但“慢”只是症状：问题可能来自客户端连接、查询并发、过滤条件、索引、Segment、缓存、磁盘、网络，甚至是召回率目标本身。
有效排障需要一条固定顺序：先保护检索质量，再定位延迟发生在哪一层，最后只改变一个变量验证。