RAG 不只是技术热词，它正在重塑企业知识系统的构建方式。本文以券商客服场景为例，系统拆解从0到1构建 RAG 知识库的全过程：从数据准备、向量化、检索策略到生成逻辑，不仅有技术路径，也有业务思维。
客户打来电话问：“我港股账户昨天除权，今天为什么显示持仓减少了？”
如果是人工客服，往往需要翻公告、查系统、确认结算规则，几分钟才能给出解释。
而在智能客服场景下，如果知识库没构建好，模型可能会一本正经地胡说八道。
有时答非所问，有时干脆甩一句：请联系人工客服……
这正是很多金融机构在大模型落地中遇到的最大瓶颈：模型有能力，却没有“业务知识”。要让 AI 真正懂业务、答得准，就必须构建一套属于自己的RAG 知识库。
本文结合券商智能客服的实践案例，带你走完整个知识库的构建流程——从 数据提取、数据清洗与格式化、内容切分、向量化，到数据入库，逐步揭开 RAG 知识库背后的秘密～
在构建领域知识库时，我们需要考虑具体的五个阶段：
第一阶段：数据提取
这里我们会遇到两大类数据：
1.1 结构化的数据（excel、csv、 json)
特点：数据已经按照表格/字段存储，有固定格式，能直接拿来用
例如：
- 数据库表：SQL数据库中的表格（如产品信息、用户数据、交易记录）。
- 知识图谱：实体-关系三元组（如维基百科的Wikidata、企业内部的领域知识图谱）。
- API接口：从外部系统（如CRM、ERP）拉取的实时结构化数据（如客户订单、库存状态）。
以券商场景为例：
- 交易规则表：如“美股交易时间表（开市9:30，收市16:00，T+2交收规则）”
- 费率表：股票佣金、印花税、过户费等，已经整理成Excel或数据库
- 账户信息：开户状态、资金流水、持仓记录等
这些数据就像是已经排列好的“excel 表格”只要对接数据库/接口。就能直接入库。
那非结构化数据是什么呢？
1.2 非结构化数据
特点：数据是“原材料”，没有统一格式，需要先清洗/切分后才能用
- PDF/Word/PPT（如技术手册、政策文件、合同）；
- 网页内容（通过爬虫抓取的行业报告、论坛讨论）；
- 书籍/论文：学术文献（如ArXiv、PubMed）、教科书、专利文档；
- 社交媒体：Reddit、Twitter、知乎等平台的讨论（需清洗噪声）；
- 聊天记录：客服对话、用户反馈（需脱敏处理）。
券商场景的非结构化数据长什么样的，这里给大家枚举一些：
- 公告、招股书类PDF：公司行动公告（分红、配股、合股拆股）、IPO招股书等都是非结构化文件；
- 客服对话记录：用户提问“为什么我的港股红利还没到账？”→语气口语化，冗余信息多；
- 语音/录音：用户打电话咨询，产生的音频文件；
- 网页/帮助中心文章：FAQ页面的内容多是长文本，没有表格化。
这些数据就像一堆“原矿石”，必须通过OCR、语音转写、文本切分等方式“提炼”成知识片段，才能被检索和调用。
第二阶段：数据清洗及格式化
数据清洗及格式化：将不同格式的数据内容提取为纯文本
2.1 FAQ类数据如何清洗
- 问题去重：同义问题合并（如“怎么开港股账户”和“开通港股账户流程”归为一类）
- 回答标准化：回答中去除冗余模板内容，如“您好，感谢您咨询…”等。
- 标签补全：为每条FAQ打上【开户】【交易】【港股】等语义标签，方便后续向量分组。
- 格式检查：确保问题不为空、回答字符集不乱（常见乱码问题）
- 脱敏处理：清除例子中的身份证、手机号、姓名等敏感数据
2.2 文档类数据清洗（PDF/Word/制度类文档）
我们用 PyMuPDF做结构提取，然后执行：
- 文档拆分：按【段落】or【章节】逻辑切块（避免语义中断）
- 格式规整：去除页眉页脚、编号、目录项（很多PDF页码与正文混在一起）
- 样式清洗：删除纯格式字符（如空白页、换行符堆积、连续空格）
- 自然段标记：补足丢失的换行符，构建每段的“标题+正文”结构
- 元数据补全：记录来源、文档版本、发布日期等信息，供追溯使用。
2.3 对话类数据清洗（客服IM、语音转写）
- 去噪处理：清除“呃”、“·这个…”、“等一下”等口语停顿和冗余语句
- 文本脱敏：正则过滤身份证号、卡号、手机号等隐私数据
- 意图提取：使用NLP工具（如spaCy、LTP）提取问题主干，如：“我转不了账”→【转账失败】
- 标签化对话：标记用户意图（开户/入金/转户/投诉），便于训练与召回
- 去情绪干扰：过滤负面情绪词，仅保留业务主句（如“这破系统怎么转户啊”→“如何转户”）。
2.4 网页/App内容清洗（HTML文本）
- 标签解析：用BeautifulSoup/Playwright将HTMLDOM解析为纯正文
- 内容分块：识别【FAQ板块】【说明板块】【公告板块】进行独立向量处理
- 多语言处理：中英文混排场景，做分语种标记，避免embedding误差
- 自动更新机制：使用diff机制检测更新页面，只重处理变更区域（减少计算量）
2.5 如何去重呢？
精确去重，使用的哈希（Hash），它可以快速判断文本是否完全一致
对于语义去重，我们是利用语义向量（embedding）+相似度计算的方法
具体做法是把文本转成高维向量，然后计算它们的余弦相似度。
当相似度超过某个阈值（比如0.9或0.95）时，我们就判定这些文本是语义重复，从而进行合并或过滤。
这种方法能有效识别“我想开户”和“怎么开账户”这类表达不同但意思相同的文本，是智能客服和RAG系统中提升知识库质量的关键。
通俗来说：哈希就像是文本的“身份证号码”，严格匹配；而语义向量是文本的“脸部识别”，看整体相似度。
比较相似度的几种方法：
余弦相似度：含义：计算两个向量之间的夹角余弦值
数学公式：cos(θ) = A·B / (‖A‖‖B‖)特点：关注方向，不考虑向量长度
应用场景：稳定性好，语义类首选欧式距离：计算两个向量之间的“空间直线距离”数学公式：√Σ (Ai-Bi)²特点：关注绝对位置差值，受向量长度影响大
应用场景：几何直觉强（图像/物理空间定位类问题常用）点积：向量内积，考虑方向和长度数学公式：A·B = ΣAi*Bi特点：值大代表方向一致且“强”，值小代表方向偏离
应用场景：高效计算，与模型训练兼容性强。
第三阶段：内容切分（Chunking）
目标：构造最小可复用、可引用的知识单元。
常见做法是 基于规则 +NLP模型：
规则切分按字符数（比如 200–500 字一个 chunk）；
- 按标点符号（句号、分号、换行符）；
- 按结构（标题、列表、表格单元格）。
容易踩坑的点：切分过大召回噪声多、过小上下文断裂。
关于不同的格式PDF、图片、图文混合、语音、视频类如何切分，我做一个更详细的介绍，欢迎大家继续阅读～
3.1 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语义通顺、结构清晰。
3.2 图片类如何切分？
对于图片类数据，我们通常分为两步：先进行内容识别，再进行语义切分。
1）图片预处理
对图片做去噪、去水印、裁剪等基础图像处理，保证后续识别质量；
对文档类图片使用图像增强技术提高OCR准确率。
2）OCR 文字识别
使用高性能OCR工具识别图片中的文字和表格；
同时提取文字位置、字体大小、布局信息，辅助后续切分。
3）图像分块与切分
根据OCR识别的文字位置，结合图像的空间布局，做逻辑区域划分；
对于图表类图片，我们会先做图表结构识别（图例、坐标轴、图形元素），再拆分成对应的文字描述+结构块。
4）语义级别切分
在文本提取后，按照自然语言的断句和业务逻辑进行语义切分，保证内容的完整性和上下文连续；
对图表、合同页等内容，会做额外的语义补充说明，方便向量召回。
5）元信息补充
每个切块会标记图片来源、页码、截图时间等，便于回溯和查询。
我们确保图片类数据不仅能被“看懂”，而且可以高效地参与到知识检索与智能问答中。
3.3 音频类如何切分？
这里主要用到ASR
ASR（自动语音识别）是将语音信号转化为对应文本的技术，是语音类数据接入自然语言处理系统的第一步。
在券商的智能客服项目中，ASR负责：
- 音频转文本：通过训练好的语音识别模型，将客户语音、电话录音、会议录音转换成文字，保持时间戳同步。
- 说话人分离与标注：在多说话人场景，做说话人分割，标明发言人，提升文本结构清晰度。
- 识别准确率优化：通过领域适配、定制化词表和语言模型微调，提高专业术语和专有名词的识别率。
为后续语义分析和RAG提供文本基础。
识别文本成为后续语义切分、知识检索的关键数据来源。
3.4 文➕图如何切分？
文图混合数据（比如图文并茂的公告、报告、投研资料）非常常见。
文图混合数据的切分，核心是图文切分的关键是确保文图是对的上的，把“视觉信息”和“文本信息”统一到语义层面，保证切块既有完整文字内容，也能体现图片或图表的语义关联。
1）图文内容提取
使用 OCR 工具（如 PaddleOCR、腾讯OCR）提取图片中的文字和表格信息；
对文本块做自然语言处理，做断句和语义分析。
2）版面结构分析
3）语义融合切分
结合图像内容分类（图表、照片、流程图等）和文本主题，按业务逻辑将图文组合成语义完整的切块；
对图表类图片做结构化描述，融合成文字块，确保图文信息同步传递。
4）多模态向量生成
生成文本向量和图像向量（使用CLIP、BLIP等多模态模型），辅助判断切块的语义边界，避免切分断裂；
5）元信息补全
每个切块标注来源页码、图文位置、版本信息，方便后续追溯和精确响应。
第四阶段：向量化
向量化：将每个知识片段转化为向量表示（比如Open AI的 Embedding 接口）
借助Embedding模型，将切分好的片段转化成向量（数字组成的）。
市面上主流的文本Embedding模型大致可以分为三类：
1）通用Embedding（适用于多语种 / 多场景）：
- OpenAI text-embedding-ada-002（使用最广泛，向量质量好，长度支持长达8K token）
- Cohere embed-v3, embed-english-light；
- HuggingFace上的 sentence-transformers（如 all-MiniLM-L6-v2、mpnet-base-v2）。
2）中文专用Embedding（适用于中文客服 / 文档场景）：
- BGE模型（如 bge-base-zh, bge-large-zh, bge-m3） → 性能好、适配中文
- Langboat / E5系列
- 讯飞、智谱等大厂提供的中文语义模型
3）多模态/多语言Embedding（适用于网页混排、OCR文档等）：
- GTE、LaBSE → 支持多语言对齐（适合中英混排）
- CLIP / XLM-R 等 → 图文场景或跨语种向量对齐
在我们券商RAG项目中，我们做过Embedding模型的A/B对比，最后选择了：
中文主向项目使用 bge-base-zh（百度开源），因为它在金融语义聚类和FAQ相似度匹配上的表现优于OpenAI模型，且支持本地部署，方便做私有化；
涉及英文合规文档，我们选用 text-embedding-ada-002 来构建中英文混合知识库；
部分内容我们还试验过 bge-m3，它支持“多功能向量”（一次embedding可用于检索、聚类、排序），效果也不错。
第五阶段：数据入库
完成向量化后，知识就变成了一块块可计算的“向量碎片”，但要让它真正发挥作用，还需要进入一个 高效、可控、可扩展的数据库——这就是数据入库的环节。
在 RAG 项目中，数据入库不仅仅是“存进去”，而是要保证 检索准确、更新及时、调用高效、安全合规。
5.1 选择合适的存储方式
常见的两类存储方案：
1）向量数据库（如 Milvus、Faiss、Pinecone、Weaviate）：
适合客服问答等“召回-排序-生成”的场景
2）关系型/文档型数据库（如 MySQL、Postgres、MongoDB）：
- 存储结构化信息（如费率表、产品参数）
- 支持复杂的条件过滤与规则检索
在金融业务中，通常与向量数据库 混合使用（Hybrid Search）
5.2 知识元数据管理
除了向量本身，还要存储丰富的 元数据，方便检索时做条件过滤。 常见元数据包括：
- 来源（公告/手册/系统）
- 适用范围（A股/港股/美股）
- 生效时间&版本号（解决知识时效性问题）
- 风险标签（合规、敏感信息）
5.3 数据更新与增量入库
知识库是“活”的，不断有新公告、新政策、新业务上线。
因此，入库需要支持：
- 增量更新：只更新变更部分，避免全量重建
- 版本管理：保留历史版本，支持“回溯查询”
- 自动化pipeline：每日定时抓取公告→切分→向量化→入库，减少人工介入。
在金融场景下，这点尤为重要：比如 印花税下调、交易规则修改、公司行动变更，知识库必须在当天完成更新，才能避免客服答错。
5.4 安全与合规
在券商业务里，数据入库还必须满足金融行业的合规要求：
- 数据加密：存储和传输必须符合监管标准
- 访问控制：不同角色（客服、风控、研发）访问权限不同
- 审计追踪：每条知识的入库、调用、更新都有记录，方便审计
数据入库的目标不是“存得下”，而是要做到：
- 检索精准（用户问什么就能找到对应chunk）
- 更新及时（业务变化第一时间反映）
- 管理有序（元数据可控、合规可查）
只有把知识存得“对、快、稳”，后续的检索增强（RAG）才能真正发挥价值，让智能客服既 答得准，又答得放心。
还想补充一下，知识库不是一次性工程，而是一条“持续迭代的生命线”。
随着市场规则更新、业务流程调整，我们需要不断优化数据源、切分方式和向量检索策略，让 AI 始终与最新业务保持同步。
如果说大模型是“通用大脑”，那么 RAG 就像是给大模型装了一个知识外挂。原本只能靠“记忆”回答问题的语言模型，现在可以在回答前“查资料”，不仅提升了准确率，也让生成内容更加贴合用户的真实需求。
未来，谁能把知识库建设好，谁就能率先跑通智能化的应用闭环。
本文由 @梧桐AI 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图由作者提供
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
