智能客服听不懂人话？这其实是个老问题了。

用户说“我这个月话费怎么多了”，系统可能只能匹配到“话费查询”这几个字，但用户真正想问的是“为什么费用异常”。这就是传统关键词检索的硬伤——字面能对上，语义对不上。

于是，向量数据库登场了。它把文本映射到高维语义空间，通过近似最近邻（ANN）搜索，实现毫秒级语义匹配，成了新一代智能客服基础设施的核心。

0. 怎么判断自己需不需要向量数据库？

传统的关键词或全文检索（比如 TF-IDF、BM25），本质上是解决“字面匹配”的问题。但用户的提问往往是各种“语义变体”——同义改写、口语化表达、错别字、跨领域的隐晦说法。遇到这种情况，传统检索基本就歇菜了。

向量数据库干的事，是把文本映射到高维语义空间，然后通过近似最近邻（ANN）在毫秒级完成“语义相似”检索。可以说，它已经是现在智能客服（FAQ、文档问答、知识助手）的基础设施。

一句话总结：Embedding × 向量索引 = 可检性 × 速度。Embedding 决定了“能搜到什么”，索引决定了“多快搜到”。

1. 体系架构（一眼看懂）

用户 → 预处理(清洗/纠错/敏感词) → 向量化(Embedding)
     → [A] 向量检索(ANN)
     → [B] 关键词/BM25 补充检索              (可选)
     → 候选合并去重 → 重排序(Rerank) → 置信度判定
     → 高置信：直答/引用   中置信：追问澄清   低置信：转人工/兜底
     → 反馈闭环(用户评价/人工标注/日志回流)

整个架构可以拆成三条主线：

• 召回（A+B）：以向量为主，BM25 作为补充检索；
• 排序：通过小模型重排或 LLM 重排，把前 1–3 条结果的相关性提上去；
• 决策：基于阈值和策略决定是直接回答、追问澄清还是转人工，同时要做安全和越权拦截。

2. 数据建模（通用表设计）

选一个支持向量类型的数据库就行，比如 PostgreSQL+pgvector、OceanBase 向量列、或 Milvus+MySQL。下面以“向量列 + BM25”为例。

知识主表（FAQ/文档切片）

-- 以 PostgreSQL 为例，pgvector: vector(768)
CREATE TABLE faq_chunk (
  id           UUID PRIMARY KEY,
  project_id   BIGINT NOT NULL,     -- 多租户/多业务隔离的强过滤维度
  title        TEXT,                -- 主题或问题标题
  content      TEXT NOT NULL,       -- 片段内容（200~500 中文字符为宜）
  source       TEXT,                -- 来源文档/URL/系统
  chunk_id     TEXT,                -- 文档内片段编号
  updated_at   TIMESTAMPTZ DEFAULT now(),
  embedding    vector(768)          -- 统一维度与归一化策略
);
-- 全文检索（BM25）索引
CREATE INDEX idx_faq_chunk_fts ON faq_chunk USING gin (to_tsvector('simple', content));
-- 项目过滤索引
CREATE INDEX idx_faq_project ON faq_chunk (project_id);
-- 向量索引（IVFFlat/HNSW 二选一）
CREATE INDEX idx_faq_vec ON faq_chunk USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

为什么需要 project_id？ 99% 的性能问题都源于“没做前置过滤”。先按项目过滤，再做向量检索，延迟可以从百毫秒级降到几十毫秒。

Chunking 规则：200–500 字一片，段尾保留“标题→正文→小结”的层级上下文，召回质量会更稳。去重相似度阈值建议设为 0.98。

3. 检索与融合（核心环节）

1）向量 TopK（主召回）

SELECT id, title, content,
       1 - (embedding <=> :q_vec) AS sim   -- cosine 相似度（0~1 越大越像）
FROM faq_chunk
WHERE project_id = :pid
ORDER BY embedding <-> :q_vec              -- 以向量距离排序
LIMIT 50;

这里有一点要注意：统一“相似度”的语义。别前面用 distance，后面又 1-distance。统一使用 sim ∈ [0,1]，阈值会更直观。

2）BM25 补充（召回兜底）

SELECT id, title, content
FROM faq_chunk
WHERE project_id = :pid
  AND to_tsvector('simple', content) @@ plainto_tsquery(:q_text)
LIMIT 50;

3）结果融合：RRF（强烈推荐） 把两路 TopK 用 Reciprocal Rank Fusion 融合后再交给重排，既鲁棒又容易实现。

4）重排（Rerank）

• 低成本方案：用轻量级的 Cross-Encoder（比如中英双语的小模型），在 50 条里选出 Top10；
• 高成本方案：用 LLM 重排（但要注意延迟和花费，先比价再上）。阈值参考：sim_top1 >= 0.92 直接命中；0.85~0.92 触发追问澄清；低于 0.85 转人工或兜底。

4. 与 LLM 的三种结合方式

1. 检索式问答（Retrieve-Then-Read）：把被引片段拼成 Context 喂给 LLM 生成答案（即经典的 RAG）。
2. 模板直答：对于 FAQ 类的固定问法，直接绕开 LLM，延迟最稳。
3. 工具调度：LLM 先判断是否需要调用“知识检索”“工单查询”“权限校验”等工具，再组装答案。底线：强制引用来源，做到答案可追溯，降低幻觉风险。

5. 评估指标（离线 + 在线）

离线：Recall@K、MRR/NDCG、相似度分布漂移（监控语料和模型版本变更）。在线：首答命中率（FCR）、无答案率、转人工率、CSAT、延迟 P50/P95/P99、平均 token 成本。目标值参考：

• FCR ≥ 65%（初期），逐月 +5% 迭代；
• P95 延迟 ≤ 150 ms（不含 LLM）；
• 无答案率 ≤ 8%，且“追问转命中率”≥ 30%。

6. 性能与成本

• 索引参数：

  • HNSW：M 决定图连边（影响召回率和内存），efSearch 决定搜索深度（影响延迟和召回率）。
  • IVF：lists（nlist）与 probes（nprobe）共同决定精度与速度。

• 缓存：对热门问法的向量与 TopK 结果做缓存（LRU/TTL）；

• 分区/分表：按 project_id 或业务线分区；

• 批量更新：离线重建索引 + 原子切换，避免线上性能退化；

• 降级策略：向量检索异常时自动回退到 BM25。

7. 质量工程与数据运营

• 语料治理：去重、合并、规范术语；命名统一（系统/版本/地域），减少歧义；
• Chunk 策略：标题上下文 + 段内小结，保持语义粒度稳定；
• 模型规范：统一 Embedding 模型版本、维度、归一化（常用 L2）；
• 标注闭环：错答/无答案样本入池 → 每周增量更新 → A/B 验证；
• 安全合规：PII 脱敏、越权检索拦截、涉政涉暴黑名单、越狱提示注入检测。

8. MVP（两周可上线的最小方案）

1. 建模：建三张表：faq_chunk（向量+全文）、conversation_log（会话日志）、feedback（评价/纠错）。

2. 入库：离线切片 → 计算 embedding → 批量写入（确保 project_id 过滤可用）。

3. 服务：

   • /embed：文本 → 向量；
   • /search：向量 TopK + BM25 TopK → RRF → 重排 → 置信度判定；
   • /answer：RAG 生成（带引用）。

4. 监控：记录 sim_top1、sim_gap、K、延迟、是否直答/追问/转人工、CSAT。

5. 迭代：每天回灌错误样本，周更索引参数（M、efSearch / lists、probes）。

9. 常见坑（避坑清单）

• 混用距离与相似度，导致阈值混乱 → 统一返回 sim ∈ [0,1]；
• 未做项目/租户过滤，导致全库 ANN，P95 暴涨；
• Chunk 过长或过短 → 召回泛化差，建议 200–500 字并带标题上下文；
• 只上向量、不配 BM25 → 数字、实体名、稀有词召回差；
• 索引在线重建 → QPS 抖动，改为离线重建 + 原子切换；
• 无“引用+来源” → 幻觉无法审计，合规风险；
• 把 LLM 当锤子 → FAQ 场景先模板直答，成本和延迟更优。

10. 代码片段（可直接参考）

服务端伪代码（Python 风格）

def answer(query_text, project_id):
    q_vec = embed(query_text)  # 统一 embedding 版本 & 归一化
    v_hits = vec_search(project_id, q_vec, topk=50)      # 向量主召回
    l_hits = bm25_search(project_id, query_text, k=50)   # 关键词补充
    merged = rrf_merge(v_hits, l_hits)[:100]             # RRF 融合
    ranked = rerank(query_text, merged)[:10]             # 重排
    sim = ranked[0].sim
    if sim >= 0.92:
        return format_direct_answer(ranked[0])           # 带引用
    elif sim >= 0.85:
        return ask_clarifying_question(ranked)           # 引导补充信息
    else:
        return fallback_to_human_or_knowledge_graph()

11. 路线图（v2 升级）

• 个性化/会话上下文向量：引入“用户画像向量 + 历史对话向量”，实现多轮与人群差异化命中；
• 结构化工具整合：把“下单查询、工单状态、权限校验”等作为工具纳入 LLM 调度；
• 领域自适应微调：将真实问答回流做少量监督微调（Rerank 或 LLM），显著提升长尾问题效果。

结语

智能客服的关键，不是“上一堆大模型”，而是把知识变成“可检”“可排”“可控”。向量数据库解决“可检”，混合检索与重排解决“可排”，引用与策略引擎解决“可控”。只要按本文的建模、检索、评估与运维方法走，两周内就可以上线一个稳、快、可迭代的智能客服 MVP。