DeepSeek赋能AI Agent，挖掘智能应用新潜能

DeepSeek作为人工智能领域的创新先锋，凭借其突破性技术为现有AI Agent赋予了更强大的任务执行与决策支持功能。而企业接入DeepSeek将带来哪些创新与实践价值，DeepSeek该如何打破发展瓶颈，其落地场景与效果表现如何等问题仍需探索。

本文将结合数势科技的实践，探讨如何通过DeepSeek和现有大模型的整合，推动企业在数字化经营中的新变革。

分享嘉宾｜岑润哲数势科技数据智能产品总经理

01DeepSeek的到来，对于大数据分析和应用领域，是“天然的利好”

数据应用赛道中，DeepSeek带来了诸多改变与优势。在数据分析领域，DeepSeek接入后，其在数学及编程能力的增强具有显著优势，极大地提升了对复杂数据的处理、统计与分析能力。在数据应用领域，代码能力与数学能力至关重要。DeepSeek到来后，无论是前期的数据清洗和特征挖掘，中期构建指标体系与指标语义层，还是后期的数据可视化及报告生成等环节，其数学能力与推理能力的提升，对数据应用的全链路机制都产生了积极影响。特别是在复杂数据清洗、数据可视化以及深度报告生成方面，DeepSeek都带来了诸多利好。

从技术视角来看，其思维链对数据分析极为有利。在数势服务的众多金融机构中，以往大模型存在一个问题：虽然能给出答案，但答案的推导过程是黑盒化的。而在DeepSeek的论文中，能够从V3的基础模型做强化模型成为DeepSeek-R1-Zero，强化学习不仅奖励准确性，还注重过程与结构的规范性。这一机制的优势在于，不仅能准确进行数据分析，还能将条理清晰的推理思路总结呈现给用户。例如，用户进行企业经营分析时，应该从哪些维度选取何种指标，DeepSeek能将思考过程以步骤的形式呈现出来。这种激励机制，极大地增强了数据分析报告的说服力，是数据应用领域的一大亮点。

作为推理模型，R1在推理时十分注重Token输出，输出的Token越多，思考越细致，出错概率越低。在进行复杂代码生成、数据数学计算及决策时，R1的表现明显优于蒸馏后的版本或千问模型。然而R1存在速度慢的问题，因为处理复杂任务需要消耗更多Token进行思考。因此可以采用结合的思路，即使用蒸馏后的相对小参数量（如32B）的模型，先进行任务分类与实体抽取，该模型在这方面与R1效果相差不大，且速度更快。然而，当用户的数据分析任务极为复杂时，可能会调用如R1这类推理模型进行深度推理与规划，以更好地满足用户的分析需求。

通过近期就模型选用问题与多家金融机构进行的交流来看，若场景主要是满足用户的快速数据检索需求，例如询问今年某月份的余额增速情况，此时无需调用R1这类长推理模型进行复杂任务拆解，使用V3模型进行读取识别与要素解析，即可快速提取数据。但如果用户的分析需求并非简单的数据提取，而是像撰写信贷报告或详细的银行信贷资产增速分析报告，这类高阶的数据推理或行动计划输出任务，V3模型的快速思考可能无法很好地完成。这种情况下，R1的推理模型更为适用，它能够将任务进行拆解。比如在分支行业绩对比复盘时，确定应关注的指标，并将任务细化为具体步骤。因此，现在很多主流AI产品都会设置“是否启用深度思考”的按钮。从某种意义上讲，这是通过产品的功能操作，让用户能够选择此次是进行快思考还是慢思考。未来，此类融合方案或许会成为众多产品的标配。

02‍数势SwiftAgent的革新与应用

‍目前数势在SwiftAgent中加入了“深度思考”按钮，一旦用户开启该按钮，便会调用R1模型进行深度推理与分析。数势的工具主要面向一些头部企业，通过接入DeepSeek后对部分能力特性进行了升级，从四个方面极大地提升了大模型的能力。

前端代码生成能力极为出色。实验得出，直接让R1基于原始数据生成代码，此时它在前端快速获取可视化呈现的能力非常强。以往，大家更多地是借助BI工具来配置一系列看板或驾驶舱，而现在，直接将原始数据交给R1生成H5或JS代码，其表现十分出色，这极大地增强了可视化能力。

其次推理能力显著提升了报告的深度。以往模型可能只能给出一些较为基础、缺乏深度的表述，而现在它能够真正思考指标是否存在问题，是否需要进行假设推断等，这大幅提升了报告的质量和深度。数据分析报告的难点在于，指标口径的准确性至关重要，结论需基于指标异常进行推断，甚至有时还需结合企业内部知识库或相关文档生成合理建议。当数据需要可视化呈现，如转化为表格以进行对比，或进行异常结论挖掘时，相较于以往如千问模型的思考深度更优，且整个过程对用户具有可观测性。

以财务数据异常分析为例，用户输入财务数据，模型能够明确告知用户，因某指标下降故而进行异常分析，其思考过程中的每一个节点都能直观地向用户解释分析的原因。如此一来，在呈现报告时，用户能够清晰理解报告撰写的逻辑，而不像以往大模型输出结果时，虽有内容却难以理解分析的依据。从这个层面来看，大模型思考过程的白盒化是一项重大变革，极大地增强了用户对结果的可信度，也提升了数据解读报告的能力。过去报告可能仅有纯文字，如今则可融入图片、表格等数据可视化元素，为用户带来更好的使用体验。

此外哪些能力适合由大模型直接生成代码去完成，哪些更适合通过工具调用。目前大模型写代码的能力很强，但有时仍需编写Function Code，而非直接让大模型生成代码。这主要分为两种情况：如果代码的范式能够固化，此时大模型直接写代码的准确率会非常高。所谓固化范式，以图表为例，基本图表具有固定范式，从数据分析可视化的角度来看，其模式早已固定，无论何时，饼图的呈现方式基本一致。在这种情况下，大模型编写代码时表现出色，基本不会出错。然而，对于业务逻辑灵活的代码，大模型则不太适合直接编写。业务逻辑通常涉及数据库中事实表与维度表的关联，这种关联具有很强的业务逻辑，且不同公司内部表与表之间的关系各不相同。若让大模型强行编写涉及三到四个表的复杂关联代码，其生成的代码往往会出现问题。所以建议通过指标平台的API取数接口，实现指标维度的拼接来获取数据，这种方式更为妥当。

03‍金融行业案例与展望

以下将详细分享某城市商业银行开展智能数据分析的成功案例，近期该银行将内部的千问模型替换为DeepSeek V3和R1后，取得了一定的效果提升。该客户产品面临的主要问题是解决行领导在数据提取和分析方面的痛点。这家银行以往依靠分析师角色，通过人工提取数据表格的方式，为领导提供诸如收入、存贷款情况、同业负债情况等报表。对于银行领导而言，其数据需求较为灵活，今日可能关注几个分支行的余额增速，明日则可能关注业绩排名。然而，银行缺乏足够的分析师来满足这些多样化需求。因此，银行期望通过自然语言查询机制，一方面释放分析师的时间，提升取数效率；另一方面，为领导提供更敏捷的归因分析及报告分析能力，以便洞察行内指标变化的异动原因，从而显著提升工作效果与效率。项目完成后的第一周，领导们提交了数千条查询请求，系统使用率较高。同时，结合指标语义层，数据准确性高，从问询到输出数据的时间基本仅需5秒左右。

这家银行开展此项目，以及众多企业寻求类似服务，本质上源于两个问题。

需求与供给的错配。即便头部银行或大型企业拥有分析师及ETL人员，但随着业务不断拓展，需求持续增长，企业不可能招募等量工程师编写脚本以满足所有需求，导致人力供给与需求不匹配。因此，企业期望借助AI agent满足日常取数和用数的分析诉求，解放人力。

指标口径层面存在黑盒问题。不同部门对同一指标名称可能存在不同理解，在底层数仓中口径不一致。所以，构建指标语义层，统一指标口径，使部门间拥有共通的数据语言，成为亟待解决的问题。‍

在实施方案中融合了大模型能力与指标语义层交互能力。当用户提出问题时，首先由大模型进行判断。若任务复杂，如需要生成深度归因报告，则通过路由将需求转至DeepSeek R1处理；若只是简单的数据提取，如按时间、机构、贷款余额等条件提取数据，使用V3或更快的模型即可。即先由大模型进行意图理解，若为复杂任务，则进入任务规划阶段，由规划层进行多任务编排。在指标查询环节，通过指标语义层，提取用户自然语言中的要素。例如用户询问各分支行业绩情况，其中分支行为维度，过去三个月为时间，业绩对应若干指标，存在一套映射逻辑。最后将这些指标语义逻辑翻译成SQL语句执行，并通过R1这样的推理模型对报告进行总结，反馈给用户。目前大模型在完整的数据提取方面能力有限，因为其对SQL底表逻辑的理解存在局限，不过大模型在任务识别与报告生成方面表现出色。因此，将大模型擅长与不擅长的部分区分开来，进行方案融合，以更好地实施相关项目。

该银行的技术团队曾尝试直接使用R1模型生成SQL。当表结构较为简单，例如查询近7日资产时，R1生成的SQL能够正常运行。然而，当问题中的任务指令较多，不仅需要提取数据，还涉及归因分析以及报告撰写等任务时，单纯通过代码生成工具来完成就较为困难。此时会先利用R1进行多任务规划，第一个任务可能是取数，第二个任务通过归因分析小模型进行维度归因，最后借助知识库生成报告。通过这种结合Agent架构与Function Code形式，能够更好地满足业务方在真实复杂业务场景下的分析需求，这些需求不仅包括数据提取，还涵盖高阶的数据洞察、归因、异常检测以及报告撰写等，这也是企业实际会面临的问题。

在为该金融机构提供服务时，采取分场景推进的方式。因为不可能一开始就覆盖所有场景。在项目一期，首先解决行领导对行内业绩指标对比的自然语言分析与报告生成需求。到了项目二期，则聚焦于实际业务，如信贷、对公贷款业务，进行风险评估、财务分析或信用卡分析等，从总部视角逐步扩展到各个业务线的领域和场景。项目一期上线后，用户体验良好。以往，无论是行长还是分支行领导，数据提取流程都是向分析师提出需求，由分析师进行加工，这个过程来回可能需要4个小时。而现在，算法能够主动帮助用户发现指标问题，例如告知用户行内不良率或贷款余额近期的变化，提醒领导关注。领导若想进一步了解各机构业务表现不佳的原因，进行详细的数据归因洞察，可按照分支行、产品类型、客户类型等维度进行问询。

最后，若领导需要向总行领导汇报，系统可结合企业已有的数据库和知识库生成包含异常原因及应对措施等内容的简单报告。在接入DeepSeek后，该银行认为其思维链生成及数据解读模块得到了显著增强。以往报告可能只有纯文字，现在则融合了表格、副文本、图表与文字，大大提高了报告的易读性和可解释性，这也是DeepSeek接入后的优势所在。

最后分享一下对于DeepSeek的未来，尤其是推理模型演进方向的展望。

第一，DeepSeek的出现实现了AI平权。这一成果意义重大，意味着无论是头部企业还是中型企业，都具备了部署开源模型的资源与能力，在这一点上，大企业和小企业处于同等地位，这是AI平台发展的体现。未来，数据应用组件将以DeepSeek为核心，分析组件作为执行部分协同运作，这样能使强大的核心与不同的技能池有效配合，更好地满足企业需求。

第二，目前DeepSeek仍无法掌握企业内部的私域知识及数据编织逻辑。在此情况下，数据应用产品需承担“翻译器”的角色。即在推理模型与企业级复杂数据结构之间构建语义层，以此作为连接用户自然语言与底层数据表格架构的桥梁，但这是大模型的通用能力所无法实现的。原因在于，DeepSeek当前的上下文处理能力为64K或128K，然而企业实际数据量，大型机构通常可达几十PB甚至上百PB。显然，无法将全部数据输入模型进行分析。因此，未来其64K或128K的上下文更适合用于推理，将任务细致拆解，再由“手脚”组件逐一执行，获取数据、开展相关分析，并将结果反馈给核心进行总结报告，这种模式更具有可行性。

第三，目前在使用R1时，存在无法控制思维链长度的问题，这导致其输出有时较为啰嗦。若R1未来取得进展，希望它能够实现对模型输出的控制。例如能够在某些场景下将Token控制在1000个以内，而在另一些场景下，允许2000个Token的输出。如果未来能够实现对Token的控制，那么在众多应用场景中，将能够灵活选择输出风格。比如，选择“谨慎型”输出，回答问题更加严谨；或者选择相对活泼、简洁的输出风格。