AI知识库
简介
知识库是什么
知识库是用来辅助大模型理解和回答问题的一种结构化或半结构化信息集合。
简单来说，它是让 AI **“更懂你”**的工具，主要做以下几件事：
-
补充大模型的知识盲区
大模型不是实时联网的，它的知识有“截止日期”。知识库可以存放最新的公司文档、产品说明、技术资料等，AI 在回答时可以参考这些内容。 -
做检索增强生成（RAG）
AI 在回答问题前，先从知识库里“查资料”，再用查到的内容来生成回答，提高准确性和可信度。 -
提高上下文相关性
比如企业的 AI 助手可以基于公司自己的知识库，准确回答公司内部的问题，而不是泛泛而谈。 -
作为私有领域知识的载体
可以存储用户自己的笔记、项目经验、会议记录等内容，让 AI 成为“你专属的智能助理”。
知识库是如何工作的
RAG 是一种将大语言模型（LLM）和外部知识结合的方法。其核心思想是：
模型先“查资料”（检索），再“回答问题”（生成）。
整体流程分为两个阶段：
- 检索阶段（Retrieval）
- 用户提出问题后，系统不会直接喂给大模型，而是先去知识库中检索相关内容。
- 知识库通常是一个 向量数据库，里面存的是知识文本经过嵌入（embedding）后的向量。由于向量数据库的稀疏性，知识库通常还包含倒排索引技术，用于做混合检索来提升召回效果。
- 检索方式：将问题做 embedding（同时做分词），找出与其最相似的内容（比如前 N 条）（进行互惠排名）。
- 生成阶段（Generation）
- 把“检索到的内容”+“用户问题”一并输入给大模型。
- 大模型基于这些上下文内容生成更准确、有依据的回答。
知识库包含什么
| 组成 | 内容 | 示例 |
|---|---|---|
| 原始数据 | 文档、网页、PDF、数据库等 | 产品手册、FAQ、公司 Wiki |
| 分片（Chunk） | 将文档分段，便于处理 | 每段 200~500 字 |
| 向量化（Embedding） | 将文本转换为向量，支持语义相似度计算 | 使用模型如 OpenAI、BGE、MiniLM 等 |
| 向量存储 | 存储和检索嵌入向量 | 向量库如 FAISS、Weaviate、Milvus 等 |
| 倒排索引 | 基于关键词匹配的全文搜索能力 | 使用 Elasticsearch 等，适合精确匹配、关键词搜索 |
| 混合检索 | 同时使用倒排索引和向量检索，提升召回效果 | 先用 ES 召回，再用向量排序；或两者融合打分，提升相关性和覆盖率 |
文档解析
chunk拆分
chunk拆分目标：在保证检索效率的同时，最大化地保留语义完整性和上下文连贯性。
可以参考以下准则进行chunk拆分：
- 切分粒度（Size）
- 理想 Token 范围：大多数应用建议每个 chunk 控制在 200–700 token（大约 150–500 字）之间。
- 动态最大值：如果遇到超长段落（如超过 1,000 token），可二次拆分；若遇到天然短条目（如列表项），可适当缩到 100–200 token。
- 语义边界优先（Semantic Boundaries）
- 标题/小节分割：优先按照文档层级结构（H1/H2/H3、目录、条目号）做第一轮粗粒度切分。
- 段落/句子分割：在大块内部，以换行、句号、分号等自然语言标记做安全拆点，避免在一句话中或同一逻辑段里硬切。
- 主题边界检测：对于长文本，可利用 TextTiling、TopicTiling、BERT-based segmentation 等算法自动发现话题转折点。
- 重叠窗口（Overlap / Sliding Window）
- 重叠比例：在相邻 chunk 之间保留 10%–20% token 重叠（例如每 500 token 切一次，重叠 50–100 token）。
- 作用：保证前后 chunk 在接近边界时有足够上下文，提升跨 chunk 检索的连贯性。
- 元数据与标签（Metadata）
- 结构信息：每个 chunk 带上所属文档 ID、章节标题、父节点层级、规则/条目编号等。
- 业务标签：如“合规／风控／示例说明”之类的类型标签，方便在检索时做过滤或聚合。
- 多模态与附件（Multi-modal / Assets）
- 纯文本优先：chunk 的主字段尽量只保留自然语言，用于向量化或倒排索引。
- 资源引用：图片、表格、公式等以 metadata（链接、描述、位置）方式单独存储，不干扰文本检索。
- 重组机制：检索后通过 metadata 或原始 Markdown/HTML 还原完整表现。
- 索引与检索优化
- 多字段（Multi-field）：为同一文本建立“清洁版”（去除占位符／URL）和“原始版”两个索引域，检索用前者，展示用后者。
- 分级检索：先按粗粒度（section/chunk）召回，再在 top-k chunk 内做更细粒度重排序或再分片，兼顾速度与命中。
- 评估与迭代（Evaluation & Tuning）
- 人工打标：设计一批典型问题和预期答案，验证 chunk 分割后检索召回率和回答质量。
- A/B 测试：尝试不同 chunk 大小、重叠比例、分割策略，监测延迟、召回准确度、下游任务效果。
- 自动监控：统计“命中 chunk 长度分布”、“边界召回失败样例”，定期调整策略。
chunk太大的缺点：
- 语义丢失：如果你用的bge-m3模型，它支持的上下文是8192个token，向量维度是1024。chunk大于8192个token的部分语义会丢失。
- 检索性能下降：在 BM25／倒排索引场景下，chunk 越长包含的 term 越多、倒排列表越长，排分（scoring）时就要遍历更多 posting，响应变慢。
- 召回的粒度粗糙，噪声增多
-
- 大 chunk 往往包含多条语义甚至不同主题，召回时由于匹配到 chunk 整体，就很难精准定位用户真正关心的那段内容，回答或生成时需要再做“chunk 内精排”或二次分片，反而更拖延。
-
- 大 chunk 中的无关内容也会干扰模型理解，降低 downstream 任务（问答、摘要）的准确度。
chunk太小的缺点
- 上下文缺失：有些文本的上下文被拆段后，往往是致命的（例如，一个规则的规则明细不能被拆分）。
- 检索性能下降：小chunk导致chunk总量变多，向量相似度计算需要耗费更多时间。
- 存储成本变大：向量的维度是由你的向量模型决定的，chunk太小道中总向量变多，占用空间变大。
图片入库
将多模态文档转换成markdown之后，直接拆分chunk会有以下问题：
- 语义缺失：图片表述的语义没有落库。
- 相似度被稀释：URL 通常很长且包含大量无意义的字符，拉低整体的相似度，影响检索效果。
为了解决这个问题，可以考虑采用以下方案：
- 用单独字段存储关联的图片，原文中用占位符去表示图片。
- 召回时将占位符替换成具体的图片
- 向量化时，用去掉占位符的内容去embedding。
- 存ES时，用单独字段存储原文（不索引），用另外一个字段存储去掉占位符的内容（检索用这个字段）。
- 图片用多模态模型解析后，单独存储chunk。
还有个简化方案：原文不存储图片位置信息，chunk用个单独字段存储关联的图片（会丢失图片位置信息）。