0. 你为什么需要向量数据库？
传统关键词/全文检索（TF-IDF、BM25）解决的是“字面匹配”，而用户提问往往是“语义变体”（同义改写、口语化、错别字、跨领域表达）。向量数据库把文本映射到高维语义空间，通过 ANN（近似最近邻）在毫秒级完成“语义相似”检索，是现代智能客服（FAQ、文档问答、知识助手）的基础设施。
一句话：Embedding × 向量索引 = 可检性 × 速度。Embedding 决定“能搜到什么”，索引决定“多快搜到”。
1. 体系架构（一眼看懂）
用户 → 预处理(清洗/纠错/敏感词) → 向量化(Embedding)
→ [A] 向量检索(ANN)
→ [B] 关键词/BM25 补充检索 (可选)
→ 候选合并去重 → 重排序(Rerank) → 置信度判定
→ 高置信：直答/引用 中置信：追问澄清 低置信：转人工/兜底
→ 反馈闭环(用户评价/人工标注/日志回流)
三条主线：
- 召回
- 排序：小模型重排或 LLM 重排，提升前 1–3 条的相关性；
- 决策：基于阈值与策略（直答/追问/转人工），并统一做安全与越权拦截。
2. 数据建模（通用表设计）
选任一支持向量类型的数据库即可（如 PostgreSQL+pgvector、OceanBase 向量列、Milvus+MySQL 等）。以下用“向量列 + BM25”做示例。
知识主表（FAQ/文档切片）
-- 以 PostgreSQL 为例，pgvector: vector(768)
CREATETABLE faq_chunk (
id UUID PRIMARY KEY,
project_id BIGINTNOTNULL, -- 多租户/多业务隔离的强过滤维度
title TEXT, -- 主题或问题标题
content TEXT NOTNULL, -- 片段内容（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 的三种结合方式
- 检索式问答（Retrieve-Then-Read）：把被引片段拼 Context 喂给 LLM 生成答案（RAG）。
- 模板直答
- 工具调度：LLM 先判断是否要调用“知识检索”“工单查询”“权限校验”等工具，再组装答案。底线：强制引用来源与答案可追溯，降低幻觉风险。
5. 评估指标（离线 + 在线）
离线：Recall@K、MRR/NDCG、相似度分布漂移（监控语料和模型版本变更）。在线：首答命中率（FCR）、无答案率、转人工率、CSAT、延迟 P50/P95/P99、平均 token 成本。目标值参考：
- 无答案率 ≤ 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（两周可上线的最小方案）
建模：建三张表：faq_chunk（向量+全文）、conversation_log（会话日志）、feedback（评价/纠错）。
入库：离线切片 → 计算 embedding → 批量写入（保持 project_id 过滤可用）。
服务：
/embed/search：向量 TopK + BM25 TopK → RRF → 重排 → 置信度判定；/answer
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。
粤ICP备14082021号
免费POC，
零成本试错
