从0到1构建 RAG 知识库(券商客服案例实战)

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.1FAQ类数据如何清洗

问题去重：同义问题合并（如“怎么开港股账户”和“开通港股账户流程”归为一类）

回答标准化：回答中去除冗余模板内容，如“您好，感谢您咨询…”等。

标签补全：为每条FAQ打上[开户][交易][港股]等语义标签，方便后续向量分组。

格式检查：确保问题不为空、回答字符集不乱（常见乱码问题）

脱敏处理：清除例子中的身份证、手机号、姓名等敏感数据

文档拆分：按[段落]or[章节]逻辑切块（避免语义中断）

样式清洗：删除纯格式字符（如空白页、换行符堆积、连续空格）

自然段标记：补足丢失的换行符，构建每段的“标题+正文”结构

元数据补全：记录来源、文档版本、发布日期等信息，供追溯使用。

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、图片、图文混合、语音、视频类如何切分，我做一个更详细的介绍，欢迎大家继续阅读～

根据文档逻辑结构+可视排版信息+语义完整性三个维度进行切分。

整个流程可以分为以下几步：

1）文档解析

2）结构识别

通过正则表达式或标题风格识别“章节标题”、“条款编号”（如第X条、1.2.3）作为一级切分点；

根据空行、缩进、符号判断自然段落边界。

3）分块切分（Chunking）

按照“一级标题+段落”组合成一个chunk，保持上下文完整；

每个chunk控制在300-500tokens，超长内容采用滑窗+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）版面结构分析

使用OCR工具（如PaddleOCR、腾讯OCR）提取图片中的文字和表格信息；

对文本块做自然语言处理，做断句和语义分析。

3）语义融合切分

结合图像内容分类（图表、照片、流程图等）和文本主题，按业务逻辑将图文组合成语义完整的切块；

对图表类图片做结构化描述，融合成文字块，确保图文信息同步传递。

4）多模态向量生成

生成文本向量和图像向量（使用CLIP、BLIP等多模态模型），辅助判断切块的语义边界，避免切分断裂；

5）元信息补全

每个切块标注来源页码、图文位置、版本信息，方便后续追溯和精确响应。

第四阶段：向量化

向量化：将每个知识片段转化为向量表示（比如OpenAI的Embedding接口）

借助Embedding模型，将切分好的片段转化成向量（数字组成的）。

市面上主流的文本Embedding模型大致可以分为三类：

1）通用Embedding（适用于多语种/多场景）：

OpenAItext-embedding-ada-002（使用最广泛，向量质量好，长度支持长达8Ktoken）

Cohereembed-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）：

存储结构化信息（如费率表、产品参数）

支持复杂的条件过滤与规则检索

在金融业务中，通常与向量数据库混合使用（HybridSearch）

5.2知识元数据管理

除了向量本身，还要存储丰富的元数据，方便检索时做条件过滤。常见元数据包括：

来源（公告/手册/系统）

适用范围（A股/港股/美股）

生效时间&版本号（解决知识时效性问题）

风险标签（合规、敏感信息）

5.3数据更新与增量入库

知识库是“活”的，不断有新公告、新政策、新业务上线。

因此，入库需要支持：

增量更新：只更新变更部分，避免全量重建

版本管理：保留历史版本，支持“回溯查询”

自动化pipeline：每日定时抓取公告→切分→向量化→入库，减少人工介入。

在金融场景下，这点尤为重要：比如印花税下调、交易规则修改、公司行动变更，知识库必须在当天完成更新，才能避免客服答错。

5.4安全与合规

在券商业务里，数据入库还必须满足金融行业的合规要求：

数据加密：存储和传输必须符合监管标准

访问控制：不同角色（客服、风控、研发）访问权限不同

审计追踪：每条知识的入库、调用、更新都有记录，方便审计

数据入库的目标不是“存得下”，而是要做到：

检索精准（用户问什么就能找到对应chunk）

更新及时（业务变化第一时间反映）

管理有序（元数据可控、合规可查）

只有把知识存得“对、快、稳”，后续的检索增强（RAG）才能真正发挥价值，让智能客服既答得准，又答得放心。

还想补充一下，知识库不是一次性工程，而是一条“持续迭代的生命线”。

随着市场规则更新、业务流程调整，我们需要不断优化数据源、切分方式和向量检索策略，让AI始终与最新业务保持同步。

如果说大模型是“通用大脑”，那么RAG就像是给大模型装了一个知识外挂。原本只能靠“记忆”回答问题的语言模型，现在可以在回答前“查资料”，不仅提升了准确率，也让生成内容更加贴合用户的真实需求。

未来，谁能把知识库建设好，谁就能率先跑通智能化的应用闭环。