在To B的公司里，如何在内部落地大模型应用？这篇文章分享的经验，希望可以帮到大家。

如何在企业的内部应用中真正用起来大模型？

在广大的业务实践中，大家都知道“知识库”是落地的好场景，

但是

实际业务中广大的“口口相传”“老师傅才懂的”到底如何沉淀为知识库的内容。

本系列关于如何探索企业内部的大模型如何应用，如何快速找到业务效果，以及产品的实操经验。

我们一起从大模型知识反观现在真正有价值却被忽略的数据资产。

01 找到合适的业务线，找到最垂直的场景，找到landing最好的业务。

现在非常多是在应用在AIGC行业，在这个行业和应用场景中，大多数是提供给“专业”人士，所以在企业内部的“赋能”场景中，如何让不太了解大模型，不太了解AI的人，也一定得感受到“惊人的效果和魅力”。这样在没有外部的KPI驱动情况下，也能让人有“冲动”使用的机会。

我设想了一下，在现在头部的互联网产业中，Agent能先行的业务大概会有这些。

1. 企业内部的AI培训

包括：员工培训、运营宣贯等等

过去非常广泛的场景，出了一个新功能、新业务方案，需要从上至下的进行培训，总部的产品经理、运营要向各个品类业务线，各个城市的子公司进行培训，然后再逐级传递；

再者还见到过大几千的项目公司，总部拉着几千个项目负责人进行培训，最后出一个培训效果试卷，大家普遍通过“传阅”答案这件事情，让大家都满分学会。

但是想想这件事情的本质是什么？是一定要大家拿高分吗。必然不是。

总部业务同学是希望全国一盘棋，让各岗位的同学达成共识，知道遇到这种事情怎么办，知道如何使用工具等等，不要等真的出了什么事情之后，不知道如何处理对吧。

所以如何本质不是学会，是“能解决，能处理”

所以如果有一个工具，他代替全缘上下达成一致认知，等于是上下都有一个共同的“外挂脑子”。

知道遇到什么事情如何解决，遇到任何要宣传的，给这个“脑子”学习一下，不知道如何解决，也是找到到脑子问问。

所以脑子的本质就是知识库+意图理解识别，让大家都有同样的理解，认知也就达成一致了。

同样，还能保持实时更新和知识记忆。

这比人工做培训，并且每个人的理解还不一样，导致业务动作会出现变形等等。

所以通过大模型重构企业内部的培训体系，不仅仅是简单的知识库应用，这里是一个非常好的场景。

所以这里的用户action和产品形态有什么呢？

1）培训老师/运营；

– 上传并维护知识库，

– 提供一些case说明具体的专业术语含义

– 监督学习并对”脑子“进行考核，达到90%的准确率

– 确定准出，全员使用

– badcase复盘，更新知识

2）其他使用员工：

-直接提问：；从原来还要听培训课，做培训实体，但是出了问题还是要找人问，转变为， “输入场景描述，直接找脑子问，怎么办”

-场景模拟，以练代学，有实时要求的场景：用“以练带学”，让“脑子”进行场景模拟，一线员工、进行模拟练习， 比如如何应用xx的客户要求，如何应用xx的电话 这里也是借鉴了现在的AI教育的场景，如何把题目无限复制，如何精准的对知识点进行考核；

通过质检的结果，找到员工不合规的点，对细节点进行场景模拟和考核。

2. 产品形态

知识库、数据集、数据标注、chatbot、模拟场景

所以再想一步，在过去的职业经验中，很多一线的员工，包括客服、物业管家等类似的B端系统操作人员，总是在吐槽业务系统太复杂了，“我们只是想减免费用，想收个款”；结果呢，要去n个系统，录入n+1遍信息，然后才能做完，

“信息化系统”复杂和难用已经被真正的业务人员吐槽很多年了。

客户还嫌弃，我们慢，我们自己也很奇怪，为什么不能简单点呢？

所以在过去的业务场景中，to B的产品经理大部分在做“提效”的工作，让用户减少点击，做了一大堆“一键”的功能等等。

但是现在呢，通过意图识别，是可以实现多节点多流程的自动化的。

02 B端业务系统自动流转

所有的员工只需要理解客户的需求即可，不需要在“复杂”的系统中记清楚，我要先干嘛再干嘛。

通过一些bot、Agent的的形式，我要给xx用户减xx元的订单，系统记录每个动作的顺序和判断逻辑，最终直接给出结论。等于说是过去，所有的人员培训要培训如何从A点到B点，我要走过几个路口，走过几个大树，然后到了。

现在只需要，你告诉我A，我自动把你让“空降”在B点。

所以在这个业务过程中，就需要对工作流程，进行逐一“标准化”，简直是大型“场景解构”现场这件事情是非常痛苦的。过去的历史缘故信息非常多，历史数据广大，所以现在很多RAG平台工具出现了一些数据清洗的小工具。

但是要相信，这一定是“阵痛期”。

或者我猜测，很多标准化流程模版，应该也是非常受欢迎的。

电商售后运营手册-退货流程1.2.3，给一个标准化的模版，但是负责调整配置的人也可以进行参数和节点的修正。

网约车司机客服运营手册，司机服务流程123等等。

这些头部的几家基本都是大差不差的。

所以，当一家做好了，这就是非常有价值的数据资产了。

所以在这里的用户action和产品形态

1）sop负责人（也可以是业务运营）

– 办事流程梳理

– 配置作业画布

2）操作人员

– 直接通过自然语言说明要做的事情

产品形态：

流程Agent配置、外挂节点封装（包括接口、插件、知识库等等）、chat bot

03 大模型判责

在现在的多方+平台的多种商业业态中，平台如何做好判官，如何在商家和消费者之间进行纠结处理，如何处置商家、等等，都涉及了“判责”和“违规处置”这些逻辑，过去大部分的业务都是通过强“规则”这件事情进行限制，通过且或非或者种种条件数据因子来进行判断。

在强条件约束下，总有一些异常情况。

这就像什么呢，我们在学习开车时，要学习各种道路法规、各种形式准则等等

但是我们真实的开车过程中，什么时候会被交警判责，如何做到“适当”违规，用几个case来说明：

我们最普通的消费者投诉外卖员没送到指定位置，还没打电话；这个时候，平台需要核实一下具体的行为情况，

比如，我看下外卖员的呼叫记录，看下行为轨迹，如果是要上楼的，是爬楼还是电梯，很多时候在垂直空间中lbs是有些不准的，所以能否通过时间来推理出，外卖员在11:00-12:00需要上12楼需要的时间，在该时间中看下lbs的变动情况呢，

比如网约车司机被乘客投诉拒载，平台要判定下司机的行为意图，看看行为轨迹是否前往上车点，还是直接掉头走的呢，半天不动，是在等红绿灯呢，还是恶意就是不动呢，司机有没有在车里吐槽订单呢，有没有联系过乘客呢，以及司机过去有没有被投诉过呢，等等。

这些都是过去通过强规则校验中，设定好的结构化数据，人工在对司机行为进行判责

所以这里的用户action做法和产品形态

1）技术：

– 把我们过去的条件约束作为结构化知识库数据，投喂给到大模型作为知识库文档

2）运营：

– 选择场景，给prompt进行框选和描述；

– 明确判责因子：采纳人工的判责因子+结果：订单详情信息、行为轨迹（包含路径、通话录音、im）、

– 搭建workflow：通过标签因素先分大类，再逐步分小场景进行判断

– AI结果自检：在AI执行完毕workflow之后，会有一些小偏差，最后在结果确认前，采用一道限制步骤

– 人工抽检复核：人工对结果进行定性和定量的抽检，如何确实出现较大数据参数偏差，是可以对workflow进行修正的。

系统规则判责==大模型意图判责

但是不得不说，这些对于强数据的场景下有一定的局限性，只是在人工意图上有非常好的时间，比如司机的拒载，到底是真车坏了，还是真拒载呢？这种场景下，大模型结合多种证据链来推理的效果还是不错的。

产品形态

数据库订阅、（过去的历史规则数据结构化）场景prompt说明

典型场景库（提供进行场景学习）

判责workflow、数据集、数据标注

最后的，对各位实践的产品技术同学的运势说明：

上上签：

当企业内部要使用大模型进行 业务尝试的时候，分两种大场景，然后提出具体的action

首先是第一种：

从上到下进行宣贯，公司级战略规划，有核心的KPI指标push大家进行主动接触使用。

这种就非常容易，大家有KPI之后，所有人都积极起来，这个知识的内容就是越用越好用，不断沉淀数据资产，甚至还能举办一些内部的PK赛。

上签：

第二种：

没有形成公司级的战略规划，但是是某个部门的KPI，比如客服部门，产品可以和部门老板拉齐观点，确定我们的业务动作和产品动作保持一致，能够达成什么样子的业务效果。

这样拿到业务部门的支持，landing的场景也会是非常丰富，从小的业务场景未来是有机会撬动成为公司的重点项目。

中签：

老板们不懂技术，偏传统行业，需要产研内部在夹缝中创新，提供好工具给业务同学进行使用，需要产研向所有的业务同学安利自己的产品，但是这种情况也是好的，咱们毕竟有实操经验了不是～

个人认为能在现在的业务节点有机会初探并有机会在实际业务中用起来已经不涉及下签了。

嘿嘿，能看到这里的祝贺大家～