2025年4月23日·1 分钟
向量数据库如何驱动 AI 应用的语义搜索
了解向量数据库如何存储嵌入向量、进行快速相似度搜索，并支持语义搜索、RAG 聊天机器人、推荐系统及其他 AI 应用。
了解向量数据库如何存储嵌入向量、进行快速相似度搜索，并支持语义搜索、RAG 聊天机器人、推荐系统及其他 AI 应用。
语义搜索是一种侧重于你“想表达的意思”而不仅仅是你输入的确切词句的搜索方式。
如果你曾经搜索某件事并想，“答案明明在这里——为什么找不到？”，你就体会到关键词搜索的局限。传统搜索匹配词项。当查询的措辞与内容的措辞重合时，这种方法有效。
关键词搜索在以下情况表现不佳：
它也可能过度看重重复出现的词，返回表面上看相关但并未真正回答问题的结果。
想象一个帮助中心有篇文章标题为 “Pause or cancel your subscription”。用户搜索：
“stop my payments next month”
如果该文章没有出现“stop”或“payments”这些词，关键词系统可能不会把它排在前面。语义搜索的设计目标是理解 “stop my payments” 与 “cancel subscription” 含义相近，并把那篇文章排在靠前的位置——因为含义一致。
为实现上述功能，系统将内容和查询表示为“含义指纹”（用数字表示的相似性）。接着需要在数百万个这样的指纹中快速搜索。
这正是向量数据库的用途：存储这些数值表示，并高效检索最相似的匹配，使语义搜索在大规模下也能即时响应。
嵌入是一种表示含义的数字向量。与用关键词描述文档不同，你用一串数字（“向量”）来表示它的主题或含义。含义相近的两个内容会在这个高维空间中彼此靠近。
可以把嵌入想象成高维地图上的坐标。你通常不会直接阅读这些数字——它们并不适合人类理解。它们的价值在于行为：如果“cancel my subscription”和“how do I stop my plan?” 产生的向量彼此靠近，系统就能把它们视为相关，即使它们几乎不共享任何词语。
嵌入不限于文本。
这就是为什么单个向量数据库可以支持“用图片搜索”、“寻找相似歌曲”或“推荐类似产品”。
向量不是人工标注出来的。它们由训练好的机器学习模型生成。你把内容发送到一个嵌入模型（自己托管或使用服务提供商），模型返回一个向量。你的应用将该向量与原始内容和元数据一起存储。
所选嵌入模型会显著影响结果。更大或更专门化的模型通常提升相关性，但成本更高（也可能更慢）。小模型更便宜、更快，但在处理领域特定语言、多语言场景或短查询时可能丢失细微差别。许多团队在扩展前会测试多个模型以找到合适的权衡。
向量数据库的核心思想很简单：把“含义”（向量）与用于识别、过滤和展示结果的信息一起存储。
大多数记录如下：
doc_18492 或 UUID）例如，一篇帮助中心文章可能存储：
kb_123{ "title": "Reset your password", "url": "/help/reset-password", "tags": ["account", "security"] }向量驱动语义相似度。ID 和元数据则让结果可用。
元数据承担两项工作：
没有良好元数据，你可能检索到正确的含义，但仍显示错误的上下文。
嵌入大小取决于模型：384, 768, 1024, 1536 维常见。更多维度能捕捉更丰富的细节，但也会增加：
一个粗略直观理解是：维度翻倍通常会推高成本和延迟，除非你通过索引选择或压缩来抵消。
真实数据集会变化，因此向量数据库通常支持：
及早规划更新流程可以避免“知识过时”问题，即搜索返回的不再匹配展示内容的结果。
把文本、图像或产品转成嵌入之后，搜索变成了一个几何问题：“哪些向量离这个查询向量最近？”这被称为最近邻搜索。系统通过比较两个向量的距离来衡量含义的相似度，而不是匹配关键词。
把每个内容想象成高维空间中的一个点。当用户搜索时，他们的查询被转换为另一个点。相似度搜索返回与该点最近的项——即“最近邻”。这些邻居很可能在意图、主题或上下文上相似，即使它们没有共享精确词语。
向量数据库通常支持几种标准的“接近度”评分方法：
不同的嵌入模型以特定度量进行训练，因此使用模型提供者推荐的度量很重要。
精确搜索会检查每个向量以找到真正的最近邻。准确但在扩展到数百万项时会变慢且成本高昂。
大多数系统使用**近似最近邻（ANN）**搜索。ANN 使用智能索引结构把搜索范围缩小到最有希望的候选集，你通常能得到“足够接近”的结果——速度大幅提升。
ANN 受欢迎是因为它允许你按需调节：
这种调优能力是向量搜索在实际应用中表现良好的原因：在保持响应迅速的同时还能返回高度相关的结果。
把语义搜索看作一个简单的流水线更容易理解：把文本转为含义、查找相似含义、然后呈现最有用的匹配项。
用户输入问题（例如：“How do I cancel my plan without losing data?”）。系统把该文本送入嵌入模型，生成一个向量——它代表查询的含义而不是准确词句。
将查询向量发送到向量数据库，执行相似度搜索以找出存储内容中“最接近”的向量。
大多数系统会返回 top-K 匹配：最相似的 K 个片段/文档。
相似度搜索针对速度优化，因此初始的 top-K 可能包含近似错误项。**二次排序器（reranker）**是一个二次模型，把查询和每个候选结果一起评估并按相关性重新排序。
可以把它理解为：向量搜索给你一份强相关候选清单；二次排序挑出最佳顺序。
最后，你将最佳匹配返回给用户作为搜索结果，或把它们传给 AI 助手（例如 RAG 系统）作为“支撑”上下文。
如果要把这类工作流集成到应用中，像 Koder.ai 这样的平台可以帮助快速原型：你在聊天界面描述语义搜索或 RAG 体验，然后在 React 前端和 Go/PostgreSQL 后端上迭代，同时把检索流水线（嵌入 → 向量搜索 → 可选二次排序 → 回答）作为产品的一级部分。
如果帮助中心文章写的是 “terminate subscription”，而用户搜索 “cancel my plan”，关键词搜索可能会错过它因为“cancel”和“terminate”不匹配。
语义搜索通常会检索到它，因为嵌入捕捉到两者表达了相同的意图。加上二次排序，顶端结果通常不仅仅是“相似”，而是直接对用户问题可操作的答案。
纯向量搜索擅长捕捉“含义”，但用户有时需要精确匹配：人的全名、SKU、发票 ID 或日志中的错误码。混合搜索通过将语义信号（向量）与词法信号（传统关键词搜索如 BM25）结合来解决这个问题。
混合查询通常并行运行两条检索路径：
系统然后把这些候选结果合并成一个排序列表。
当你的数据包含“必须匹配”的字符串时，混合搜索效果最佳：
单纯语义搜索可能返回广泛相关的页面；单纯关键词搜索可能错过措辞不同的相关答案。混合则覆盖了这两种失败场景。
元数据过滤可以在排名之前（或同时）限制检索，提升相关性和速度。常见过滤器包括：
多数系统采用实用的混合方法：并行运行两种搜索，归一化分数使其可比较，然后应用权重（例如“对 ID 更偏重关键词”）。有些产品还会用轻量级模型或规则对合并后的候选清单做二次排序，过滤器确保你在正确的子集上进行排名。
检索增强生成（RAG）是一种让 LLM 更可靠的实用模式：先检索相关信息，再基于检索到的上下文生成回答。
与其要求模型“记住”你的公司文档，不如把这些文档（以嵌入形式）存入向量数据库，在提问时检索最相关的片段，并把它们作为上下文传给 LLM。
LLM 擅长生成文本，但在缺乏事实时会自信地“填空”。向量数据库便于检索知识库中最接近含义的段落并把它们提供给提示。
这种基于证据的方式把模型的行为从“自创答案”转变为“总结并解释这些来源”。它也让答案更容易审计，因为你可以记录检索到的片段并选择性地展示引用来源。
RAG 的质量往往更取决于分块策略而非模型本身。
把流程想成：
用户问题 → 嵌入问题 → 向量数据库检索 top-k 片段（+ 可选元数据过滤）→ 用检索到的片段构建提示 → LLM 生成答案 → 返回答案（和来源）。
向量数据库在中间充当“快速记忆”，为每次请求提供最相关的证据。
向量数据库不仅让搜索“更聪明”——它们启用用户用自然语言描述需求却仍能获得相关结果的产品体验。下面是一些反复出现的实用用例。
支持团队通常有知识库、历史工单、聊天记录和发行说明——关键词搜索在处理同义词、意译和模糊问题描述时表现不佳。
借助语义搜索，客服或聊天机器人可以检索到表达相同含义但措辞不同的历史工单，加速问题解决、减少重复劳动并帮助新手更快上手。把向量搜索与元数据过滤（产品线、语言、问题类型、日期范围）结合能保持结果聚焦。
购物者很少知道精确产品名。他们会搜索像“能放笔记本且看起来专业的小背包”这样的意图。嵌入能捕捉风格、功能和约束，使结果更像由人工助理提供的推荐。
这种方法适用于零售目录、旅行列表、房产、职位板和市场平台。你还可以把语义相关性与结构化约束（价格、尺寸、库存或位置）混合使用。
向量数据库的经典功能是“找和这个相似的项”。当用户查看某件商品、阅读文章或观看视频时，你可以检索语义或属性相似的其他内容——即便类别不完全匹配。
适用场景包括：
公司内部信息分散在文档、Wiki、PDF 和会议记录中。语义搜索帮助员工用自然语言提问（“我们的会议报销政策是什么？”）并找到正确来源。
不可妥协的一点是访问控制。结果必须遵守权限——通常通过在检索时基于团队、文档所有者、机密级别或 ACL 列表进行过滤来实现——确保用户只检索到他们有权查看的内容。
如果你想进一步利用这一点，相同的检索层也可以驱动有依据的问答系统（RAG 部分已覆盖）。
语义搜索系统的质量取决于供给它的流水线。如果文档到达不一致、分块糟糕或编辑后不重建嵌入，搜索结果会偏离用户期望。
大多数团队遵循可重复的顺序：
“分块”步骤是许多流水线成败的关键。过大的分块稀释含义；过小的分块丢失上下文。一个实用做法是按自然结构（标题、段落、问答对）分块，并保留小的重叠以保持连贯性。
内容不断变化——政策更新、价格变动、文章被重写。应把嵌入视为派生数据，需要重新生成。
常见策略：
若服务多种语言，你可以使用多语言嵌入模型（更简单）或按语言选用模型（有时质量更高）。若进行模型试验，请为嵌入版本化（例如 embedding_model=v3），以便做 A/B 测试并能回滚而不破坏搜索。
关键词搜索匹配精确的词元。语义搜索通过比较嵌入（向量）来匹配含义，因此即使查询用不同措辞也能返回相关结果（例如 “停止付款” → “取消订阅”）。
向量数据库存储嵌入向量（数字数组）以及 ID 和元数据，然后进行快速的最近邻查找，以找到与查询含义最接近的项。它针对大规模相似度搜索（通常是数百万条向量）进行了优化。
嵌入是一种由模型生成的数字“指纹”，代表内容的含义。你不直接解读这些数字；而是用它们来衡量相似度。
实际流程：
大多数记录包括：
元数据支持两个关键功能：
没有良好元数据，你可能检索到正确的“含义”，但仍显示错误的上下文或泄露受限内容。
常见选项有：
应使用嵌入模型建议的度量；使用“错误”的度量会明显降低排序质量。
精确搜索会把查询与每个向量比较，随着规模增长会变慢且昂贵。ANN（近似最近邻）使用索引结构在一个更小的候选集中搜索。
你可以在：
之间进行权衡和调优。
混合搜索结合了：
当你的语料包含“必须匹配”的字符串时（例如订单号、错误代码、带修饰的产品名），混合搜索通常是更好的默认选择。
RAG（检索增强生成）在 LLM 应用中常见的模式：先检索相关信息，再生成与这些检索到的上下文绑定的回答。
典型流程：
三个高影响的陷阱：
缓解措施包括按结构分块、为嵌入版本化以及在检索时强制服务器端元数据过滤（例如 tenant_id、ACL 字段）。
title, url, tags, language, created_at, tenant_id）向量驱动语义相似度；元数据使结果可用（用于过滤、访问控制和展示）。