尧图网页设计 
简介一份面向金融机构客服、运营及技术规划人员的AI大模型场景落地方案PPT针对人工成本高、多语种支撑弱、响应慢、知识更新滞后等客服痛点梳理了从算力平台搭建、模型蒸馏量化到多模态交互、智能语音语义理解、文档解析与视频核验等核心功能模块并给出风控合规与AB测试迭代路径。压缩包内为单个PPT体积仅1.11MB便于快速阅读和内部转培。目前已有60人浏览学习。内容按行业背景、技术架构、功能模块、应用案例、风险控制、价值评估六大部分组织既讲清技术与业务结合逻辑也包含了秒级高并发响应、情绪识别转人工、长尾市场覆盖等可参考的落地策略适合用来做金融客服智能化改造的汇报底稿或方案素材。1. AI大模型金融业客服场景先别急着上GPU集群先想清楚这三点金融业客服是AI大模型落地最扎实的场景之一原因很简单客服每天面对大量重复性问答人力成本高而且话术必须合规。但如果你以为买几块卡、部署一个开源模型就能把客服系统替换掉大概率会在第一周就翻车。我见过好几个团队拿着这个方向立项最后都卡在同一个地方——模型很会聊天但不懂金融业务更不会管客户情绪。金融客服场景要的不是一个聪明的AI而是一个懂规矩、不胡说、能对接工单系统的助手。所以这篇笔记我打算沿着选型、链路搭建、知识库检索、避坑到推理优化把一套能复现的最小方案拆开讲。适合谁看准备在金融业做客服智能化改造的从业者或者已经在跑POC但效果不理想的工程师。我会把参数、命令、踩坑点写清楚新手照着搭能跑通熟手可以直接参考边界条件。2. 金融客服场景下的大模型选型开源基座与微调路线的取舍2.1 选型维度知识密度、可控性与部署成本金融客服的大模型选型比通用场景多了一层约束你不能只追求回答质量还得保证回答在监管和业务规则内。我一般会从三个维度去卡。第一是知识密度。金融术语、产品规则、业务流程有大量专有表达比如代销赎回T1到账。通用模型可能知道基本概念但不了解你们银行的具体产品所以要么微调要么做检索增强。第二是可控性。客服回答如果出现幻觉说错一个利率或者担保条款后果不是扣分是投诉和合规风险。因此选型时我特别看重模型对指令的遵循度尤其是不知道时就说不清楚的能力。第三是部署成本。金融业对数据合规要求高很多机构不允许把对话数据发到外部API所以私有化部署是刚需。这就意味着你要考虑显存、推理延迟和运维成本不能只看模型榜单。2.2 三种常见路线通用API、私有化开源基座、垂直小模型我见过三种主流做法。第一种是直接调用通用大模型API比如市面上常见的对话接口。优点是见效快不需要自己买卡缺点是非私有化数据出域是个大问题而且API的接口语义未必贴合客服话术。第二种是用开源基座模型做私有化部署常见的有Qwen、Llama、ChatGLM系列。这条路能保证数据留在内网但需要你自己做指令微调或者用RAG把业务知识接进去。第三种是在开源基座的基础上做垂直小模型用金融客服对话语料继续训练得到参数量更小、专门用于客服的模型。这条路效果最好但需要优质训练数据一般团队没有那么多标注资源。我自己的判断是对于大多数金融客服项目与其纠结要不要全参数微调不如先用开源基座 检索增强 好的Prompt编排跑通主链路。先把80%的常规问答做好再根据badcase决定是否微调。因为微调的成本不只是训练机时还有持续的评测和模型迭代流程很多团队根本转不起来。2.3 我用下来的参数范围参考模型选型不是只看名字同一个模型的不同版本、不同量化方式效果和资源占用差很多。我常用的方案是7B到14B参数量的开源模型作为基座比如Qwen2.5-7B-Instruct或同级别的在16G显存的GPU上就能跑FP16推理如果压到INT8或者INT48G显存也能带得动但回答质量稍微降一点。推理参数上我默认设置如下temperature0.7top_p0.9max_tokens512。如果是需要精确输出的场景比如算利率、提取日期我会把temperature降到0.1甚至直接用贪心解码。注意temperature调低会让回答保守但也会让逻辑更稳定调高则会发散适合生成话术或解释。金融客服场景我一般不会超过0.7否则同样的问题每次回答不一样客户会觉得不靠谱。3. 把大模型接进客服系统最小可用的对话链路搭建3.1 总体架构知识库、检索增强与对话编排很多团队一开始就想做一个端到端的聊天机器人输入问题直接输出答案。但金融客服场景必须把知识库拉进来否则模型只会抖机灵不会给你准确的业务规则。常见做法是用户问题先过意图识别判断是查余额问利率还是投诉转人工然后进入检索模块从知识库中召回相关片段把片段和问题一起拼进Prompt最后让大模型基于Prompt生成回复。这整个链路可以放在一个FastAPI服务里也可以拆成微服务。我一般会用一个很朴素的编排方式先做关键词匹配的意图分类命中就直接走对应流程没命中就统一走RAG问答。这样避免了对话管理过于复杂又能快速覆盖高频问题。下面给一个最小可用的服务骨架。from flask import Flask, request, jsonify from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from transformers import AutoTokenizer, AutoModelForCausalLM import torch app Flask(__name__) # 加载向量库和模型实际项目中这些应在启动时完成 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_db FAISS.load_local(faiss_index, embeddings) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.float16).cuda() def build_prompt(query, context): system 你是一个金融客服助手请根据提供的参考内容回答问题不要编造信息。 content f参考内容\n{context}\n\n客户问题{query}\n请用简洁、专业的客服语气回答。 return [{role: system, content: system}, {role: user, content: content}] app.route(/chat, methods[POST]) def chat(): data request.get_json() query data.get(query) docs vector_db.similarity_search(query, k4) context \n.join([doc.page_content for doc in docs]) messages build_prompt(query, context) text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt).to(cuda) outputs model.generate(inputs.input_ids, max_new_tokens512, temperature0.7, top_p0.9) reply tokenizer.decode(outputs[0][inputs.input_ids.shape[-1]:], skip_special_tokensTrue) return jsonify({reply: reply}) app.run(host0.0.0.0, port8000)这段代码是一个最简通道。它在每次请求里做三件核心事用向量库检索出最相似的4个片段把片段和用户问题拼成Prompt调用模型生成回复。k4是召回条数太少容易漏信息太多会把不相关的噪声带进Prompt我自己一般试1到5之间。max_new_tokens512对于客服回复通常够用但如果你希望回答更详细可以加到1024代价是延迟增加。temperature0.7和top_p0.9是通用配置后面我会专门讲怎么调。3.2 用FastAPI包一个客服问答服务的最小实现Flask能跑但生产环境我更喜欢用FastAPI因为它自带异步和OpenAPI文档对接前端或者工单系统更舒服。下面这个版本把检索和生成拆成两个函数方便以后替换成独立服务。from fastapi import FastAPI from pydantic import BaseModel from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from transformers import AutoTokenizer, AutoModelForCausalLM import torch import uvicorn app FastAPI() class Query(BaseModel): message: str session_id: str None embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_db FAISS.load_local(faiss_index, embeddings) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.float16).cuda() def retrieve(query: str, k: int 4): docs vector_db.similarity_search(query, kk) return [doc.page_content for doc in docs] def generate_reply(query: str, context: list[str]) - str: ref \n.join(context) system 你是一个金融客服助手请根据提供的参考内容回答问题不要编造信息。 user f参考内容\n{ref}\n\n客户问题{query}\n请用简洁、专业的客服语气回答。 messages [{role: system, content: system}, {role: user, content: user}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt).to(cuda) outputs model.generate(inputs.input_ids, max_new_tokens512, temperature0.7, top_p0.9) return tokenizer.decode(outputs[0][inputs.input_ids.shape[-1]:], skip_special_tokensTrue) app.post(/chat) async def handle_query(query: Query): context retrieve(query.message) reply generate_reply(query.message, context) return {reply: reply, session_id: query.session_id} if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)这里把检索和生成分开好处是可以分别做缓存。比如同一个问题交给检索模块时命中相同片段就直接用缓存不用重新推理。另外session_id先占个位置后续你可以用它做多轮对话的上下文管理。注意这个最小实现还没做上下文拼接每轮都是独立问答。金融客服产品里如果客户说那利率呢你得上文才能知道那指什么所以多轮记忆是后面必须补的。3.3 调用大模型时的关键参数temperature、top_p、max_tokens很多翻车现场都是参数设置太随意。我先说结论客服场景里temperature的优先级最高。它控制的是生成的随机性0是纯贪心每次一模一样1是极度发散。法律、金融、医疗这类需要精确回答的我建议0.2以下。但也不是越低越好因为太低的temperature会让回答死板同一个句子翻来覆去。我的经验是0.3左右折中既能保证逻辑稳定又不会显得像复读机。top_p是核采样控制的是从累积概率阈值内采样。比如top_p0.9就是只从可能性最高的90%里选词。通常temperature和top_p不要同时调得太激进一般固定一个调另一个。我习惯固定top_p0.9用temperature来控制发散度。另外max_tokens决定了回复多长金融客服问答一般不超过200字但如果你要让模型解释一个复杂产品规则512是起步否则话没说完就被截断了。还有一个很容易被忽略的参数是repetition_penalty当客户重复问同一个问题或者模型卡在好的好的好的时把它调到1.1到1.3很管用。4. 金融知识库的构建与检索增强让模型不胡说八道4.1 知识库切分从产品文档到FAQ的清洗规则金融知识库的数据源多半是产品说明书、客服话术、FAQ、历史工单、监管条例。这些文档格式五花八门有的是PDF有的是Word还有的是网页里的表格。直接扔给Embedding模型效果会很差因为里面的表格、页眉页脚、多级标题都会污染向量。我一般会先做一轮清洗把页眉页脚去掉、把表格按行转为自然语言描述。举个例子一个定期存款利率表的表格我会转换成一年期定期存款年利率为1.9%起存金额为100元这样的句子才能被向量检索理解。清洗之后做切分这是知识库效果的分水岭。切分不是简单按字符数截断而是按语义块。我的规则是优先按自然段切每个文档块控制在200到400字。如果一段太长再按句子边界切保证不要把一个完整句子拆开。金融文本里有很多但和然而转折切在中间会让检索到的片段语义不完整模型看到一半以为结论是相反的这就是回答错误的直接原因。4.2 向量化与检索Embedding模型选型和相似度阈值Embedding模型的选择比大模型基座更重要因为检索的上限决定了模型能参考什么。我用的比较多的是BGE系列和M3E这类中文语料上表现较好的模型。BGE-large-zh-v1.5的向量维度是1024语义覆盖对金融场景的专有名词算友好。如果你更看重性能可以用bge-base维度少一半召回会弱一些但速度更快。把文档切块后用Embedding模型做向量化存入FAISS或Milvus。金融客服里我建议用FAISS做本地POC就够了真实并发要求高再上Milvus。检索时similarity_search默认返回相似度分数但你可以结合自己的业务决定阈值。比如相似度低于0.75的我建议直接告诉用户我需要转人工不要硬答。因为低相似度意味着知识库里没有可靠依据强行生成等同于编造。这个阈值要观察数据分布后确定一开始0.75放进去统计查询日志把那些低分但答对的case找出来微调阈值。# 检查相似度分数的示例 query_text 定期存款到期后会自动转存吗 results vector_db.similarity_search_with_score(query_text, k4) for doc, score in results: print(fscore{score:.4f}, content{doc.page_content[:50]})这段代码告诉你每一条检索结果的分数范围。正常来说命中的片段分数应该在0.8以上如果你看到大量0.6以下的结果有三种可能知识库切分太碎、Embedding模型不匹配语料、或者查询里带了太多口语化噪声。我见过一种常见错误——把我要投诉你们服务态度差这种情绪化表达直接送去做检索和知识库里的产品文档完全不沾边分数低很自然。所以预处理阶段最好先做一次意图分类把情绪化表达分流到人工别去检索。4.3 把检索结果拼进Prompt的模板写法Prompt模板是很多人最忽略的一环。同样的检索结果模板写法不同效果天差地别。我会遵循一个简单原则先给角色再给参考再给问题最后给输出约束。角色是金融客服助手参考内容里如果有多段用标记分好问题放在后面最后强调如果参考内容不足以回答问题请回复转人工客服处理。这个明确的兜底指令比让模型自己判断重要得多。一个我踩过坑的细节不要把所有检索结果都塞进去。检索到的4段里可能2段是相关2段是沾边但不准确的模型会把不准确的也当依据。所以最好对检索结果做一个重排序或过滤。没有重排条件时我通常会把那4段按分数排序只取前2段作为Prompt引用避免噪声干扰。另外参考内容之间要换行分隔而且要在每段前标注编号让模型能明确引用第几段。5. 大模型客服场景的5个常见翻车点与排查方法作为一线踩坑者我把日常最多遇到的5个问题写成现象→原因→解决希望能帮大家省点试错时间。5.1 现象模型答非所问检索没生效检索没生效往往不是代码报错而是助手的回答和参考内容完全无关。你以为你加了RAG实际模型根本没有用到检索片段或者检索出来的片段本身不相关。我遇到过最离谱的一次是向量库加载错了模型一直在拿另一个知识库的内容硬答看起来很有道理但完全不是本银行的产品。原因多半是Embedding模型在不同语言/领域上不一致或者是向量库索引没有加载到最新版本。解决先单独打印出检索结果的score和content看是否命中再检查FAISS索引路径是否和生成时的知识库一致最后确认查询是否经过了同一种清洗逻辑。如果这些都对了但模型还是不参考试着在Prompt里加强请严格基于以下参考内容这种强约束句式。5.2 现象回答语气不像客服反而像百科模型用词书面化尊敬的客户变成阁下您说得对变成根据现有政策这种问题特别常见。原因是模型的指令风格里没有注入客服角色特征或者微调数据里缺少口语化问答。解决的办法不需要微调而是调整System Prompt。我会给一段明确的语气样本比如你是银行的在线客服语气亲切、专业每句话不超过30个字避免使用然而综上所述等书面用语。有时候加一个你是一个经常在微信上和客户闲聊的客服姐姐这类人设效果会更自然。5.3 现象同一问题每次答案都不一样temperature设得太高是头号原因。客户问你理财起购金额是多少你第一次答1万元第二次答起购金额为人民币1万元虽然内容一样但客户会觉得AI不稳定。更严重的是有些模型在temperature0.9时会生成完全不同的产品条款解释。我的解决方法是把temperature降到0.1并且设置固定随机种子。同时把do_sampleFalse直接贪心解码这样同一个问题在相同检索结果下一定输出同一句话。代价是多样性消失但对金融场景这是应该的。5.4 现象涉及金额/利率计算时算错大模型本质上不擅长数学尤其是利息计算、分期手续费这种需要精确公式的场景。我见过不少团队以为RAG能解决一切结果模型照着年利率3.5%存10万一年算出3501元的例子。原因在于模型只是从知识库里检索了一个利率值然后自己拿这个值去乘乘法看似简单但语言模型的逐token解码容易在进位时出错。解决这个问题的标准套路是在意图识别阶段判断这类问题属于计算类然后不要用大模型计算结果而是用规则或者Python代码算大模型只负责组织和解释。我的做法是做一个简单的calculate_interest函数用正规公式算完再让模型基于计算结果组织话术。计算逻辑永远不交给模型这是一个铁律。5.5 现象GPU显存不够推理延迟高显存不够是最常见的物理限制。7B模型FP16大概需要14GB显存加上KV cache和中间状态一张16G的显卡勉强能跑但并发一高就容易OOM。你说你有32G内存能装AI大模型这是真的但内存不是显存CPU推理慢得让人崩溃。我的建议是如果你只有普通电脑没有独立大显存显卡那就老老实实选用量化模型。比如把7B量化到INT4显存占用可以压到6~7GB消费级显卡能跑。但延迟和并发能力还是有限生产环境最少要两张24G的卡才敢接真实流量。排查时先用nvidia-smi看显存占用再用torch.cuda.max_memory_allocated看模型峰值占用。如果峰值接近上限先关掉torch.inference_mode()之外的内存优化再考虑开启flash_attention和KV cache的量化。如果延迟超过3秒多半是模型太大或者输入太长试试减小max_new_tokens或做流式输出。6. 把模型压到能用的一个技巧量化推理与流式输出的取舍前几章把链路和坑都讲透了最后说一个最常见的工程优化技巧把模型量化到INT4再配合流式输出。很多人担心量化后效果会断崖式下降但金融客服场景里主要是检索增强后的答案生成模型对单字的敏感度没那么高量化后我实测人工评测的准确率只差2到3个百分点但显存占用和推理速度都有明显改善这个性价比非常高。我用的是AutoGPTQ或llama.cpp的方式做量化。如果你用的是HuggingFace Transformers生态可以这样加载INT4模型from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, quantization_configquantization_config, device_mapauto )这段配置里bnb_4bit_compute_dtypetorch.float16是为了保持计算精度虽然权重是4bit但会反量化到FP16做矩阵计算速度比纯FP16快一些。bnb_4bit_quant_typenf4是NF4量化比原始的4bit更稳定对越大的模型效果越好。use_double_quant进一步压缩量化常数显存省得更多但会增加一点推理耗时。如果显存仍然紧张可以关掉device_mapauto手动指定GPU。然后是流式输出。客服场景里如果等模型生成完一整段再回复体验上往往要等两三秒甚至更久。流式输出把生成过程变成逐字推送用户感觉响应很快。实现不算复杂可以用TextIteratorStreamer配合一个后台线程。from transformers import TextIteratorStreamer from threading import Thread streamer TextIteratorStreamer(tokenizer, skip_promptTrue, skip_special_tokensTrue) generation_kwargs dict( inputsinputs.input_ids, max_new_tokens512, temperature0.3, top_p0.9, streamerstreamer, ) thread Thread(targetmodel.generate, kwargsgeneration_kwargs) thread.start() for text in streamer: print(text, end, flushTrue)流式输出的代价是Token生成速度可能比批量模式慢一点点但感知体验提升很大。我自己的习惯是对超高频的固定问答比如查利率、查营业时间我会做一层缓存完全不走模型对复杂追问才走完整的RAG流式生成。这样用一个7B量化模型就能顶住日常客服压力。最后说我的一个教训。一开始我把temperature设成0.9觉得客服要有亲切感结果上线后客户发现每次回答都不一样差评很多。后来全部切成温度0.3量化流式效果反而明显好。原因是金融客户要的是稳定和可预期不是你发挥创意。希望这个踩坑经验能帮你的客服项目少走弯路也希望这套方案能在你的金融机构里真正落地、变成能用的系统。祝你顺利。本文还有配套的精品资源点击获取 AI大模型金融客服落地：选型、RAG与推理优化实践
简介一份面向金融机构客服、运营及技术规划人员的AI大模型场景落地方案PPT针对人工成本高、多语种支撑弱、响应慢、知识更新滞后等客服痛点梳理了从算力平台搭建、模型蒸馏量化到多模态交互、智能语音语义理解、文档解析与视频核验等核心功能模块并给出风控合规与AB测试迭代路径。压缩包内为单个PPT体积仅1.11MB便于快速阅读和内部转培。目前已有60人浏览学习。内容按行业背景、技术架构、功能模块、应用案例、风险控制、价值评估六大部分组织既讲清技术与业务结合逻辑也包含了秒级高并发响应、情绪识别转人工、长尾市场覆盖等可参考的落地策略适合用来做金融客服智能化改造的汇报底稿或方案素材。1. AI大模型金融业客服场景先别急着上GPU集群先想清楚这三点金融业客服是AI大模型落地最扎实的场景之一原因很简单客服每天面对大量重复性问答人力成本高而且话术必须合规。但如果你以为买几块卡、部署一个开源模型就能把客服系统替换掉大概率会在第一周就翻车。我见过好几个团队拿着这个方向立项最后都卡在同一个地方——模型很会聊天但不懂金融业务更不会管客户情绪。金融客服场景要的不是一个聪明的AI而是一个懂规矩、不胡说、能对接工单系统的助手。所以这篇笔记我打算沿着选型、链路搭建、知识库检索、避坑到推理优化把一套能复现的最小方案拆开讲。适合谁看准备在金融业做客服智能化改造的从业者或者已经在跑POC但效果不理想的工程师。我会把参数、命令、踩坑点写清楚新手照着搭能跑通熟手可以直接参考边界条件。2. 金融客服场景下的大模型选型开源基座与微调路线的取舍2.1 选型维度知识密度、可控性与部署成本金融客服的大模型选型比通用场景多了一层约束你不能只追求回答质量还得保证回答在监管和业务规则内。我一般会从三个维度去卡。第一是知识密度。金融术语、产品规则、业务流程有大量专有表达比如代销赎回T1到账。通用模型可能知道基本概念但不了解你们银行的具体产品所以要么微调要么做检索增强。第二是可控性。客服回答如果出现幻觉说错一个利率或者担保条款后果不是扣分是投诉和合规风险。因此选型时我特别看重模型对指令的遵循度尤其是不知道时就说不清楚的能力。第三是部署成本。金融业对数据合规要求高很多机构不允许把对话数据发到外部API所以私有化部署是刚需。这就意味着你要考虑显存、推理延迟和运维成本不能只看模型榜单。2.2 三种常见路线通用API、私有化开源基座、垂直小模型我见过三种主流做法。第一种是直接调用通用大模型API比如市面上常见的对话接口。优点是见效快不需要自己买卡缺点是非私有化数据出域是个大问题而且API的接口语义未必贴合客服话术。第二种是用开源基座模型做私有化部署常见的有Qwen、Llama、ChatGLM系列。这条路能保证数据留在内网但需要你自己做指令微调或者用RAG把业务知识接进去。第三种是在开源基座的基础上做垂直小模型用金融客服对话语料继续训练得到参数量更小、专门用于客服的模型。这条路效果最好但需要优质训练数据一般团队没有那么多标注资源。我自己的判断是对于大多数金融客服项目与其纠结要不要全参数微调不如先用开源基座 检索增强 好的Prompt编排跑通主链路。先把80%的常规问答做好再根据badcase决定是否微调。因为微调的成本不只是训练机时还有持续的评测和模型迭代流程很多团队根本转不起来。2.3 我用下来的参数范围参考模型选型不是只看名字同一个模型的不同版本、不同量化方式效果和资源占用差很多。我常用的方案是7B到14B参数量的开源模型作为基座比如Qwen2.5-7B-Instruct或同级别的在16G显存的GPU上就能跑FP16推理如果压到INT8或者INT48G显存也能带得动但回答质量稍微降一点。推理参数上我默认设置如下temperature0.7top_p0.9max_tokens512。如果是需要精确输出的场景比如算利率、提取日期我会把temperature降到0.1甚至直接用贪心解码。注意temperature调低会让回答保守但也会让逻辑更稳定调高则会发散适合生成话术或解释。金融客服场景我一般不会超过0.7否则同样的问题每次回答不一样客户会觉得不靠谱。3. 把大模型接进客服系统最小可用的对话链路搭建3.1 总体架构知识库、检索增强与对话编排很多团队一开始就想做一个端到端的聊天机器人输入问题直接输出答案。但金融客服场景必须把知识库拉进来否则模型只会抖机灵不会给你准确的业务规则。常见做法是用户问题先过意图识别判断是查余额问利率还是投诉转人工然后进入检索模块从知识库中召回相关片段把片段和问题一起拼进Prompt最后让大模型基于Prompt生成回复。这整个链路可以放在一个FastAPI服务里也可以拆成微服务。我一般会用一个很朴素的编排方式先做关键词匹配的意图分类命中就直接走对应流程没命中就统一走RAG问答。这样避免了对话管理过于复杂又能快速覆盖高频问题。下面给一个最小可用的服务骨架。from flask import Flask, request, jsonify from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from transformers import AutoTokenizer, AutoModelForCausalLM import torch app Flask(__name__) # 加载向量库和模型实际项目中这些应在启动时完成 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_db FAISS.load_local(faiss_index, embeddings) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.float16).cuda() def build_prompt(query, context): system 你是一个金融客服助手请根据提供的参考内容回答问题不要编造信息。 content f参考内容\n{context}\n\n客户问题{query}\n请用简洁、专业的客服语气回答。 return [{role: system, content: system}, {role: user, content: content}] app.route(/chat, methods[POST]) def chat(): data request.get_json() query data.get(query) docs vector_db.similarity_search(query, k4) context \n.join([doc.page_content for doc in docs]) messages build_prompt(query, context) text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt).to(cuda) outputs model.generate(inputs.input_ids, max_new_tokens512, temperature0.7, top_p0.9) reply tokenizer.decode(outputs[0][inputs.input_ids.shape[-1]:], skip_special_tokensTrue) return jsonify({reply: reply}) app.run(host0.0.0.0, port8000)这段代码是一个最简通道。它在每次请求里做三件核心事用向量库检索出最相似的4个片段把片段和用户问题拼成Prompt调用模型生成回复。k4是召回条数太少容易漏信息太多会把不相关的噪声带进Prompt我自己一般试1到5之间。max_new_tokens512对于客服回复通常够用但如果你希望回答更详细可以加到1024代价是延迟增加。temperature0.7和top_p0.9是通用配置后面我会专门讲怎么调。3.2 用FastAPI包一个客服问答服务的最小实现Flask能跑但生产环境我更喜欢用FastAPI因为它自带异步和OpenAPI文档对接前端或者工单系统更舒服。下面这个版本把检索和生成拆成两个函数方便以后替换成独立服务。from fastapi import FastAPI from pydantic import BaseModel from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from transformers import AutoTokenizer, AutoModelForCausalLM import torch import uvicorn app FastAPI() class Query(BaseModel): message: str session_id: str None embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_db FAISS.load_local(faiss_index, embeddings) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.float16).cuda() def retrieve(query: str, k: int 4): docs vector_db.similarity_search(query, kk) return [doc.page_content for doc in docs] def generate_reply(query: str, context: list[str]) - str: ref \n.join(context) system 你是一个金融客服助手请根据提供的参考内容回答问题不要编造信息。 user f参考内容\n{ref}\n\n客户问题{query}\n请用简洁、专业的客服语气回答。 messages [{role: system, content: system}, {role: user, content: user}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt).to(cuda) outputs model.generate(inputs.input_ids, max_new_tokens512, temperature0.7, top_p0.9) return tokenizer.decode(outputs[0][inputs.input_ids.shape[-1]:], skip_special_tokensTrue) app.post(/chat) async def handle_query(query: Query): context retrieve(query.message) reply generate_reply(query.message, context) return {reply: reply, session_id: query.session_id} if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)这里把检索和生成分开好处是可以分别做缓存。比如同一个问题交给检索模块时命中相同片段就直接用缓存不用重新推理。另外session_id先占个位置后续你可以用它做多轮对话的上下文管理。注意这个最小实现还没做上下文拼接每轮都是独立问答。金融客服产品里如果客户说那利率呢你得上文才能知道那指什么所以多轮记忆是后面必须补的。3.3 调用大模型时的关键参数temperature、top_p、max_tokens很多翻车现场都是参数设置太随意。我先说结论客服场景里temperature的优先级最高。它控制的是生成的随机性0是纯贪心每次一模一样1是极度发散。法律、金融、医疗这类需要精确回答的我建议0.2以下。但也不是越低越好因为太低的temperature会让回答死板同一个句子翻来覆去。我的经验是0.3左右折中既能保证逻辑稳定又不会显得像复读机。top_p是核采样控制的是从累积概率阈值内采样。比如top_p0.9就是只从可能性最高的90%里选词。通常temperature和top_p不要同时调得太激进一般固定一个调另一个。我习惯固定top_p0.9用temperature来控制发散度。另外max_tokens决定了回复多长金融客服问答一般不超过200字但如果你要让模型解释一个复杂产品规则512是起步否则话没说完就被截断了。还有一个很容易被忽略的参数是repetition_penalty当客户重复问同一个问题或者模型卡在好的好的好的时把它调到1.1到1.3很管用。4. 金融知识库的构建与检索增强让模型不胡说八道4.1 知识库切分从产品文档到FAQ的清洗规则金融知识库的数据源多半是产品说明书、客服话术、FAQ、历史工单、监管条例。这些文档格式五花八门有的是PDF有的是Word还有的是网页里的表格。直接扔给Embedding模型效果会很差因为里面的表格、页眉页脚、多级标题都会污染向量。我一般会先做一轮清洗把页眉页脚去掉、把表格按行转为自然语言描述。举个例子一个定期存款利率表的表格我会转换成一年期定期存款年利率为1.9%起存金额为100元这样的句子才能被向量检索理解。清洗之后做切分这是知识库效果的分水岭。切分不是简单按字符数截断而是按语义块。我的规则是优先按自然段切每个文档块控制在200到400字。如果一段太长再按句子边界切保证不要把一个完整句子拆开。金融文本里有很多但和然而转折切在中间会让检索到的片段语义不完整模型看到一半以为结论是相反的这就是回答错误的直接原因。4.2 向量化与检索Embedding模型选型和相似度阈值Embedding模型的选择比大模型基座更重要因为检索的上限决定了模型能参考什么。我用的比较多的是BGE系列和M3E这类中文语料上表现较好的模型。BGE-large-zh-v1.5的向量维度是1024语义覆盖对金融场景的专有名词算友好。如果你更看重性能可以用bge-base维度少一半召回会弱一些但速度更快。把文档切块后用Embedding模型做向量化存入FAISS或Milvus。金融客服里我建议用FAISS做本地POC就够了真实并发要求高再上Milvus。检索时similarity_search默认返回相似度分数但你可以结合自己的业务决定阈值。比如相似度低于0.75的我建议直接告诉用户我需要转人工不要硬答。因为低相似度意味着知识库里没有可靠依据强行生成等同于编造。这个阈值要观察数据分布后确定一开始0.75放进去统计查询日志把那些低分但答对的case找出来微调阈值。# 检查相似度分数的示例 query_text 定期存款到期后会自动转存吗 results vector_db.similarity_search_with_score(query_text, k4) for doc, score in results: print(fscore{score:.4f}, content{doc.page_content[:50]})这段代码告诉你每一条检索结果的分数范围。正常来说命中的片段分数应该在0.8以上如果你看到大量0.6以下的结果有三种可能知识库切分太碎、Embedding模型不匹配语料、或者查询里带了太多口语化噪声。我见过一种常见错误——把我要投诉你们服务态度差这种情绪化表达直接送去做检索和知识库里的产品文档完全不沾边分数低很自然。所以预处理阶段最好先做一次意图分类把情绪化表达分流到人工别去检索。4.3 把检索结果拼进Prompt的模板写法Prompt模板是很多人最忽略的一环。同样的检索结果模板写法不同效果天差地别。我会遵循一个简单原则先给角色再给参考再给问题最后给输出约束。角色是金融客服助手参考内容里如果有多段用标记分好问题放在后面最后强调如果参考内容不足以回答问题请回复转人工客服处理。这个明确的兜底指令比让模型自己判断重要得多。一个我踩过坑的细节不要把所有检索结果都塞进去。检索到的4段里可能2段是相关2段是沾边但不准确的模型会把不准确的也当依据。所以最好对检索结果做一个重排序或过滤。没有重排条件时我通常会把那4段按分数排序只取前2段作为Prompt引用避免噪声干扰。另外参考内容之间要换行分隔而且要在每段前标注编号让模型能明确引用第几段。5. 大模型客服场景的5个常见翻车点与排查方法作为一线踩坑者我把日常最多遇到的5个问题写成现象→原因→解决希望能帮大家省点试错时间。5.1 现象模型答非所问检索没生效检索没生效往往不是代码报错而是助手的回答和参考内容完全无关。你以为你加了RAG实际模型根本没有用到检索片段或者检索出来的片段本身不相关。我遇到过最离谱的一次是向量库加载错了模型一直在拿另一个知识库的内容硬答看起来很有道理但完全不是本银行的产品。原因多半是Embedding模型在不同语言/领域上不一致或者是向量库索引没有加载到最新版本。解决先单独打印出检索结果的score和content看是否命中再检查FAISS索引路径是否和生成时的知识库一致最后确认查询是否经过了同一种清洗逻辑。如果这些都对了但模型还是不参考试着在Prompt里加强请严格基于以下参考内容这种强约束句式。5.2 现象回答语气不像客服反而像百科模型用词书面化尊敬的客户变成阁下您说得对变成根据现有政策这种问题特别常见。原因是模型的指令风格里没有注入客服角色特征或者微调数据里缺少口语化问答。解决的办法不需要微调而是调整System Prompt。我会给一段明确的语气样本比如你是银行的在线客服语气亲切、专业每句话不超过30个字避免使用然而综上所述等书面用语。有时候加一个你是一个经常在微信上和客户闲聊的客服姐姐这类人设效果会更自然。5.3 现象同一问题每次答案都不一样temperature设得太高是头号原因。客户问你理财起购金额是多少你第一次答1万元第二次答起购金额为人民币1万元虽然内容一样但客户会觉得AI不稳定。更严重的是有些模型在temperature0.9时会生成完全不同的产品条款解释。我的解决方法是把temperature降到0.1并且设置固定随机种子。同时把do_sampleFalse直接贪心解码这样同一个问题在相同检索结果下一定输出同一句话。代价是多样性消失但对金融场景这是应该的。5.4 现象涉及金额/利率计算时算错大模型本质上不擅长数学尤其是利息计算、分期手续费这种需要精确公式的场景。我见过不少团队以为RAG能解决一切结果模型照着年利率3.5%存10万一年算出3501元的例子。原因在于模型只是从知识库里检索了一个利率值然后自己拿这个值去乘乘法看似简单但语言模型的逐token解码容易在进位时出错。解决这个问题的标准套路是在意图识别阶段判断这类问题属于计算类然后不要用大模型计算结果而是用规则或者Python代码算大模型只负责组织和解释。我的做法是做一个简单的calculate_interest函数用正规公式算完再让模型基于计算结果组织话术。计算逻辑永远不交给模型这是一个铁律。5.5 现象GPU显存不够推理延迟高显存不够是最常见的物理限制。7B模型FP16大概需要14GB显存加上KV cache和中间状态一张16G的显卡勉强能跑但并发一高就容易OOM。你说你有32G内存能装AI大模型这是真的但内存不是显存CPU推理慢得让人崩溃。我的建议是如果你只有普通电脑没有独立大显存显卡那就老老实实选用量化模型。比如把7B量化到INT4显存占用可以压到6~7GB消费级显卡能跑。但延迟和并发能力还是有限生产环境最少要两张24G的卡才敢接真实流量。排查时先用nvidia-smi看显存占用再用torch.cuda.max_memory_allocated看模型峰值占用。如果峰值接近上限先关掉torch.inference_mode()之外的内存优化再考虑开启flash_attention和KV cache的量化。如果延迟超过3秒多半是模型太大或者输入太长试试减小max_new_tokens或做流式输出。6. 把模型压到能用的一个技巧量化推理与流式输出的取舍前几章把链路和坑都讲透了最后说一个最常见的工程优化技巧把模型量化到INT4再配合流式输出。很多人担心量化后效果会断崖式下降但金融客服场景里主要是检索增强后的答案生成模型对单字的敏感度没那么高量化后我实测人工评测的准确率只差2到3个百分点但显存占用和推理速度都有明显改善这个性价比非常高。我用的是AutoGPTQ或llama.cpp的方式做量化。如果你用的是HuggingFace Transformers生态可以这样加载INT4模型from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, quantization_configquantization_config, device_mapauto )这段配置里bnb_4bit_compute_dtypetorch.float16是为了保持计算精度虽然权重是4bit但会反量化到FP16做矩阵计算速度比纯FP16快一些。bnb_4bit_quant_typenf4是NF4量化比原始的4bit更稳定对越大的模型效果越好。use_double_quant进一步压缩量化常数显存省得更多但会增加一点推理耗时。如果显存仍然紧张可以关掉device_mapauto手动指定GPU。然后是流式输出。客服场景里如果等模型生成完一整段再回复体验上往往要等两三秒甚至更久。流式输出把生成过程变成逐字推送用户感觉响应很快。实现不算复杂可以用TextIteratorStreamer配合一个后台线程。from transformers import TextIteratorStreamer from threading import Thread streamer TextIteratorStreamer(tokenizer, skip_promptTrue, skip_special_tokensTrue) generation_kwargs dict( inputsinputs.input_ids, max_new_tokens512, temperature0.3, top_p0.9, streamerstreamer, ) thread Thread(targetmodel.generate, kwargsgeneration_kwargs) thread.start() for text in streamer: print(text, end, flushTrue)流式输出的代价是Token生成速度可能比批量模式慢一点点但感知体验提升很大。我自己的习惯是对超高频的固定问答比如查利率、查营业时间我会做一层缓存完全不走模型对复杂追问才走完整的RAG流式生成。这样用一个7B量化模型就能顶住日常客服压力。最后说我的一个教训。一开始我把temperature设成0.9觉得客服要有亲切感结果上线后客户发现每次回答都不一样差评很多。后来全部切成温度0.3量化流式效果反而明显好。原因是金融客户要的是稳定和可预期不是你发挥创意。希望这个踩坑经验能帮你的客服项目少走弯路也希望这套方案能在你的金融机构里真正落地、变成能用的系统。祝你顺利。本文还有配套的精品资源点击获取