1. 从信贷风控的痛点说起为什么我要啃下这块硬骨头去年底接了个活儿帮一家城商行做信贷审批辅助系统的智能化改造。对方的需求很直接客户经理每天要处理上百份贷款申请材料从营业执照、银行流水、征信报告到财务报表光是把这些材料里的关键信息摘出来填进风控系统就要耗掉大半天。更头疼的是人工录入难免出错有时候把“年收入”看成了“月收入”后面整个授信额度算出来就是错的。他们问我能不能用大模型加RAG搞一套东西让机器先把材料读一遍自动提取关键字段再根据行里现行的信贷政策给出初步的风险判断。这个需求听起来简单但真动手做起来坑比我想象的多得多。金融信贷这个场景跟一般的知识问答完全不是一回事——它对准确性要求极高容错率极低而且每一笔判断都要能追溯到具体的政策条款和原始材料。我前后试了三套方案从纯提示词工程到本地知识库最后落到了华为云AgentArts上。这套东西最吸引我的地方在于它把智能体的工作流编排、RAG知识库、工具调用这几块能力整合到了一个平台上不用自己从零搭LangChain那套东西省了很多胶水代码的功夫。这篇笔记就是把我这段时间踩过的坑、试过的参数、跑通的流程完整记录下来。如果你也在做金融信贷方向的AI智能体或者对AgentArts这个平台感兴趣想看看它在真实业务场景里到底能不能打那这篇内容应该能帮你省下不少试错的时间。我会从整体设计思路讲到具体的节点配置再到RAG知识库的搭建和调优最后把我在实操中遇到的典型问题和排查方法一并整理出来。内容偏实战代码和配置会尽量给全但更重要的是把“为什么这么选”的逻辑讲清楚。2. 整体方案设计为什么选AgentArts而不是自己搭2.1 金融信贷场景对智能体的三个硬约束在动手选型之前我先把金融信贷这个场景对AI智能体的约束条件列了出来。第一个约束是可解释性。信贷审批不是聊天不能给个“我觉得这笔贷款风险较高”就完事了。每一笔判断都必须能说清楚依据的是哪条政策、哪个字段触发了预警、置信度是多少。这意味着智能体的每一步推理过程都要留痕不能是个黑盒。第二个约束是数据隔离。银行的客户材料涉及大量敏感信息不可能传到公网大模型上去处理。所以整个方案必须支持私有化部署或者至少能保证数据在传输和处理过程中不出企业边界。这也是我一开始考虑本地部署开源模型的原因但后来发现效果和成本很难平衡。第三个约束是流程可控。信贷审批有固定的流程材料接收→信息提取→资质核验→风险评估→额度测算→审批意见生成。智能体不能跳步也不能随意发挥必须严格按照这个流程走。这就要求智能体框架支持工作流编排而不是简单的对话链。2.2 AgentArts在信贷场景的适配性分析华为云AgentArts吸引我的第一个点是它的工作流编排能力。它把智能体的执行过程拆成了一个个节点每个节点可以是LLM调用、知识库检索、代码执行或者条件判断。这种设计天然适合信贷审批这种流程固定的场景——我可以把每个审批步骤做成一个节点节点之间的流转条件用代码写死LLM只在需要理解和生成的地方介入。第二个点是RAG知识库的原生支持。AgentArts内置了知识库管理功能支持上传文档、自动切片、向量化存储和检索。对于信贷场景来说这意味着我可以把行里的信贷政策、产品说明书、风险指引全部灌进去智能体在判断时自动检索相关条款作为依据。而且它支持在检索结果中标注来源这对可解释性要求极高的金融场景来说太关键了。第三个点是工具调用的灵活性。信贷审批过程中需要调用外部系统比如查询征信接口、计算器、额度测算模型等。AgentArts支持自定义工具我可以把行里现有的API封装成工具节点让智能体在需要的时候调用。这样既复用了现有系统又不用把敏感数据暴露给大模型。当然也有取舍。AgentArts目前对自定义模型的支持不如一些开源框架灵活如果你要用自己微调的模型可能需要做一些适配工作。另外它的知识库切片策略是平台预设的虽然可以调参数但不如自己写代码那么自由。不过对于大多数信贷场景来说这些限制在可接受范围内。2.3 整体架构与数据流向整个方案的架构分三层。最底层是数据层包括信贷政策文档、产品说明书、历史审批案例这些经过清洗后灌入AgentArts的知识库。中间是智能体层在AgentArts上搭建一个主智能体内部包含材料解析、信息提取、政策检索、风险评估、额度测算、意见生成六个核心节点。最上层是应用层通过API对接行里现有的信贷系统客户经理上传材料后触发智能体执行结果回写到业务系统。数据流向是这样的客户经理上传贷款申请材料PDF或图片→ 材料解析节点调用OCR工具提取文本 → 信息提取节点用LLM从文本中抽取关键字段企业名称、营收、负债率等→ 政策检索节点根据企业类型和贷款品种从知识库中召回相关条款 → 风险评估节点结合提取的字段和召回的政策做综合判断 → 额度测算节点调用行内额度模型计算建议授信额度 → 意见生成节点汇总所有信息生成审批意见 → 结果回写业务系统。整个流程中LLM只在信息提取、风险评估和意见生成三个节点介入其他节点都是确定性的代码逻辑。这样设计的好处是关键的风险判断有政策条款作为依据不是LLM凭空生成的同时流程可控不会出现智能体自己“加戏”的情况。3. 核心节点拆解与实操配置3.1 材料解析节点OCR与文本清洗的细节材料解析是整个流程的第一步也是最容易被低估的一步。我一开始觉得OCR嘛调个接口就完事了结果实际跑下来发现银行材料格式五花八门有扫描件、有照片、有PDF还有客户手写的补充说明。如果这一步的文本质量不过关后面LLM提取信息的准确率会断崖式下跌。在AgentArts里材料解析节点我配置了两个工具一个OCR工具和一个文本清洗工具。OCR工具用的是华为云OCR服务支持表格识别和手写体识别。这里有个细节要注意表格识别一定要开启因为银行流水和财务报表都是表格形式如果按普通文本识别行列关系会丢失后面LLM根本没法正确提取数字。文本清洗工具是我自己写的一段Python代码主要做三件事去除OCR产生的乱码字符、统一数字格式比如把“1,000,000”和“100万”都转成“1000000”、按段落切分并标注来源页码。这段代码不复杂但很关键。我试过不做清洗直接丢给LLM提取准确率大概只有70%左右清洗后能到92%以上。import re def clean_ocr_text(raw_text): # 去除常见OCR乱码 text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9.,。、()%\-/], , raw_text) # 统一数字格式 text re.sub(r(\d),(\d{3}), r\1\2, text) text text.replace(万元, 0000).replace(亿元, 00000000) # 按段落切分 paragraphs [p.strip() for p in text.split(\n) if len(p.strip()) 10] return paragraphs注意文本清洗不要过度有些看似乱码的字符可能是客户手写的特殊标记过度清洗会丢失信息。我的做法是保留原始文本清洗后的文本作为LLM输入原始文本存档备查。3.2 信息提取节点提示词设计与字段校验信息提取节点是整个智能体里提示词最讲究的地方。信贷审批需要提取的字段有二十多个包括企业基本信息、财务数据、征信记录、担保信息等。如果把这些字段全部塞进一个提示词里让LLM一次性提取准确率会明显下降而且一旦某个字段提取错误很难定位是哪个环节出了问题。我的做法是分组提取。把字段分成四组基本信息组企业名称、统一社会信用代码、成立日期等、财务数据组营收、利润、负债率、现金流等、征信信息组逾期记录、对外担保、涉诉情况等、申请信息组贷款金额、期限、用途、担保方式等。每组用一个独立的LLM调用提示词里明确列出该组需要提取的字段和格式要求。提示词的结构是这样的先给LLM一个角色设定“你是一名资深信贷审批专员”然后给出待提取的字段列表和每个字段的格式要求比如“营收”字段要求输出纯数字单位为元接着把清洗后的文本按段落传入最后要求LLM以JSON格式输出结果。这里有个技巧在提示词里加入一个示例展示输入文本和对应的JSON输出LLM的提取准确率会明显提升。字段校验是在LLM提取之后做的。我写了一个校验函数检查每个字段是否符合预期格式比如数字字段是否真的是数字、日期字段是否在合理范围内、必填字段是否为空。校验不通过的字段会触发一次重试把校验错误信息反馈给LLM让它重新提取。实测下来一次重试能解决80%以上的格式错误。3.3 政策检索节点RAG知识库的搭建与调优政策检索节点是RAG知识库真正发挥作用的地方。我把行里的信贷政策文件、产品说明书、风险指引、监管要求等文档全部上传到AgentArts的知识库中。上传之前做了一轮清洗去掉页眉页脚、合并跨页表格、给每个章节加上层级标题。这些预处理工作看起来琐碎但对检索效果影响很大。知识库的切片策略我调了好几次。默认的切片大小是512个token重叠128个token。但在信贷政策文档里很多条款是跨段落的比如“第五条 借款人的准入条件”下面跟着好几个子条款如果按默认切片很可能把一条完整的政策切到两个片段里。我的做法是把切片大小调到1024个token重叠调到256个token同时在切片时保留章节标题作为元数据。这样检索出来的片段自带上下文LLM更容易理解。检索策略用的是混合检索向量检索加关键词检索各取前10个结果然后用RRF倒数排名融合算法合并排序取前5个作为最终召回结果。纯向量检索在信贷场景下有个问题有些专业术语比如“拨备覆盖率”“资本充足率”的向量表示很接近容易混淆。加入关键词检索后精确匹配的权重上来了召回准确率明显提升。实操心得知识库文档的命名很重要。我一开始用“信贷政策.pdf”这种笼统的名字后来改成“2024年小微企业信贷政策-准入条件.pdf”这种带年份和章节的命名检索时的元数据过滤效果好很多。AgentArts支持按文档名过滤这个功能在政策有多个版本时特别有用。3.4 风险评估节点规则引擎与LLM的配合风险评估节点是整个智能体的核心。我的设计思路是规则引擎打底LLM做补充。具体来说先把行里现行的风险评分卡规则用代码实现一遍包括财务指标阈值判断、征信记录扣分、行业风险调整等。这部分是确定性的不依赖LLM。然后LLM在规则引擎输出的基础上结合检索到的政策条款生成一段自然语言的风险分析。为什么要这么设计因为纯靠LLM做风险判断有两个问题一是不稳定同样的输入两次运行可能给出不同的风险等级二是不可解释LLM说“风险较高”但你问它具体触发了哪条规则它说不清楚。规则引擎保证了判断的一致性和可解释性LLM则负责把冷冰冰的分数转化成客户经理能看懂的分析文字。规则引擎的实现不复杂就是一系列if-else判断。比如资产负债率超过70%扣20分有当前逾期记录直接判定为高风险对外担保金额超过净资产50%扣15分等等。这些规则从行里的风险指引文档里来我把它整理成了一个配置表方便后续调整。risk_rules [ {condition: debt_ratio 0.7, score: -20, reason: 资产负债率超过70%}, {condition: overdue_count 0, score: -100, reason: 存在当前逾期记录}, {condition: guarantee_amount net_assets * 0.5, score: -15, reason: 对外担保超过净资产50%}, # ... 更多规则 ]LLM在风险评估节点收到的输入包括提取的结构化字段、规则引擎的评分结果和触发规则列表、检索到的相关政策条款。提示词要求LLM基于这些信息生成一段200字左右的风险分析必须引用具体的政策条款编号并且不能添加规则引擎未涉及的新判断。这个约束很重要防止LLM“自由发挥”引入不可控的风险。3.5 额度测算与意见生成最后的输出环节额度测算节点相对简单就是调用行里现有的额度测算模型。这个模型可能是一个API也可能是一段Python代码。在AgentArts里我把它封装成了一个工具节点输入是提取的财务数据和风险评分输出是建议授信额度。这里要注意的是额度测算模型可能需要一些智能体没有提取的字段比如行业代码、地区代码等这些字段我从申请信息里补全或者在工具节点里设置默认值。意见生成节点是最后一步把前面所有节点的输出汇总成一段完整的审批意见。这段意见要包含申请人基本信息、关键财务指标、风险评分和主要风险点、政策依据、建议授信额度和期限、附加条件如有。提示词里我给出了一个固定的模板LLM只需要把各个字段填充进去并做适当的语言润色。这样既保证了格式统一又避免了LLM随意发挥。注意意见生成节点的输出一定要做敏感信息过滤。我遇到过LLM在意见里直接写“该企业法人代表有民间借贷纠纷”的情况虽然信息是从征信报告里提取的但直接写在审批意见里可能引发合规问题。我的做法是在这个节点后面加一个过滤工具把涉及个人隐私的表述替换成中性描述。4. 实操全流程从零搭建一个信贷审批智能体4.1 环境准备与AgentArts基础配置在AgentArts上创建智能体之前需要先做一些准备工作。首先是账号权限确保你的账号有创建智能体、管理知识库和调用工具的权限。其次是模型选择AgentArts支持多种基础模型我选的是盘古大模型的一个金融行业版本它在中文金融文本上的表现比通用模型好不少。如果你要用其他模型需要在模型管理里先做接入配置。创建智能体的第一步是定义角色和技能。角色描述我写的是“你是一名资深信贷审批专员负责根据申请人提交的材料和行内信贷政策给出初步的审批意见”。技能描述里列出了智能体需要具备的能力材料解析、信息提取、政策检索、风险评估、额度测算、意见生成。这些描述会影响LLM在后续节点中的行为倾向所以要认真写。接下来是工作流编排。AgentArts的工作流编辑器是可视化的拖拽节点、连线、配置参数就行。我按照前面设计的六个节点依次排列节点之间的连线设置了条件判断如果材料解析失败直接跳到错误处理节点如果信息提取的必填字段缺失触发重试如果风险评估结果是“高风险”跳过额度测算直接生成拒贷意见。这些条件判断用平台内置的表达式编辑器配置不需要写代码。4.2 知识库搭建文档预处理与切片参数知识库的搭建我花了整整两天时间大部分时间花在文档预处理上。行里给的信贷政策文档有PDF、Word、Excel好几种格式内容也有重复和冲突的地方。我的处理流程是这样的先把所有文档转成纯文本然后用脚本去掉页眉页脚和空白页接着人工核对一遍把过期作废的政策标注出来最后按章节拆分成独立的文档再上传。切片参数方面我前面提到调到了1024个token。但不同文档类型其实需要不同的切片策略。政策文件适合大切片因为条款之间有关联产品说明书适合中等切片因为每个产品相对独立监管要求适合小切片因为每条要求都很明确。AgentArts目前不支持按文档设置不同的切片参数我的变通做法是把不同类型的文档放在不同的知识库里检索时根据场景选择对应的知识库。检索参数我调了这几个向量检索的相似度阈值设为0.75低于这个值的结果不返回关键词检索的匹配模式设为“精确匹配同义词扩展”RRF融合的k值设为60。这些参数不是拍脑袋定的是我用一批测试问题跑出来的。测试问题包括“小微企业贷款准入条件是什么”“资产负债率超过多少会被拒贷”“对外担保怎么计算”等每个问题人工标注了正确答案所在的文档片段然后看检索结果里有没有命中。调参的过程就是不断调整阈值和权重让命中率最大化。4.3 工具节点的封装与调试AgentArts的工具节点支持三种类型API调用、代码执行和内置工具。我用了两种API调用用于对接行里的征信查询接口和额度测算接口代码执行用于文本清洗和规则引擎。API调用的配置比较简单填入接口地址、请求方法、请求头和请求体格式就行。这里有个坑要注意接口的超时时间要设够。征信查询接口有时候响应很慢我一开始设了5秒超时结果经常触发重试。后来改成15秒稳定多了。另外接口返回的数据格式要在工具节点里做一次解析把JSON转成智能体后续节点能用的结构化数据。代码执行节点的配置稍微复杂一点。AgentArts支持Python代码但运行环境是沙箱不能访问外部网络也不能读写本地文件。所以文本清洗和规则引擎的代码必须是纯函数输入输出都是字符串或JSON。我一开始想把清洗后的文本存到本地文件里方便调试结果发现沙箱不支持文件写入后来改成把中间结果通过节点的输出变量传递。调试工具节点的时候AgentArts提供了单节点测试功能。你可以给节点一个模拟输入看它的输出是否符合预期。这个功能很实用我每个工具节点都单独测过确认输入输出格式正确后再连到工作流里。不然整个流程跑起来一个节点出错排查起来很麻烦。4.4 工作流联调与性能优化所有节点配置完成后就是联调。联调的第一步是用一批真实的贷款申请材料跑一遍看整个流程能不能走通。我准备了20份材料覆盖了不同行业、不同规模、不同贷款品种的情况。第一轮跑下来有6份材料在信息提取节点失败了原因是OCR识别质量太差LLM提取不到必填字段。针对这个问题我做了两件事一是在材料解析节点后面加了一个质量检查步骤如果OCR文本的字符数少于阈值或者关键字段的识别置信度低于阈值就触发人工复核流程不往下走二是在信息提取节点的提示词里增加了“如果某个字段在文本中找不到输出null而不是猜测”的指令减少LLM的幻觉。性能方面整个流程跑一份材料平均耗时约45秒其中OCR占15秒LLM调用占20秒知识库检索占5秒其他占5秒。这个速度对于信贷审批场景来说可以接受因为客户经理上传材料后不需要一直等着智能体跑完后会推送通知。如果要做实时交互可以考虑把OCR和LLM调用并行化但AgentArts目前的工作流是串行的并行需要自己写代码实现。实操心得联调阶段一定要用真实数据不要用自己编的测试数据。我一开始用自己写的假材料测试跑得很顺换成真实材料后问题全暴露出来了。真实材料的格式混乱程度远超想象有客户把营业执照拍歪了有客户把银行流水截了一半还有客户上传的是加密PDF。这些情况在测试数据里根本模拟不出来。5. 常见问题与排查技巧实录5.1 信息提取准确率低的排查思路信息提取准确率低是最常见的问题。我遇到过的原因有四种OCR质量差、提示词不清晰、字段定义模糊、文本过长导致LLM注意力分散。排查的时候按这个顺序来先看OCR输出的文本质量如果文本本身就有大量乱码或缺失那问题在OCR环节需要换OCR工具或调整识别参数。如果OCR文本没问题再看提示词检查字段定义是否明确、格式要求是否具体、有没有给示例。如果提示词也没问题那可能是文本太长LLM在处理长文本时对中间部分的注意力会下降。解决办法是把长文本按段落切分分段提取后再合并结果。字段定义模糊是容易被忽略的原因。比如“营收”这个字段是营业收入还是营业总收入是去年全年还是最近一期如果提示词里不写清楚LLM可能这次提取的是营业收入下次提取的是营业总收入导致结果不一致。我的做法是给每个字段写一段明确的定义包括数据来源、时间范围、计算口径等。5.2 知识库检索不准的调优方法知识库检索不准的表现是LLM在风险评估时引用了不相关的政策条款或者明明知识库里有相关条款但没检索出来。前者是召回结果不精准后者是召回失败。召回不精准的调优方法提高相似度阈值把不相关的结果过滤掉调整切片大小让每个片段包含更完整的语义单元在检索时加入元数据过滤比如只检索“小微企业”相关的政策文档。召回失败的调优方法降低相似度阈值让更多结果进入候选集增加关键词检索的权重因为有些专业术语向量检索确实不敏感检查知识库里到底有没有相关文档有时候是文档没上传成功或者切片时被切碎了。我遇到过一个典型问题检索“科技型企业贷款政策”时知识库里明明有这份文档但检索结果里就是没有。排查后发现这份文档的标题是“高新技术企业信贷支持方案”向量检索时“科技型”和“高新技术”的相似度不够高没被召回。解决办法是在知识库的文档元数据里加上同义词标签检索时把“科技型”扩展成“科技型|高新技术|科创”召回率就上来了。5.3 智能体输出不稳定的处理经验智能体输出不稳定表现为同样的输入两次运行给出的风险等级或审批意见不一致。这个问题在金融场景下很致命因为审批结果必须是一致的。原因通常是LLM的温度参数设得太高。AgentArts默认的温度是0.7对于创意写作场景合适但对于信贷审批这种需要确定性的场景太高了。我把温度调到0.1输出的稳定性明显提升。另外在提示词里加入“请严格按照规则引擎的输出进行判断不要添加额外的主观判断”这样的约束也能减少LLM的自由发挥。还有一个原因是知识库检索结果的不确定性。同样的查询每次检索返回的片段可能略有不同导致LLM看到的政策依据有差异。解决办法是固定检索参数并且把检索结果缓存起来同一个查询在短时间内复用缓存结果。5.4 常见问题速查表问题现象可能原因排查方法解决方案信息提取字段缺失OCR质量差检查OCR输出文本更换OCR工具或调整识别参数信息提取字段错误提示词不清晰检查字段定义和示例补充字段定义增加示例知识库检索不到相关条款切片不合理或阈值过高查看检索日志中的相似度分数调整切片大小降低阈值知识库检索到不相关条款阈值过低或元数据缺失检查召回结果的相似度提高阈值增加元数据过滤风险评估结果不一致温度参数过高检查模型温度设置降低温度至0.1-0.3工作流执行超时某个节点耗时过长查看各节点执行时间优化耗时节点增加超时时间工具节点调用失败接口地址或参数错误单节点测试检查接口配置确认参数格式6. 我在这套方案里踩过的坑和总结的经验第一个坑是低估了数据预处理的复杂度。我一开始觉得把文档丢给OCR就完事了结果发现银行材料的格式混乱程度远超预期。后来我专门写了一个预处理脚本把PDF转图片、图片去噪、表格检测、文本清洗这些步骤串起来预处理时间占了整个项目的一半以上。如果你也要做类似的事情建议在数据预处理上留足时间不要想着跳过。第二个坑是提示词写得太“聪明”。我一开始想让LLM自己判断哪些字段重要、哪些政策相关提示词写得很开放。结果LLM经常“想太多”把不相关的信息也扯进来。后来我把提示词改得很“笨”明确告诉LLM每一步做什么、输出什么格式、不要做什么反而效果更好。在金融这种严谨场景下约束比自由更重要。第三个坑是忽略了知识库的版本管理。行里的信贷政策是会更新的我一开始把新旧政策都传到了同一个知识库里结果检索时经常召回已经作废的条款。后来我按年份建了不同的知识库检索时根据申请日期选择对应的知识库。这个教训告诉我RAG知识库不是一劳永逸的需要持续维护和更新。第四个坑是没有做充分的异常处理。工作流跑通之后我以为万事大吉了结果上线第一天就遇到客户上传了一个加密PDFOCR解析失败整个流程卡死。后来我在每个节点都加了异常捕获和降级处理比如OCR失败就转人工复核LLM调用超时就返回默认结果并标记待审核。这些异常处理逻辑虽然增加了开发量但保证了系统的鲁棒性。最后分享一个我觉得很实用的技巧用历史审批案例做回归测试。我整理了50笔已经审批完成的贷款案例把它们的材料和审批结果作为测试集跑一遍智能体看智能体的判断和人工审批的一致率。这个一致率是衡量智能体效果最直接的指标。我第一版的一致率只有68%经过几轮调优后到了89%。剩下的11%不一致的案例我逐一分析原因发现大部分是政策理解差异导致的少数是材料质量问题。这个回归测试集我到现在还在用每次调整提示词或知识库后都会跑一遍确保效果没有退化。