用向量数据库拯救你混乱的JSON查询？一个真实的企业级应用场景剖析

作为开发者或架构师，我们都热爱灵活性。在构建系统时，尤其是在处理多变的业务数据时，使用JSON格式存储在string或JSON类型的字段里，似乎是一个既快捷又灵活的“银弹”。然而，当“查询”这个魔鬼找上门时，噩梦便开始了。

我们的困境：灵活的JSON与僵化的查询

在我们的审批流系统中，就面临着这样一个典型的场景：

业务背景：审批流单据需要关联五花八门的外部业务数据。
技术实现：为了快速适应变化，我们将这些业务数据序列化为JSON字符串，存入数据库的某个text字段中。
暴露的问题：当运营或管理人员需要根据业务内容进行查询时，我们束手无策。LIKE '%关键词%'不仅效率低下，而且极不智能。用户搜“笔记本电脑”，就找不到“采购MacBook”的单据。

这时，领导提出了一个听起来很前沿（甚至有点奇怪）的建议：“试试向量数据库？”

这篇文章，就是我们探索这个“奇怪”建议并最终发现其巨大价值的全过程记录。

柳暗花明：为什么向量数据库是答案？

初听这个建议，我的第一反应是：向量数据库不是用来做“以图搜图”和“大语言模型”的吗？用来查我们业务系统的JSON，是不是杀鸡用牛刀了？

要解答这个疑惑，我们必须理解向量数据库与传统数据库的根本区别。

核心思想：从“关键词匹配”到“语义理解”

传统数据库 (如MySQL)：像一个严谨的图书管理员，你必须告诉他书的精确ID (WHERE id = 123)或者书名中包含的精确词汇 (WHERE title LIKE '%哈利%')，他才能帮你找到。他不懂“一个男孩在魔法学校的故事”是什么意思。
向量数据库 (如Milvus, Pinecone)：像一个博学且善解人意的图书管理员。你用自然语言描述“我想找一本关于一个年轻巫师在魔法学校成长的书”，他能理解你描述的“意思”（语义），然后把《哈利·波特》推荐给你。

这个“理解意思”的过程，就是通过Embedding（嵌入）技术实现的。它能将任何非结构化数据（文本、图片，甚至是我们的JSON）转换成一个由数字组成的向量（Vector）。这个向量，就是数据在“语义空间”中的坐标。意思相近的数据，它们的向量坐标也相近。

ChatGPT Image 2025年8月4日 16_31_52 (1)

因此，我们审批流的查询问题，可以从“在JSON字符串中匹配关键词”转变为“在语义空间中寻找意思最相近的审批单”。

实战蓝图：如何用向量数据库改造审批流查询？

这是一个两阶段的实施方案：数据入库和数据查询。

第一步：数据向量化入库 (Ingestion)

当一个审批单被创建或更新时，我们需要将其“喂”给向量数据库。

提炼JSON为自然语言：这是最关键的一步！不要直接将原始JSON字符串进行向量化，效果会很差。我们应该写一个转换函数，将JSON中的关键信息提炼成一段通顺的自然语言描述。

原始JSON数据:
```
{
  "applicant": "张三",
  "department": "市场部",
  "type": "费用报销",
  "items": [
    { "name": "MacBook Pro 14寸", "quantity": 1, "price": 15999 },
    { "name": "扩展坞", "quantity": 1, "price": 500 }
  ],
  "total_amount": 16499,
  "reason": "新员工电脑采购"
}
```
转换为待Embedding的文本:

"市场部的张三提交了一张费用报销单，申请报销16499元，事由为新员工电脑采购，具体项目包括一台MacBook Pro 14寸和扩展坞。"
调用Embedding模型：使用一个Embedding模型（如OpenAI的text-embedding-3-small，或开源的BGE、M3E等中文模型）将上述文本转换为向量。

"市场部的张三..." => [0.012, -0.345, 0.891, ..., -0.553]
存入向量数据库：将生成的向量与该审批单的唯一ID（如approval_id）一同存入向量数据库。
- Vector: [0.012, -0.345, ...]
- Metadata: { "approval_id": "AP-2023-1027-001" }

第二步：实现语义搜索查询 (Querying)

当用户在搜索框输入查询时：

获取并向量化用户查询：假设用户输入“查找小张上个月买电脑的单子”。我们使用同一个Embedding模型将这句话也转换成一个查询向量。
执行相似度搜索：拿着查询向量，去向量数据库中执行相似度搜索（ANNS, Approximate Nearest Neighbor Search），请求返回最相似的Top K个结果。
返回最终结果：向量数据库返回的是它存储的元数据，即approval_id的列表。我们的应用服务拿到这些ID后，再回到**原始业务数据库（MySQL）**中，根据ID查出完整的单据详情，呈现给用户。

这种“向量数据库存索引，业务数据库存全量数据”的架构模式，是当前的主流实践。

进阶玩法：混合搜索（Hybrid Search）—— 两全其美的艺术

向量搜索擅长处理语义模糊，但对于精确条件的过滤（如部门、时间、金额范围）则不是强项。最佳实践是将传统SQL过滤和向量搜索结合起来，实现“混合搜索”。

查询示例：“查找市场部在上个月提交的关于采购电脑的审批单”

执行流程：

元数据预过滤 (Pre-filtering)：先用SQL在业务数据库中筛选出所有满足精确条件的单据。
```
SELECT approval_id FROM approvals 
WHERE department = '市场部' 
  AND create_time >= '2023-09-01' 
  AND create_time < '2023-10-01';
```
这一步可能将搜索范围从百万级缩小到百级。
向量语义搜索 (Semantic Search)：将查询的语义部分“关于采购电脑”向量化，然后在向量数据库中，仅在上一步筛选出的ID范围内进行相似度搜索。

混合搜索兼具了SQL的精确性和向量搜索的智能性，是企业级应用中的黄金标准。

决策指南：我到底该不该用向量数据库？

通过这次实践，我们总结出一个评估框架，来判断一个场景是否适合引入向量数据库。

评估维度	适合向量数据库 ✅	更适合传统数据库 ❌	你的场景符合吗？
数据性质	非结构化、半结构化，富含“描述性”语义（如文章、评论、业务活动JSON）	高度结构化，事务性、指令性数据（如金额、状态、ID）	✅
查询意图	模糊的、开放的、基于自然语言的“找相似”	精确的、基于已知条件的“找相等/找范围”	✅
核心诉求	追求结果的“相关性”排名（Top-K），允许一定模糊	追求结果的100%“正确性”和完整性	✅
当前痛点	`LIKE`等传统方法已无法满足性能和智能化的要求	简单的关键词匹配或字段索引已足够	✅

总结

将审批流中的JSON数据查询问题，重新定义为一个企业级的语义搜索问题，是解决此问题的关键思维转变。

向量数据库并非遥不可及的AI黑科技，它是一种新型的数据库范式，能够有效解决非结构化数据的检索难题。对于我们这种在业务系统中大量使用JSON来保持灵活性的团队来说，它不仅不是一个“奇怪”的方案，反而是一个能精准解决痛点、大幅提升用户体验的现代化利器。

如果你也正被混乱的JSON查询所困扰，不妨也抬头看看，向量数据库可能就是你的“柳暗花明”。