如何用大模型提升数据开发各个环节效率-CSDN博客

如何用大模型提升数据开发各个环节效率

一点感受，大模型做一个完整的技术方案，很难；但如果大模型改造我们工作流程中的每一个环节，大有可为。也就是，人类专家负责构建业务流程，大模型来完成流程环节，比幻想大模型一下子做成什么事情，可行的多。

这篇文章从数据仓库的日常研发视角出发，分析大模型可以对每一个环节做哪些效率的提升。

## |0x00 推理模型和非推理模型的区别

我们都知道要用DeepSeek的R1，这是个推理模型，那么R1和V3有什么区别，我们又应该如何选用呢？

推理模型：具备思维链，在复杂任务上，能够进行更长时间、更深入的思考，比如哪怕你问它一个很简单的事情，R1都会想一下这个问题背后有哪些事情需要注意。因此，推理模型在制定复杂规划的策略时，表现的更为高效，并且准确度和精度更高。

非推理模型：反应速度更快、消耗token更少，适合直接执行的任务。非推理模型更像是搜索引擎，直接将答案告诉你，但处理复杂任务的时候，经常搞不准。

什么场景下应该选择什么模型？

第一，追求速度与成本，选择V3，模型速度更快且成本更低；

第二，有执行明确定义的任务，选择V3，模型能很好地处理明确定义的任务；

第三，要求准确性和可靠性，选R1，模型是可靠的决策者；

第四，解决复杂问题解决，选R1，模型思考能力能够显著提升结果的准确性。

当然，写代码大多数时候使用R1，但写文档读取文档的时候，如果需要的只是例行的任务，写好提示词，走V3就可以了，速度更快。

## |0x01 需求理解

作为大模型，处理自然语言是天生的优势，很多时候，我们面对的需求文档，是很复杂的MRD，或者是大段的PRD，直接读懂和理解是有难度的，而大模型具备学习文档和回答问题的能力。

在一些比较好用的AI平台上，是允许模型学习一些文档素材的，基于学习到的内容来解读当前的产品文档，很好用。

例如：回答一下什么是ADX？ XX平台和XX平台之间有什么区别？本次产品要实现的核心目标是什么？产品原型图包括几个模块，分别需要实现什么功能？请帮我按照规范生成英文词根和说明 ...

当然，我们也不能忽视大模型幻觉的事情，毕竟大模型会使用互联网上的其他语料来填充缺失的知识，而这些知识不一定是准确的。这个事情我在测试大模型解读合同的时候经常遇到，需要给出正确的引导词。

互联网的开发流程里，大部分的时间，搞的是读文档、写文档的事情，因此大模型提效显著，相当于给自己一个提纲，顺着提纲读PRD就快多了。

## |0x02 代码编写

目前在代码编写层面，我们有了一些更深入的探索。

首先，是将资产平台的信息，以文档的形式，给大模型学习。之前有不少朋友问我，资产平台如何和大模型结合，我的答案是，把资产平台当成高质量数据的产出平台，知识作为标准化数据给大模型学习，更加合适。

其次，将我希望使用的表、指标，以及需求的内容，组合成一段提示词，给大模型。例如，请使用表xxx，统计xxx维度，日期范围xxx，统计gmv、roi、cmr指标，其中cmr的计算公式 = xxx；语料写好后，直接丢给大模型；

再次，大模型会反馈执行的sql，据我使用的经验，准确率95%以上，应用层的提数类需求，用这种方式生成的嘎嘎快。原本需要2小时思考和写出代码的过程，大概15分钟就可以极限写好。最近在测试让大模型写一写复杂的需求，比如实现某种归因的逻辑，目前来看，需要讲细节规则写清楚，比如特殊指标定义、特定的过滤条件，不然大模型不理解，会乱写。。但总体上是比较可靠的。

最后，将执行SQL贴到开发平台中，配置上线。

感谢万能的GitHub，很多开发术语，“归因”、“pvuv”这些常见的技术术语，大模型都理解，写的比我好 ~

## |0x03 质量测试

质量测试有两种，一种是写测试用例，一种是执行报错时自动识别如何修改SQL。

测试用例的方法比较简单，让大模型启动深度思考能力，告诉他我的场景，生成测试用例并且执行即可。虽然这个过程比较简单，但是我们想一下，为了保证数据质量准确，我们往往会涉及很多很多种规范，走xx种用例之后才能放心使用。每次遇到一个新的需求，写测试用例也很费时间，而大模型能够自动生成！！并不是说我写的就差，而是使用工具，能够提升效率，哪怕一些微不足道的环节，累加起来，效率的提升也是很恐怖的。

另外一个就是自动识别如何修改SQL，这种情况常见于：语法不兼容、参数未设置正确、多语言混合等情况，一般是run time的时候遇到的多，大模型根据报错日志来改写目前的sql，很好用。

“道路千万条，安全第一条，测试不规范，复盘两行泪”。

## |0x04 文档生成

我一个下属第一次用大模型写好文档时，我是有点惊讶的。给的任务是接手一块前人留下的业务，然后整理好业务知识，并且改造之前不合理的公共层。然后，大模型仅用时一天时间，配合前人留下的文档，就能够快速生成一篇这个业务的科普和介绍文章，甚至还能举一些通俗易懂的例子！！

woc，大模型举例子，让我理解其他人的文档，真tmd智能！

因此，我从这个case中能够总结出一些经验，即我需要的是列出一个我希望的提纲，然后分段贴上目前现有的材料和文档，纯文本就行，然大模型基于提纲和文档，帮我改善这篇文档。虽然我们讲大模型少了一些个性，但处理这种标准化、套路化、公式化的工作，还是非常快速的。

甚至，可以基于目前的表sql，自动帮我设计公共层应该怎么重构（能不能用另说。。标准化的数据我个人认为，还是需要人来完成）。

别小看了这些文档的整理，互联网一向讲究小步快跑，先干了再说。不写文档和注释，是大多数人的习惯。TL的日常工作，很大一部分就是督促大家按照规范办事。。而大家不愿意做的理由，很多时候也是因为太费时间了，不想干。用大模型完成很多重复性的事情，事实上还能提升工作的幸福程度。

## |0xFF 总结，要不要转型算法

最后讨论一个观点，既然大模型无所不能，那我要不要转型算法？

一般来讲，不推荐，因为转型难度太大了。虽然我们说，大部分的代码，都是可以由大模型完成，我们的日常工作变成了写提示词、调用API这种简单的工作。但往复杂的说，大模型并不理解业务，大模型只是根据前人的经验，写一段貌似正确的话而已。我们需要了解业务，了解大模型的能力边界，了解哪些适合大模型，准确的提示词怎么写，等等。这都需要资深的工程师的理解能力，而不是完全没有计算机背景的业务能够搞得定的。

与其如此，从原来的做工程、做数仓，转型做AI，工作的内容没有变化，变化的只是我们使用的工具而已。这也是大势所趋，越来越多的业务需要在调用大模型来实现，而势必有一部分人要提前做出改变。

既然大家都做的是AI应用，为什么不比大多数人更懂点算法呢？