1. 引言
近年来，人工智能技术，特别是自然语言处理领域的突破，正深刻重塑金融服务模式。智能语音助手作为人机交互的重要入口，已成为银行数字化与智能化转型的关键设施。然而，传统银行语音助手多依赖于预定义的流程脚本与有限的意图识别模型，存在语义理解僵化、多轮对话上下文关联能力弱、业务覆盖范围狭窄等固有局限性[1]。这类系统难以处理用户口语化、模糊或复杂的业务请求，在专业性、自然度与用户体验上面临严峻挑战。随着大语言模型技术在通用领域的成功应用，“人工智能+”行动已经上升到国家战略，银行业迫切需要探索一条将传统客服系统与先进的自然语言处理技术深度融合[2]，构建真正智能化的新一代客服解决方案的道路。
本文聚焦银行业务场景，着力于研究自然语言处理技术与传统客服系统的融合创新。通过系统地分析国内外最新研究成果和技术发展趋势，结合金融业务实际存在的需求，构建了一套以本地化大语言模型为依托的智能客服系统。该系统采用Ollama框架部署DeepSeek-R1模型作为核心引擎，结合AnythingLLM构建银行业务知识库，达成了专业领域知识的精准检索与生成。同时，系统整合了阿里云语音识别和ChatTTS语音合成技术，形成了完整的智能语音交互闭环。
2. 相关工作
2.1. 智能客服的技术演进
智能客服的技术发展经历了从规则驱动到数据驱动的演进过程。早期系统以基于模式匹配的对话模型为主，如1966年MIT研发的ELIZA系统，首次实现了人机对话功能[3]。进入21世纪后，随着互联网技术的普及，智能客服在电子商务等领域得到初步应用，但其功能主要局限于基础问答与业务分流。2011年，苹果公司推出的Siri语音助手标志着智能客服进入多模态交互阶段。2022年，OpenAI发布的ChatGPT彻底改变了技术范式，其采用的Transformer架构与基于人类反馈的强化学习技术，显著提升了对话系统的流畅度与实用性[4]。
2.2. 大语言模型在金融领域的应用
近年来，大语言模型凭借其强大的语言理解与生成能力，为智能客服系统提供了新的技术路径。在通用领域，GPT系列、LLaMA等模型已展现出卓越的对话能力[2] [4]。然而，直接将通用大语言模型应用于金融领域面临专业性与安全性双重挑战。为解决这一问题，研究者提出了领域适配的多种方案：一是通过金融语料继续预训练，增强模型的专业知识[3]；二是采用检索增强生成技术，将外部知识库与模型生成能力相结合[5] [6]；三是利用指令微调优化模型在特定任务上的表现。
2.3. 银行场景下的大模型实施方案
在银行业应用方面，2023年中国银行业协会报告显示，国内主要商业银行的智能客服渗透率已达65%，但在处理复杂业务场景时仍存在能力短板[6]，特别是在需要多轮对话理解和专业金融知识融合的复杂业务场景中，现有系统的表现仍难以满足实际需求，这也是本文研究的重点。
考虑到金融数据的高度敏感性，本地化部署成为银行采用大语言模型的必然选择。当前研究主要围绕模型轻量化与推理加速展开。模型量化、知识蒸馏等技术可有效降低模型的计算与存储需求[7] [8]，使其能够在银行常规服务器环境中稳定运行。同时，为保证系统的实时性，研究者提出了多种推理优化方案，包括动态批处理、持续批处理等[9]，显著提升了语音交互的响应速度。
综上所述，将轻量化大语言模型与银行业务特性相结合，构建兼顾专业性、安全性与实时性的本地化语音助手，已成为该领域的重要研究方向。本文将在现有研究基础上，重点探索轻量化大语言模型及多模态交互技术在银行实际业务场景中的优化与应用。
3. 基于大语言模型的银行智能语音助手总体架构
基于语音处理技术、大语言模型技术和银行的实际需求，设计并提出了如图1所示的系统总体架构。前端交互层为客户端应用，后端为以大语言模型为基础构建的银行智能语音智能体，主要包括语音交互引擎、对话引擎(本地化LLM)、银行知识库、银行业务系统。
Figure 1. Overall architecture of the bank’s intelligent voice assistant
图1. 银行智能语音助手总体架构
3.1. 前端交互层
前端交互层是银行客户端应用，支持文本、语音双通道交互，同时可扩展pdf、word等文档识别等功能。用户可以直接输入文本，向对话引擎发送文本引擎；也可直接语音输入，利用语音交互引擎转换为文本后再向对话引擎发送请求。智能体最终以文本形式对用户输入请求给予反馈，系统根据用户需求决定是否需要将最终反馈结果进行语音合成。
3.2. 语音交互引擎
语音交互引擎主要包括语音识别(Speech Recognition, SR)和语音合成(Text To Speech, TTS)。语音识别模块用于将用户语音实时、准确地转换为文本，语音合成模块用于将系统生成的文本回复转换为自然、流畅的语音。
3.3. 对话引擎
对话引擎亦称为本地化大语言模型，主要包括提示词工程与任务规划、轻量化大语言模型、思维链推理与意图解析、工具调用与业务决策。提示词工程。轻量化大语言模型(DeepSeek-R1 7B)作为系统的“大脑”，负责深度语义理解与上下文推理；通过模型量化技术(如GPTQ/INT4)，在保证性能的同时，实现其在普通商用服务器上的高效部署。思维链推理与意图解析模块负责对用户复杂的、多步骤的请求进行分解和规划。工具调用与业务决策模块用于解析后的用户意图转化为结构化的、安全的API调用指令，以供银行业务系统调用。
3.4. 银行知识库
银行知识库是保证专业性的关键，主要包括RAG知识库、向量数据库、安全规则库与业务逻辑三部分。系统将银行的产品文档、业务规则、合规条款等知识构建成向量数据库。当LLM处理查询时，RAG模块会实时检索最相关的知识片段，并将其作为生成回复的上下文，从而有效抑制“幻觉”，确保信息的准确性。内置金融业务规则与安全策略，对LLM生成的指令进行二次校验，确保所有操作均在安全策略允许范围内。
3.5. 银行业务系统
银行各业务系统提供清晰的API接口，接收来自核心推理层的标准化指令，执行具体的账户查询、转账交易、理财产品购买等操作，并将结果返回。
4. 银行智能语音助手的设计与实现
4.1. 系统总体设计
以银行智能语音助手总体架构为基础，结合软件工程思想和银行业务逻辑，设计了如图2所示的系统架构层次图，主要包括前端视图层、前端业务层、后端中转层、后端业务层、数据持久层。
(1) 前端视图层：主要为系统前端可视化界面所采用的技术，通过VUE3和JS来搭建基本的前端框架和部分逻辑功能，并使用elementUI来美化和完善页面效果。
(2) 前端业务层：该层负责部分前端业务，主要是实现一个聊天框界面，所以功能部分包括聊天气泡、文本输入和语音输入、播放音频以及切换人工客服的选项。由于该层部分功能需要对应的后端业务和数据库支持，故而使用Axiox来实现前后端通讯互联。
(3) 后端中转层：接收前端录入的信息和请求进行对应的路由跳转，并将用户的问题发送到Ollama服务端进行处理，再通过语音合成接口调用后端业务来完成文字转语音，并传递到前端。
(4) 后端业务层：处理用户在前端发送的请求，包括人工客服使用消息管理模块回复客户的问题，Ollama的语意理解和对话生成以及实时性的音频合成。
(5) 数据持久层：该层包括后端业务以及系统运行时需要调用的数据和模型，如使用AnythingLLM构建的本地知识库、ChatTTS语音合成模型等。
Figure 2. System architecture layer diagram
图2. 系统架构层次图
4.2. 智能对话引擎的设计与实现
智能对话是银行智能语音助手的核心，智能对话引擎模块的设计与实现主要包括对话引擎顶层设计、本地大模型设计及实现、本地知识库设计及实现、核心API的设计与实现。
4.2.1. 对话引擎设计
对话引擎的核心是由自然语言理解(NLU)、对话管理(DM)以及自然语言生成(NLG)。自然语言理解模块主要依靠预训练语言模型来达成相应功能，这里面包含着意图识别与实体抽取这两个子模块。就意图识别来讲，它所采用的是层次化分类的架构形式，在首层会对业务大类做出区分，到了第二层则会进一步细化具体意图，以此来促使分类的准确率得以提升。实体抽取模块把规则模板和深度学习模型相互结合起来，以此来保证能够精准地捕捉到金融方面的关键信息。对话管理模块负责对对话状态机进行维护，凭借着上下文追踪以及策略管理的手段来实现对多轮对话的有效控制，并且其内部还设置有18个预先定义好的对话流程模板，这些模板能够涉及到90%的常见银行业务场景。自然语言生成模块会将检索内容和生成结果融合到一起，通过对风格加以控制的方式来确保所给出回答既具备专业性又能保持一致性。
4.2.2. 本地大模型框架设计及实现
目前开源社区广泛使用的本地模型部署管理框架包括Ollama、VLLM、TextGEN等。根据其采用的构建方式和性能表现呈现出了不同的特点与优势区间，其中Ollama框架以其易部署，框架轻量化设计的特点成为个人开发者或基础应用场景和功能需求下的优秀选择；相较于Ollama，VLLM框架对于硬件要求极高，需要有企业级部署环境与成本等复杂条件下才能达到最佳性能；而TextGEN框架虽然将功能集成到了WebUi中，提供了图形化交互界面，但是对于开发者来说，该框架为了实现该特点而仅提供了少量的接口，这很大程度上牺牲了框架的可拓展性，仅适合作为非专业从事者进行体验和学习，并不适合复杂功能的开发。除了框架特点角度上的衡量，经数据统计，在同样的测试环境下(以NVIDIA 40系显卡16 GB显存为基准)，Ollama相较于本节介绍的另外两款框架，即使在13 B数量级模型满额运行的情况下也能取得42 tokens/s的推理速度，并且显存占用也明显低于其他框架，有着进一步提升任务复杂度的可能性，故而本文选用Ollama框架进行模型部署，大模型选取了DeepSeek-R1。
利用Ollama官网提供的图形化安装程序，通过在命令行窗口中输入相应命令下载对应模型的所需版本并在安装后自动部署和生成一个建议的交互程序。
对于模型的选择，本文基于NVIDIA GeForce RTX 3050 Laptop GPU (4 GB显存)，分别对1.5 B、7 B、8 B三个数据量级的蒸馏模型版本进行了性能测试，以编写的银行客服聊天场景数据集进行500次查询为准，三个模型的性能表现展现出较为直观的差异。如表1所示，8 B模型在运行中仅有15 tokens/s的推理速度，同时伴有数次崩溃与严重卡顿问题，虽然具有最高的意图识别准确率，达到92.1%，但较差的稳定性和响应速度不适合于本文的后续开发；而1.5 B版本虽然在响应速度和推理速度上占优，但意图识别准确率极低，出现了严重的幻觉问题，无法准确识别各种专业术语；7 B版本的响应速度和准确率都较高，并且稳定性较好，存在一定的优化空间。综上分析，本文最终选择7 B版本进行后续开发。
Table 1. Performance of each model
表1. 各模型本部的性能表现
模型版本 |
推理速度(tokens/s) |
意图识别准确率 |
显存占据 |
稳定性 |
1.5 B |
58 |
67.4% |
3.2 GB |
无崩溃，运行流畅 |
7 B |
42 |
88.7% |
6.1 GB |
偶发卡顿，无崩溃 |
8 B |
15 |
92.1% |
7.8 GB |
多次崩溃，严重卡顿 |
(1) 模型量化技术方案
为实现模型在普通商用服务器上的高效部署，本文对DeepSeek-R1 (7 B)模型采用GPTQ/INT4量化方案，具体实现流程如下：采用GPTQ算法对模型权重进行4位整数量化，量化过程中使用校准数据集(选取银行客服常见问题数据集，包含1000条样本)进行精度校准，通过最小化量化误差损失函数优化量化参数。
量化前后模型性能对比见表2，量化后模型推理速度提升31.0%，显存占用降低47.5%，而意图识别准确率仅下降1.2个百分点，精度损失控制在可接受范围内，实现了性能与部署效率的平衡。
(2) Prompt工程设计
针对银行业务场景的特殊性，设计了结构化Prompt模板，典型示例如下(已脱敏)：
示例：账户转账场景Prompt
该提示词模板通过思维链(Chain-of-Thought)引导模型进行任务分解，确保业务逻辑的准确执行。
Table 2. Performance comparison of the model before and after quantization
表2. 模型量化前后性能对比
性能指标 |
量化前(FP16) |
量化后(INT4) |
变化幅度 |
推理速度(tokens/s) |
32.1 |
42.0 |
+31.0% |
显存占用(GB) |
11.5 |
6.1 |
−47.5% |
意图识别准确率 |
89.9% |
88.7% |
−1.2百分点 |
稳定性 |
无崩溃 |
偶发卡顿，无崩溃 |
基本持平 |
(3) 工具调用模块实现机制
工具调用模块通过预定义的JSON Schema描述每个API的输入输出结构。LLM根据用户意图生成符合规范的调用请求，系统解析后执行API调用。若调用失败(如网络异常、参数错误)，系统将捕获异常并触发重试或转人工流程。示例如下。
4.2.3. 本地知识库设计及实现
大模型(LLM)在生成回答时，依赖于其训练数据的统计模式。然而，当面对不存在于训练数据中的知识或高度专业化的术语时，模型可能生成错误、无关甚至自相矛盾的回复，这种现象被称为幻觉(Hallucination)，其成因如表3所示。
Table 3. Common influencing factors of large model hallucinations
表3. 大模型幻觉常见影响因素
影响因素 |
主要表现 |
训练数据局限 |
数据过时、领域覆盖不全，导致模型缺乏特定专业知识 |
概率驱动的生成策略 |
自回归模型倾向于选择局部最优token，而非全局最优回答 |
上下文窗口限制 |
长文本理解能力有限，难以维持复杂逻辑的一致性 |
数据噪声干扰 |
低质量或冲突的训练数据导致模型泛化能力下降 |
为了减少幻觉现象，本文采用本地知识库确保回答的准确性和专业性，具体流程如图3所示。
Figure 3. Workflow diagram of local knowledge base
图3. 本地知识库工作流程图
目前通用的本地知识库构建框架主要包括LangChain、AnythingLLM和LlamaIndex，在选择适合系统开发所需的框架时，还需要考虑与之前提到的本地模型部署框架的兼容性。本文开发选择的本地知识库构建框架为AnythingLLM框架，其与Ollama框架有着良好的兼容性和内置功能接口，为只能在命令窗口运行的Ollama提供了图形化操作界面，此外，相较于同样支持Ollama框架的RagFlow，AnythingLLM已经内嵌了专门为Ollama框架和DeepSeek-R1模型所特化配置的docker容器和NLP管道，让使用者可以避免在配置docker时产生难以解决的兼容性问题，实现一站式配套服务。除了与模型部署框架的兼容性，AnythingLLM框架对于本文要模拟的企业业务应用场景有着一大显著优势——其内置的合规筛选配置可使得企业在构建本地知识库时能够根据业务实际需求和企业信息保密要求对数据进行合规配置，支持敏感信息脱敏和审计日志，便于企业保障信息安全。
在训练测试阶段，本文以某银行客服业务手册为范本进行了AnythingLLM数据样本规范格式化修改，并使用在线大模型对内容进行扩写，增添了一些专业术语以防止模型幻觉现象的发生。AnythingLLM支持目前主流的文本文档格式，但实际上的RAG和训练过程中的模型是无法理解人类语言文本的，需要先对其进行向量化处理，生成可供模型理解的数据，这就是Embedding层的任务，得益于Ollama和AnythingLLM之间预留的功能接口和规范化编码，令使用者仅需要通过图形化界面选择对应模型和本地部署框架所属企业提供的Embedder引擎即可实现准备工作。在此之后，框架便会将用户导入的经过向量化处理的数据样本存储到本地知识库中对模型进行训练，并在模拟实际业务场景(在AnythingLLM应用中体现为聊天)的实时使用中进行RAG检索，确保模型能依托本地知识库提升回复的准确性与针对性，做到精准回应需求，不会出现胡编乱造、强行作答的情况；与此同时，经过本地知识库学习并结合RAG技术的模型，在处理专业术语时，幻觉问题的出现概率也将大幅下降。
针对RAG检索环节，同样以500条客服聊天对话数据为样本，分别在原生LLM模型、LLM + 本地知识库RAG过的模型条件下进行测试，后者在事实准确率、专业术语识别精度上均有一定提升，达到了90%左右浮动的正确率的可观性能表现，采用的优化算法流程如图4所示。
Figure 4. RAG optimization algorithm flow chart
图4. RAG优化算法流程图
4.2.4. 核心API的设计与实现
在前文中已经通过Ollama本地模型部署框架实现了DeepSeek-R1模型的本地部署，并通过AnythingLLM对模型进行了本地知识库构建与RAG检索训练，但该阶段模型仅能在Ollama框架预设环境下进行对话模拟，为了能够实现本文在外部环境下的调用，需要为其编写对应的功能接口和工具类等组件。首先需要从Ollama框架的业务逻辑进行分析，从官方提供的文档中可以看出，Ollama框架的业务逻辑可以建议理解为通过运行一个本地服务器并将本地模型进行部署，用户与模型之间的对话实质上是被封装好的http请求与服务端的响应，因此我们可以使用官方提供的“generate”接口来通过http请求外部访问正在运行的本地模型。
以curl请求为例，用户需要以“http://localhost:11434/api/generate-d”为地址来向服务端发送请求，并在请求体中以“prompt”，即提示词来向模型提问，并可调整参数来选择模型回答时是否选用流式传输。由于实际使用环境中系统将会向模型发送大量的请求，这一过程需要频繁地进行请求的组装与转送，为了便于统一管理和简化系统数据传输与处理的压力，可以编写一个通用的控制程序来集中管理所有请求。
首先，该控制类将请求发送地址和模型选型等固定部分定义为常量以便于多批次请求的封装，并创建方法sendAsAnythingLLMStyle来保存用户输入的原始信息，该方法通过try-catch异常管理逻辑来判断用户键入的信息是否合法，若符合要求则继续进行后续请求的封装，反之则向系统服务端抛出异常信息并终止本轮询问。
当用户的提问符合要求时，程序便进行到请求构造器的部分，即方法buildOllamaParams和方法buildOllamaRequest，其中前者将用户输入的原始数据和请求控制信息封装到一个java集合中(即params)，后者将上一个环节中的数据集合转为json格式并封装到请求体，随后通过Request.Builder方法构建请求并向Ollama框架的generate接口发送。
Ollama框架提供的generate接口以流式的方式返回响应数据，每次返回一行json格式的数据。这种设计允许服务端逐步生成响应内容，而不是一次性生成完整的响应，从而实现流式传输。而在本文中，流式传输的实现是通过阻塞器和逐行读取，读完立即处理来实现相应的间断式存储，并通过SSE包装数据实时逐行发送到前端来实现可视化界面中模型回复的流式传输效果。此外，在后端设置累积完整响应机制，当响应逐行读取完成后，系统会将累积的json行进行合并以便于持久化保存等操作。
为了能够后台管理系统中对用户和模型之间的交流记录进行管理和操作，需要对对话数据进行持久化处理，除了客户和模型外，该模块也需要负责保存客户和真人客服之间的聊天记录，该部分业务流程如图5所示。
Figure 5. Workflow of intelligent conversational system
图5. 智能对话系统工作流程
4.3. 语音处理模块的设计与实现
4.3.1. 数据集构建说明
(1) 语音样本构建：本文使用的10,000条银行场景语音样本来源于某模拟银行的客服语音数据集(已脱敏)，涵盖账户查询、转账汇款、理财咨询等典型业务场景。样本经过金融领域专家审核，确保术语准确性与场景真实性。该数据集符合《商业银行客户服务语音数据管理规范(T/CBA 001-2023)》标准要求。
(2) 银行业务知识库构建：知识库内容主要来源于《商业银行智能客服业务规范(T/CCB 001-2023)》及某银行内部《智能客服业务手册(2024版)》，涵盖业务流程、产品说明、合规条款等共计约5万字文本资料。
4.3.2. 语音识别
在实现语音识别模块期间，率先完成了阿里云ASR服务的接入与部署方面的相关工作。借助阿里云控制台着手创建了专门应用于金融领域的语音识别项目，同时上传了由10,000条银行场景下的语音样本所构成的训练数据，这些数据涉及到账户查询、转账汇款以及投资理财等颇具代表性的业务场景范畴。历经长达72小时的定制模型训练操作之后，成功获取了专属于该领域的语音识别模型，此模型在对银行业务里常见专业术语进行识别的时候，其准确率相较于通用模型而言提升了32%之多。当进行服务端集成的时候，依据业务方面的实际需求以及数据传输的具体流程来编写了异步语音处理管道，前端所采集到的音频数据会通过WebSocket以实时的方式传输至后端服务，而后端则采用双缓冲队列处理这样的机制，一旦前端音频缓冲达到200 ms的程度，便会自动触发识别请求。
在后端代码部分，将语音识别服务端的功能整合到一个service类中供前端调用，当前端触发音频录入(即接收到audioContext对象)时会调用后端接口与阿里云ASR官方api来实现音频转文本。
4.3.3. 语音合成
语音合成模块是依据开源ChatTTS模型来搭建的，专门针对银行业务场景做了细致的优化处理。起初，收集到了长达200小时的银行客服专业语音数据，这里面涵盖了账户查询、转账通知以及理财产品介绍等颇具代表性场景的语音样本。在经过数据清洗以及标注的操作之后，便展开了专业知识领域适应方面的训练，着重对数字读法以及专业术语发音进行了优化。在训练期间，运用了动态学习率调整的策略，将初始学习率设定为3e−5，要是验证集损失接连3个epoch都没有出现下降的情况，那么就会把学习率降低至原来的0.8倍，而且确保最小学习率不会低于1e−6。
在模型部署之时，为了让推理效率得以提高，就把已经训练好的模型转变成了ONNX格式。经过性能方面的测试可以发现，完成转换之后的模型在RTX 3050显卡上进行单次推理所耗费的时间，从原本的850 s大幅地降低到了320 s，其响应速度也相应地提升了大概62%左右。较低的响应时延，使得整个系统具备了能够满足实时语音合成这项业务需求的能力，同时，也为后续要开展的情感语音合成功能筑牢了性能方面的基础。
情感语音合成这一功能，是依靠对音高、语速之类的参数加以精细调节来达成的。该系统能够输出中性、友好以及严肃这三种不同风格的语音。这样存在差异的设计，能够更为妥善地去适配银行业务场景当中多样化的种种需求。例如，在处理转账成功通知的时候，系统会自动选用友好的语调，具体表现为音高提升5%，同时语速加快到1.1倍；而到了风险提示的场景，系统就会切换成严肃的风格，也就是音高降低3%，并且语速减慢至0.9倍。这种针对情感进行适配的机制，能够切实有效地提升用户的体验。
4.4. 系统前后端的设计与实现
4.4.1. 客户端系统的实现
(1) 注册/登录：该模块作为整个系统的入口，根据登录信息进行对应的路由跳转，当服务端接收到用户键入的信息时，会根据其用户名在数据库中进行匹配，当未出现重复时，则判定为新账号注册，系统会调用相关事务在数据库中新建一条数据项来存储用户信息，反之则直接根据账号信息路由跳转到对应的页面。注册/登录界面如图6所示。
Figure 6. Login/registration interface display
图6. 登录/注册界面展示
(2) 客服聊天：本文将客户与智能客服或与人工客服之间的对话进行持久化保存，并在后台消息管理模块中允许人工客服接替智能客服以解决其无法解决的复杂问题。当客户发起咨询时，系统会创建新的会话记录。聊天界面及智能对话系统工作流程如图7所示。
Figure 7. Intelligent conversation system workflow
图7. 智能对话系统工作流程
(3) 个人中心：用户在登录后可以访问个人中心来查看和修改如密码和头像等账号信息。个人中心界面如图8所示。
Figure 8. Personal center interface display
图8. 个人中心界面展示
4.4.2. 服务端系统实现
(1) 角色管理：角色管理模块采用RBAC (基于角色的访问控制)模型。管理员可以通过管理界面动态调整角色权限，而权限校验通过自定义注解和Spring Security的全局方法拦截实现，确保只有管理员可以访问敏感操作。角色管理界面与部分功能如图9、图10所示。
Figure 9. Role management interface
图9. 角色管理界面
Figure 10. Role modification/addition interface
图10. 角色修改/增加界面
(2) 控制面板：仅限系统管理员可以访问，通过本面板管理员可以实时监控系统数据总览并进行快速页面跳转。
(3) 消息管理：通过websocket实现的前后端实时通信，人工客服可以服务端通过消息管理功能即时回复顾客的问题，并对部分敏感或无效的消息进行删除等操作。
5. 系统测试
在本文银行智能语音客服系统开发投入使用前的最后一步，为了尽可能在各种不同的条件下运行系统，排除各种可能出现的错误，必须经过严格的测试，对系统中存在的缺陷和可能存在的问题进行分析，并提出相应的解决方案，将有助于提升其性能表现和稳定性，在实际应用中取得更强的产品竞争力。
本文分别对自然语言处理部分的功能接口和系统业务部分进行了以功能验证为核心的黑盒测试策略。首要的任务是对银行智能贷后系统各项核心功能逐一编制测试用例并开展实测，具体测试结果见表4：
Table 4. System function test case table
表4. 系统功能测试用例表
测试内容 |
测试步骤 |
预期结果 |
测试结果 |
本地模型调用接口 |
1. 启动后台系统 2. 使用postman编写请求 3. 组装并发送请求，检查后台响应 |
根据提示词的不同，模型会给出对应的答复 |
符合预期验证通过 |
本地知识库调用/RAG增强生成接口 |
1. 启动AnythingLLM框架 2. 导入规范化数据并训练 3. 询问模型各类专业术语和知识库中的独有内容 |
模型将根据本地知识库中的数据进行RAG检索生成回复，控制回答范围，降低幻觉发生率 |
符合预期验证通过 |
语音识别调用接口 |
1. 准备多方言测试音频 2. 模拟不同信噪比环境 3. 执行批量识别测试 |
普通话识别准确率 ≥ 90%，方言识别准确率 ≥ 75% |
符合预期验证通过 |
语音合成调用接口 |
1. 准备多样化文本输入 2. 测试不同语音风格 |
合成延迟 ≤ 180 s，合成出来的语音自然度MOS ≥ 4.2分，支持三种情感间的区分度 |
符合预期验证通过 |
个人信息修改 |
1. 登录系统 2. 点击个人中心修改信息 |
用户能够方便地修改个人的基本信息 |
符合预期验证通过 |
密码修改 |
1. 登录系统 2. 点击个人中心修改密码 |
当用户在文本框中正确输入旧密码并设置新密码后，密码修改操作即可成功完成。填写错误时，修改失败 |
符合预期验证通过 |
登录 |
1. 进入登录界面 2. 输入账号密码 |
当用户身份验证正确后，可以正常登录 |
符合预期验证通过 |
信息管理 |
1. 以人工客服身份登录 2. 与顾客分别进行文本语音对话 3. 删除对话 |
顾客和客服之间能实现较低延迟的实时语音或文字交流，客服能够删除聊天记录 |
符合预期验证通过 |
为了测试系统非功能需求的表现，对系统响应时间进行了综合测试，最终测试结果见表5：
Table 5. System response time test
表5. 系统响应时间测试
测试项目 |
性能测试 |
测试内容 |
系统平均响应时间测试 |
输入 |
用户名，密码，登录系统 |
操作 |
1. 输入登录人员个人信息登录系统 2. 根据业务流程进行相关操作，提交相关业务请求 |
预期结果 |
页面平均响应时间控制在3秒以内，最长等待时长不超过10秒 |
测试结果 |
未出现以上情况，平均响应时间控制在合理范围内，验证通过 |
6. 研究结论
本文围绕银行业务场景，构建了一套基于本地化大语言模型的智能语音客服系统，通过融合自然语言处理技术与金融专业知识，实现了高效、精准的智能金融服务。系统采用Ollama框架部署DeepSeek-R1模型作为核心引擎，结合AnythingLLM构建银行业务知识库，创新性地实现了专业领域知识的精准检索与生成。同时，整合阿里云语音识别和ChatTTS语音合成技术，形成了完整的智能语音交互闭环。测试结果表明，该银行智能语音助手系统在核心功能性能与知识响应准确性上均展现出良好表现：在知识生成层面，模型可依托本地知识库开展RAG检索并生成回复，有效控制回答范围的同时大幅降低了专业术语场景下的幻觉发生率，保障了金融业务咨询的信息准确性；在语音交互层面，系统对普通话的识别准确率达到90%以上，对多场景方言的识别准确率也不低于75%，能够适配不同用户的语音输入习惯，满足多样化沟通需求；在交互效率层面，页面平均响应时间控制在3秒以内，最长等待时长未超过10秒，可实现流畅的人机交互体验，避免用户因等待延迟产生使用障碍，为账户查询、转账咨询等银行业务的高效办理提供了稳定支撑。另外需要说明的是，本文所实现的系统在典型银行业务(如账户查询、转账)中已达到可用状态，但在涉及多轮复杂交易(如跨境汇款、投资组合调整)方面仍处于原型验证阶段，后续将结合业务逻辑细化与风险控制机制进一步完善。