RAG 不只是技术热词，它正在重塑企业知识系统的构建方式。本文以券商客服场景为例，系统拆解从0到1构建 RAG 知识库的全过程：从数据准备、向量化、检索策略到生成逻辑，不仅有技术路径，也有业务思维。
客户打来电话问：“我港股账户昨天除权，今天为什么显示持仓减少了？”
如果是人工客服，往往需要翻公告、查系统、确认结算规则，几分钟才能给出解释。
而在智能客服场景下，如果知识库没构建好，模型可能会一本正经地胡说八道。
有时答非所问，有时干脆甩一句：请联系人工客服……
这正是很多金融机构在大模型落地中遇到的最大瓶颈：模型有能力，却没有“业务知识”。 要让 AI 真正懂业务、答得准，就必须构建一套属于自己的 RAG 知识库。
本文结合券商智能客服的实践案例，带你走完整个知识库的构建流程——从 数据提取、数据清洗与格式化、内容切分、向量化，到数据入库，逐步揭开 RAG 知识库背后的秘密～
在构建领域知识库时，我们需要考虑具体的五个阶段：
这里我们会遇到两大类数据：
特点：数据已经按照表格/字段存储，有固定格式，能直接拿来用
例如：
以券商场景为例：
这些数据就像是已经排列好的“excel 表格”只要对接数据库/接口。就能直接入库。
那非结构化数据是什么呢？
特点：数据是“原材料”，没有统一格式，需要先清洗/切分后才能用
券商场景的非结构化数据长什么样的，这里给大家枚举一些：
这些数据就像一堆“原矿石”，必须通过 OCR、语音转写、文本切分等方式“提炼”成知识片段，才能被检索和调用。
数据清洗及格式化：将不同格式的数据内容提取为纯文本
我们用 PyMuPDF做结构提取，然后执行：
精确去重，使用的哈希（Hash），它可以快速判断文本是否完全一致
对于语义去重，我们是利用语义向量（embedding）+相似度计算的方法
具体做法是把文本转成高维向量，然后计算它们的余弦相似度。
当相似度超过某个阈值（比如0.9或0.95）时，我们就判定这些文本是语义重复，从而进行合并或过滤。
这种方法能有效识别“我想开户”和“怎么开账户”这类表达不同但意思相同的文本，是智能客服和RAG系统中提升知识库质量的关键。
通俗来说：哈希就像是文本的“身份证号码”，严格匹配；而语义向量是文本的“脸部识别”，看整体相似度。
比较相似度的几种方法：
余弦相似度：含义：计算两个向量之间的夹角余弦值
数学公式：cos(θ) = A·B / (‖A‖‖B‖)特点：关注方向，不考虑向量长度
应用场景：稳定性好，语义类首选欧式距离：计算两个向量之间的“空间直线距离”数学公式：√Σ (Ai-Bi)²特点：关注绝对位置差值，受向量长度影响大
应用场景：几何直觉强（图像/物理空间定位类问题常用）点积：向量内积，考虑方向和长度数学公式：A·B = ΣAi*Bi特点：值大代表方向一致且“强”，值小代表方向偏离
应用场景：高效计算，与模型训练兼容性强。
目标：构造最小可复用、可引用的知识单元。
常见做法是 基于规则 +NLP模型：
规则切分按字符数（比如 200–500 字一个 chunk）；
容易踩坑的点：切分过大召回噪声多、过小上下文断裂。
关于不同的格式PDF、图片、图文混合、语音、视频类如何切分，我做一个更详细的介绍，欢迎大家继续阅读～
根据 文档逻辑结构 + 可视排版信息 + 语义完整性 三个维度进行切分。
整个流程可以分为以下几步：
1）文档解析
使用 PyMuPDF 解析文本和排版结构（如字体大小、缩进、标题层级）；
如果是扫描件PDF，则通过 OCR（如 PaddleOCR + 表格检测）还原内容。
2）结构识别
通过正则表达式或标题风格识别“章节标题”、“条款编号”（如 第 X 条、1.2.3）作为一级切分点；
根据空行、缩进、符号判断自然段落边界。
3）分块切分（Chunking）
按照“一级标题 + 段落”组合成一个chunk，保持上下文完整；
每个chunk控制在300-500 tokens，超长内容采用滑窗 + overlap；
若chunk包含表格，则先展开表格结构再切分。
4）元数据补全
为每个chunk添加文档标题、页码、版本、发布日期等元信息，方便后续追溯与响应定位；
切分质量验证
随机抽样chunk进行 Embedding 相似度热图分析，检查语义跳跃或中断问题；
还会做人工 spot-check，确保每个chunk语义通顺、结构清晰。
对于图片类数据，我们通常分为两步：先进行内容识别，再进行语义切分。
1）图片预处理
对图片做去噪、去水印、裁剪等基础图像处理，保证后续识别质量；
对文档类图片使用图像增强技术提高OCR准确率。
2）OCR 文字识别
使用高性能OCR工具识别图片中的文字和表格；
同时提取文字位置、字体大小、布局信息，辅助后续切分。
3）图像分块与切分
根据OCR识别的文字位置，结合图像的空间布局，做逻辑区域划分；
对于图表类图片，我们会先做图表结构识别（图例、坐标轴、图形元素），再拆分成对应的文字描述+结构块。
4）语义级别切分
在文本提取后，按照自然语言的断句和业务逻辑进行语义切分，保证内容的完整性和上下文连续；
对图表、合同页等内容，会做额外的语义补充说明，方便向量召回。
5）元信息补充
每个切块会标记图片来源、页码、截图时间等，便于回溯和查询。
我们确保图片类数据不仅能被“看懂”，而且可以高效地参与到知识检索与智能问答中。
这里主要用到ASR
ASR（自动语音识别） 是将语音信号转化为对应文本的技术，是语音类数据接入自然语言处理系统的第一步。
在券商的智能客服项目中，ASR负责：
为后续语义分析和RAG提供文本基础。
识别文本成为后续语义切分、知识检索的关键数据来源。
文图混合数据（比如图文并茂的公告、报告、投研资料）非常常见。
文图混合数据的切分，核心是图文切分的关键是确保文图是对的上的，把“视觉信息”和“文本信息”统一到语义层面，保证切块既有完整文字内容，也能体现图片或图表的语义关联。
1）图文内容提取
使用 OCR 工具（如 PaddleOCR、腾讯OCR）提取图片中的文字和表格信息；
对文本块做自然语言处理，做断句和语义分析。
2）版面结构分析
使用 OCR 工具（如 PaddleOCR、腾讯OCR）提取图片中的文字和表格信息；
对文本块做自然语言处理，做断句和语义分析。
3）语义融合切分
结合图像内容分类（图表、照片、流程图等）和文本主题，按业务逻辑将图文组合成语义完整的切块；
对图表类图片做结构化描述，融合成文字块，确保图文信息同步传递。
4）多模态向量生成
生成文本向量和图像向量（使用CLIP、BLIP等多模态模型），辅助判断切块的语义边界，避免切分断裂；
5）元信息补全
每个切块标注来源页码、图文位置、版本信息，方便后续追溯和精确响应。
向量化：将每个知识片段转化为向量表示（比如Open AI的 Embedding 接口）
借助Embedding模型，将切分好的片段转化成向量（数字组成的）。
市面上主流的文本Embedding模型大致可以分为三类：
1）通用Embedding（适用于多语种 / 多场景）：
2）中文专用Embedding（适用于中文客服 / 文档场景）：
3）多模态/多语言Embedding（适用于网页混排、OCR文档等）：
在我们券商RAG项目中，我们做过Embedding模型的A/B对比，最后选择了：
中文主向项目使用 bge-base-zh（百度开源），因为它在金融语义聚类和FAQ相似度匹配上的表现优于OpenAI模型，且支持本地部署，方便做私有化；
涉及英文合规文档，我们选用 text-embedding-ada-002 来构建中英文混合知识库；
部分内容我们还试验过 bge-m3，它支持“多功能向量”（一次embedding可用于检索、聚类、排序），效果也不错。
完成向量化后，知识就变成了一块块可计算的“向量碎片”，但要让它真正发挥作用，还需要进入一个 高效、可控、可扩展的数据库 ——这就是数据入库的环节。
在 RAG 项目中，数据入库不仅仅是“存进去”，而是要保证 检索准确、更新及时、调用高效、安全合规。
常见的两类存储方案：
1）向量数据库（如 Milvus、Faiss、Pinecone、Weaviate）：
适合客服问答等“召回-排序-生成”的场景
2）关系型/文档型数据库（如 MySQL、Postgres、MongoDB）：
在金融业务中，通常与向量数据库 混合使用（Hybrid Search）
除了向量本身，还要存储丰富的 元数据，方便检索时做条件过滤。 常见元数据包括：
知识库是“活”的，不断有新公告、新政策、新业务上线。
因此，入库需要支持：
在金融场景下，这点尤为重要：比如 印花税下调、交易规则修改、公司行动变更，知识库必须在当天完成更新，才能避免客服答错。
在券商业务里，数据入库还必须满足金融行业的合规要求：
数据入库的目标不是“存得下”，而是要做到：
只有把知识存得“对、快、稳”，后续的检索增强（RAG）才能真正发挥价值，让智能客服既 答得准，又 答得放心。
还想补充一下，知识库不是一次性工程，而是一条“持续迭代的生命线”。
随着市场规则更新、业务流程调整，我们需要不断优化数据源、切分方式和向量检索策略，让 AI 始终与最新业务保持同步。
如果说大模型是“通用大脑”，那么 RAG 就像是给大模型装了一个知识外挂。原本只能靠“记忆”回答问题的语言模型，现在可以在回答前“查资料”，不仅提升了准确率，也让生成内容更加贴合用户的真实需求。
未来，谁能把知识库建设好，谁就能率先跑通智能化的应用闭环。
本文由 @梧桐AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图由作者提供
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。