知识库(智能客服方向)核心知识清单
| 概念 | 英文 | 一句话解释 |
|---|---|---|
| 知识库 | Knowledge Base | 结构化或非结构化存储的领域知识集合,供系统检索和使用 |
| 向量 | Vector / Embedding | 文本被转成的一串浮点数(如 [0.12, -0.34, 0.56, ...]),代表语义信息 |
| 向量化 | Embedding / Vectorization | 把文本转成向量的过程,由向量模型完成 |
| 向量模型 | Embedding Model | 专门将文本转为向量的模型(如 BAAI/bge-m3) |
| 向量数据库 | Vector Database | 存储向量并支持相似度搜索的数据库(如 ChromaDB、Milvus、pgvector) |
| 向量检索 | Vector Search / Similarity Search | 在向量库里找与查询向量最相似的K个向量 |
| 相似度 | Similarity | 两个向量之间的距离或余弦夹角,值越大表示语义越相关 |
| RAG | Retrieval-Augmented Generation | 检索增强生成 = 先检索知识库,再让LLM基于检索结果生成答案 |
| 文本分块 | Chunking / Splitting | 把长文档切成若干小段,便于向量化和检索 |
| 重排序 | Rerank | 对向量检索结果再次排序,提升相关性(可选优化环节) |
| 幻觉 | Hallucination | LLM生成了知识库里没有的内容,RAG的核心目标之一就是减少幻觉 |
| 混合检索 | Hybrid Search | 向量检索 + 关键词检索(BM25/TF-IDF)结合,提升召回率 |
| 提示词工程 | Prompt Engineering | 设计输入给LLM的指令,约束其基于知识库回答 |
┌─────────────────────────────────────────────────────────────────┐
│ 接入层(Interface Layer) │
│ 对外API(RESTful / gRPC) │ 后台管理Web(上传/管理文件) │
├─────────────────────────────────────────────────────────────────┤
│ 应用层(Application Layer) │
│ 智能问答 │ 文档检索 │ 多轮对话 │ 权限管理 │ 审计日志 │
├─────────────────────────────────────────────────────────────────┤
│ RAG核心层(RAG Core) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ 文档解析 │→│ 文本分块 │→│ 向量化 + 入库 │ │
│ │ PDF/Word/TXT │ │ 固定长度/语义│ │ Embedding→Vector DB │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
│ ↑ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ 用户Query │→│ Query向量化 │→│ 向量检索 + Rerank │ │
│ │ 问题输入 │ │ Embedding │ │ 召回Top-K文档片段 │ │
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 上下文组装 + LLM生成答案(Prompt + 检索结果 → LLM) │ │
│ └─────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 数据层(Data Layer) │
│ 向量数据库(ChromaDB/Milvus) │ 对象存储(原始文件) │
│ 关系数据库(用户/权限/元数据) │ 缓存(Redis) │
├─────────────────────────────────────────────────────────────────┤
│ 模型层(Model Layer) │
│ Embedding Model(向量模型) │ LLM(大语言模型) │
└─────────────────────────────────────────────────────────────────┘
用户上传文档(PDF/Word/TXT)
│
▼
① 文档解析
提取纯文本内容(Apache Tika / PyPDF2 / python-docx)
│
▼
② 文本分块(Chunking)
按固定长度(500字符)或语义边界切分,保留重叠(50字符)
│
▼
③ 向量化(Embedding)
调用Embedding Model,将每个文本块转为向量
│
▼
④ 存入向量数据库
存储:(向量,原文,元数据-来源文件名/块序号/文档ID)
用户提问:"产品怎么退款?"
│
▼
⑤ Query向量化
用【同一个Embedding Model】将问题转为向量
│
▼
⑥ 向量检索(相似度搜索)
在向量数据库中搜索Top-K(如K=3)最相似的文档块
│
▼
⑦ (可选)Rerank重排序
用重排序模型对结果精排,提升相关性
│
▼
⑧ 组装Prompt
"根据以下资料回答问题:\n{检索结果}\n\n问题:{用户问题}"
│
▼
⑨ LLM生成答案
调用LLM,返回自然语言答案 + 引用来源
│
▼
⑩ 返回用户
{"answer": "根据退款政策...", "sources": ["退款说明.pdf"]}
| 语言 | 推荐框架 | 适用场景 |
|---|---|---|
| Python | FastAPI + LangChain / LlamaIndex | 快速原型、生态最丰富 |
| Java | Spring Boot 3 + Spring AI / LangChain4j | 企业级、与现有Java系统集成 |
| Node.js | NestJS + LangChain.js | 全栈JavaScript团队 |
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| ChromaDB | 纯Python,本地文件存储,无需部署 | 开发测试、轻量级 |
| Milvus / Zilliz | 分布式、高性能、云原生 | 生产环境、大规模 |
| pgvector | PostgreSQL扩展,与关系数据同库 | 已有PostgreSQL、想统一存储 |
| Elasticsearch | 支持向量+关键词混合检索 | 已有ES、需要全文搜索+向量 |
| 模型 | 维度 | 特点 |
|---|---|---|
| BAAI/bge-m3 | 1024 | 中英文效果好,开源免费,硅基流动可调用 |
| text-embedding-v4(阿里) | 1024 | 阿里云百炼,中文优化 |
| embedding-2(智谱) | 1536 | 智谱平台,中文优化 |
| text-embedding-ada-002(OpenAI) | 1536 | 英文效果好,国内访问需网络配置 |
| 模型 | 特点 | 适用场景 |
|---|---|---|
| DeepSeek-V3 / R1 | 性价比极高,中文好 | 通用问答,推荐首选 |
| Qwen2.5-7B/14B(通义千问) | 阿里出品,中文开源最强梯队 | 通用问答 |
| GLM-4-Flash(智谱) | 速度快,免费额度多 | 实时对话、低成本 |
| GPT-4o / GPT-4o-mini | 综合能力最强 | 效果优先,成本不敏感 |
| 平台 | 免费额度 | 特点 |
|---|---|---|
| 硅基流动(SiliconFlow) | 1000万Tokens | BGE-M3免费,兼容OpenAI接口 |
| 智谱AI(Zhipu) | 2000万Tokens | GLM系列,兼容OpenAI接口 |
| 阿里云百炼 | 100万Token/模型 | 通义系列,企业级稳定 |
核心原则:一旦选定了Embedding模型(如
bge-m3),不要中途更换,否则向量库需重建。
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 固定长度 | 按字符数切(如500),带重叠(50) | 通用,实现简单 |
| 语义分块 | 按段落/句子边界切,保持语义完整 | 文档结构清晰时 |
| 父子分块 | 父块(大段)+ 子块(小段),检索子块,返回父块 | 需要上下文完整时 |
经验值:chunk_size=500
800,overlap=50100,效果最稳。
| K值 | 效果 |
|---|---|
| K=1 | 答案简洁,但可能信息不全 |
| K=3~5 | 推荐,召回与噪音平衡 |
| K≥10 | 信息冗余多,LLM可能被干扰 |
- 设置阈值(如0.7),低于阈值的结果不送LLM,直接返回"知识库中暂无相关信息"
- 避免LLM对不相关内容强行编造答案
- 纯向量检索:语义理解好,但对专有名词(如产品型号)可能不敏感
- 加关键词检索(BM25) :提升精确匹配能力,适合FAQ类场景
- 混合检索(Hybrid Search) = 向量 + BM25,用RRF(倒数排名融合)合并结果,效果更优
RAG = 检索增强生成,在LLM生成答案前,先从外部知识库检索相关文档,作为上下文输入给LLM。微调是调整模型参数来适应新领域。区别:RAG适合知识频繁更新、需要引用的场景;微调适合固定风格/格式的任务。RAG成本低、实时性好;微调成本高、周期长。
向量数据库专为高维向量相似度搜索优化,支持十亿级向量的近似最近邻(ANN)检索,毫秒级响应。传统关系数据库(MySQL等)不擅长高维向量索引,全量比对计算量巨大(O(n²)),无法支撑实时检索。
考虑:语义效果(中英文能力)、向量维度(越高越精确但存储/计算成本高)、成本(开源免费 vs 商业API)、部署方式(本地 vs 云API)。不能换的原因:不同模型将同一文本映射到不同向量空间,向量分布不一致。换模型后,新旧向量无法在同一空间内计算相似度,需重建整个向量库。
检索层面:Recall@K(Top-K召回率)、MRR(平均倒数排名)、NDCG。生成层面:答案准确性、引用正确性、幻觉率、用户满意度。端到端:人工评估 + A/B测试 + 用户反馈闭环。
- 优化Prompt,强制要求"只根据资料回答,不知道就说不知道"
- 调高相似度阈值,过滤低相关结果
- 在Prompt中要求LLM标注引用来源
- 用更精准的检索(混合检索+Rerank)提高召回质量
- 对LLM输出做事实性校验(如与原始资料比对)
维护对话历史,每轮将历史对话摘要 + 当前问题一起做检索,确保上下文连贯。同时用Session ID隔离不同用户的会话状态,用Memory机制存储历史信息。
- 向量数据库用ANN索引(如HNSW、IVF)而非暴力搜索
- 采用分库分表或分区策略(按时间/业务线)
- 使用GPU加速向量检索
- 加一层缓存(热门Query → 答案)
- 对文档做预过滤(先按业务标签筛选,再向量检索)
异步处理:上传后返回
doc_id,客户端轮询/documents/{doc_id}/status接口,状态变化为:pending→parsing→chunking→embedding→completed/failed。支持WebSocket推送进度更佳。
用Apache Tika或Unstructured.io通用解析器,提取纯文本。复杂格式(表格/图片):用OCR + 表格结构识别,或转为Markdown保留结构。企业级方案可接入Doc2X等商业解析服务。
增量更新:删除旧文档的所有分块(按
doc_id批量删除),再添加新文档的分块。版本管理:记录文档版本号,查询时只返回最新版本。一致性要求不高的场景,可接受短时(秒级)不一致。
| 组件 | 选型 | 理由 |
|---|---|---|
| 编程语言 | Python | 代码量最小,生态最全 |
| Web框架 | FastAPI | 轻量、异步、自动生成API文档 |
| 向量数据库 | ChromaDB | 纯Python本地存储,零部署 |
| Embedding模型 | BAAI/bge-m3(硅基流动) | 免费、中文效果好 |
| LLM | DeepSeek-V3(硅基流动) | 性价比高、响应快 |
| 文档解析 | PyPDF2 + python-docx | 轻量、无需额外依赖 |
| 部署 | python main.py |
单文件启动,无需容器 |
| 中文 | 英文缩写/术语 |
|---|---|
| 检索增强生成 | RAG |
| 向量 | Vector / Embedding |
| 向量化 | Embedding |
| 向量数据库 | Vector DB |
| 向量检索 | Vector Search |
| 相似度 | Similarity / Cosine Similarity |
| 分块 | Chunking |
| 重排序 | Rerank |
| 幻觉 | Hallucination |
| 混合检索 | Hybrid Search |
| 提示词 | Prompt |
| 检索结果排名 | Recall / MRR / NDCG |
| 近似最近邻 | ANN (Approximate Nearest Neighbor) |