Copilot类产品在企业内落地的核心问题

导语

在许多企业在思考 AI 战略的同时，企业服务提供商如何为企业提供 AI+的服务或产品成为了 ToB 赛道的重要机会方向。在这其中，Copilot 在行业里成为了率先被关注的概念之一，也被许多企业的相应职能部门率先应用。

如何商业化？在哪些垂直需求或职能内能更早见到完善产品？出海企业如何结合 Copilot？我们在出海同学会闭门会第 90 期，与 Linkloud 一同携手，深入讨论了 Copilot 如何在企业里落地这一话题。以下是本次讨论的可公开部分。

为何行业更关注 ToB 的 AI 落地？

Linkloud 高宁

我转述一下 stability 的 CEO 在一次播客里面的观点。stability 是个开源的公司，依旧坚持把最先进的模型不断地放出来。他又讲到了自己的商业模式是什么，大家之前很关心叫 enterprise readiness，很多人提到企业会关心自己的隐私、关心自己的数据，但是没人讲到 enterprise readiness 到底怎么去落地，我觉得 stability 至少不管真与否，它的 CEO 讲到了落地的方式，我觉得是现在看到最完整的。

作为一个 AI 产品或 AI 的模型怎么在企业里落地的，他就讲到一共分为这么几步，假设是 stability 文生图的开源模型，刚开始的时候，不管是派团队里的咨询顾问、还是跟 conducting 的公司一起去合作，入驻到企业里面。刚开始的时候去听企业需要什么东西；告诉企业为什么需要大模型；现在的大模型不管是我的大模型，还是 GPT 4 ，还是 coherent，任何大模型的优缺点在什么地方，latest research 到了什么地步了；以及如果企业需要跟图像生成相关的场景，现在不同的 midjourney 或者相似的产品能做些什么事情。

花了挺长一段时间教育用户之后，他会说，为什么 stability 对你有更好的支持，原因就是因为我们的模型是开源的，不仅仅是我们的模型开源，而是说我们能帮你把模型布置在你企业里面，这就意味着，企业可以用到三部分数据，一部分叫 national data。举个例子，同样一段 prompt，放在日本、东南亚或中国，生成的东西其实是需要不一样的。

这就好比，为什么 camera 在各国建立了子公司，camera 的中国名字叫可画，因为每个节假日或民族的文化，对一段文字的理解是不同的，那就意味着要生成的东西是要符合，每个区域里面的人想要看到的一些风格，这是有地理特殊性的。

第二部分是企业的 data。企业里面肯定有自己统一的 VEI 和风格，这一部分数据是没有的，这一部分也是企业最核心的资产，企业也不希望是拿出来，或者是介意。

最后一部分，才是 stability 原生的 open source 模型，经过预训练之后的这一部分是公开的数据集，不断的功能调优、迭代，还是抓到更多的数据集，还是未来可能有多模态，本身模型的演进。

所以这三部分跟客户讲完了之后，最后说，你是日本的企业，或者印度尼西亚的企业，那么你需要产出是不一样的，我再告诉客户，这个场景里面我能做什么事情，跟我合作的 sixty integrator，或 IT 咨询公司会去交付一个怎样的 solution 或者产品，然后再按照什么样的商业模式去，不管是 licensing 还是 revenue 的分成去落地。

我觉得这才是真正把 enterprise 落地的过程，很仔细地讲清楚了。其实我们现在看到很多大模型或者是 Copilot 类产品，也遇到这样的问题。大家看到微软在 3 月份的时候发布了很炫酷的视频，以及讲解了 Copilot 在不同的产品之间有怎样的联动，去达到个人助手的目的。但是实际上我们是这个月初，才看到有新闻报道，微软 Copilot 产品开始在 600 多个企业里面测试了，以 1000 个人公司为例，大概会收 100 美金一年额外的费用，这其实也花了两个月的时间。所以这次我们也挺好奇 Copilot 作为微软最重要的一系列产品，不仅仅是在办公协同的套件里面，而是在 Dynamics、365 各个技术栈、各个技术层面上都做了植入。我们也很好奇，Copilot 类产品，企业到底是怎么用起来的？什么部门开始用起来了？希望今天与大家一起讨论。

Copilot 类产品在企业里的商业化

Kinesys.ai Nemo：

我的观点比较简单，给企业赋能有两个渠道，第一个是 internal 的，还有是 external 的。

另外一个很有意思的领域是，有更多的中型、成长型的公司，和比较成熟的传统企业公司都会去注意的，就是如何能够能够把 AI build 进我自己的产品里面去。

这个问题相对来说还是蛮复杂的，因为大家都知道 large language model 直接放进一个产品内部之前，是有很多 artifacts 和各种 prompt，或者各种来回的调用，才能真正做进产品里，

目前有一些 application framework 来试图解决这些问题，比如说像 Langchain、llama index，当然这些都是我觉得相对来说开源的比较早期的这种尝试。

但实际上我们在跟企业和创业公司去聊的时候，得到很多回答是，他们觉得 langchain 基本上只能算做一个 hobbest 的水平的一个产品，要是真的很把它能够很 predictable，很成熟的加进他们想要直接变现的客户的群体里面，还是有很多困难的，其中有一个非常不可预测地方，就是 evaluation 和 testing，所以这也是另外一个我觉得很有趣的切入点，就是我们如何能够赋能，不仅是 internal Copilot 类型产品的 use case，还有能够帮助我们的客户能够使用这件事情，这就是 external 的产品的打造。所以就是另外一个比较有意思角度。

提问： 您观察到，像类 AI 助手或 Copilot 类产品，已经用起来的是企业哪些部门？

Kinesys.ai Nemo：

我们观察到企业内部，基本上，尤其是比较传统的企业，他们首先会想到的一件事情就是怎么把 customer support 客户支持变得更加智能一些。

Logistic 特别重的公司，基本上都会先想怎么把 customer support 做得更好，尤其是售前，因为售后参与到了一些比较 economical 的 financial decision。

比如这个 refund 到底是 refund 还是不 refund，这种事情一般还是需要人工来做，但是售前的很多问题，像 Documentation 里面本来就有答案的，但是太多客户懒得去找，这类问题用 GPT 就很容易解决。我们看到客服，尤其是售前的客服是慢慢在被 GPT 给代替的。

提问：员工不太愿意贡献知识上来，是不是原来，就没有特别好的一些系统或者 documentation 去记录以前的知识，才导致现在收集数据困难？

云问科技 李蔓：

国内的知识管理分为三个阶段，早期的时候就是文档管理，会有一些知识存在知识库或者档案系统里面，内容大多偏制度、政策类的，真正运用到实战过程中的经验类其实是很少的，而这部分隐性的智慧大部分是在一线作业人员的脑子里，所以这是我们做知识型 Copilot 过程中关于知识来源一个比较大的问题。

还有一个点是国央企特别的看重咨询设计方案最终能不能落到具体工具上，不能只是给一个策划 idea，而是要把能力的实现路径清晰落到每一个工具上，这里有接口和界面的问题，也有数据和权限的考虑，所以知识智能类产品对于厂商的业务理解力和工程实践力要求比较高，考虑的因素确实比较多。

提问：国央企或能源类的客户，对于 Copilot 类的产品付费意愿高吗？

云问科技 李蔓：

国央企客户在智能化转型的力度上一直走在前面，付费意愿还是蛮高的。看历史的招投标公告，知识智能类的需求都是百万级以上，400-500w 区间的比较集中，且迁移性良好。当然除了产品工具之外，客户也非常看重前期的轻咨询、科研创新能力，以及后续的持续运营能力，咨询+产品+运营联合发挥作用把知识的飞轮转动起来。

提问：哪个部门相对来说对知识的贡献，或者数字化的技术会好一些，把这个产品推得更快。

云问科技 李蔓：

对类 Copilot 产品的接受程度其实各个部门没有太大区别，大家都是很开放地去接纳拥抱。单纯从最终使用上来看，我们判断拥有海量知识和交互需求的部门走得会更快一些，比如营销部门、设备部门。

ex-Roblox Allen Shi：

我最近看到有两个公司，他们年初大概花了一个月的时间，针对公司各个部门下了一个比较大的一个要求，希望看到每一个人都有两倍以上的生产力。我直接可以先讲结果，这两个公司大概两个月缩减了大概一半以上的人员。

这两个方向效果很显著，一个是 HR 方向，假如几百人的公司，至少有 5-10 人以上的 HR 的团队。而 HR 的团队里大部分都是花很多时间在出勤管理、离职结算、特休结算，甚至是 ESOP 结算等上面，现在基本都可归纳到一个 HR 身上。

另外一块是招聘的角度，不管是从 linkedin、Twitter 上面，一次一个整个 request，快速去搜到加 100 个人或 1000 个人，再看针对这些人用什么样的方式去回复，这部分也是内部去做到优化，加速招聘友善跟速度。

所以最后的结果，我理解的是整个 HR，从招聘到管理，到离职、薪酬等等庶务性质的工作，大概只需要一个人，整个公司只有一个 HR 现在。

我跟朋友们也有在讨论一个专案 performance review 这件事，我之前待过一些外企和大公司，一年至少要写 100 份以上或者是 200 份以上的 performance review。

假如像字节或者其它更庞大的团队，有一些同事我可能认识他或者熟悉他，但我不知道怎么样给他公正或客观。其实就可以在这个上面去调，不管是调他的在公司里面实际任职的工龄，360 度的考评，在海外还蛮多人用这个东西去做，所以跟 people 相关是以上这几块。

我自己本身是产品经理，也在做一些顾问类型的案子合作，就发现有两波客户，一波是互联网转型比较积极的，另一波是初期或早期创业阶段的，就需要两套不同的思考框架和分析框架。

顾问最怕的是提了一些很高级的东西，不接地气，甲乙方需要更多的沟通和理解，所以我们就会把一些工具提早提供给他们，让他们去使用，比如台湾的中小外贸企业，要外贸到全世界各地几十个国家，这时候怎么样用比较好的文案，或者营销内容，跟 sales 一起讨论，也容易让企业主看到改变。

因为企业主他们自己有时候也是 sales，所以这个时候也是可以帮他们在说在 sales 这一块上面去得到很大的提升了。

再举个例子，一个连锁的公司他们会有几个考量，第一是选址的考量，第二是能不能够在这一个地域上面占有一定的优势和供给。假如一些需要人力的资源汇入的时候，怎么招募到这些人，我们尝试的把一些流程全部标准化，然后通过 Copilot 给予回应，这个是线上线下的合作上面。

还有一块就，台湾有很多早期的广告公司，算是 AIGC 早期的比较 Pioneer 的团队，现在挺多的内容生成，包含演唱会、电影、社群 KOL，以及人民币预算在 50 万到 100 万以上广告预算的大型客户，在前期做 pitch 的时候，怎么样快速地拉齐客户对于想象的认知，半天或一天之内就可以很快的回复。

他们大概是 10-20 个人的团队，就可以接亚洲各地不同的视觉化、2D 或 3D 视觉化制作前期提案，这种互动设计、艺术设计算是现在比较热门一些。

此外，最近我看了一些银行业，以前银行最为痛苦的是怎么样做资料的清洗，再到用户可能的机会点，然后再到怎么样快速的让每一个团队调到这些资讯，不需要去写很复杂的 Python 等或者是 SQL 等语法，所以银行在内部上面也有改善，从内部的数据往外去做，台湾的几大银行都有在探索。

还有几个公司金融商品与证券类型的公司，或者金融商品贩卖的公司，他们都尝试着开始借有像 ChatGPT 的这种对话形式的入口型，把它变成一个门户型的入口，去投放到 C 端用户上面。

我举个例子，假如你今天想要买基金、股票或想要看权证股票基金的 performance，以前筛选要买一个很复杂的软件，问两三句就可以很快留名单到导流。

台湾有一家叫 whoscall 的公司，最早做电话骚扰，最近在台湾刚上市，他们就分出来一个团队，专门把一些入口 build 出来之后产出建议，同时跟跟东南亚的银行业合作。

Google DeepMind 戴涵俊：

我自己背景是比较偏技术方面的，在技术顾问平台也是也接触到很多企业的应用场景，正好在两方面都有一些个人的见解，正好在这里也是分享一下。

一个主要的痛点是你的 language model 本身，不管 train 的多好，都不会在企业客户的数据上去 train，所以很大一部分数据是没有 observe 到的。

第二个部分是，你的新的数据它也是不知道的，所以就是从数据本身来说，它是有一个天生的缺陷，有一些 workaround，比如 retrial based method 可以是你把你企业的私有数据作为一个 external 的 database，然后通过召回的方式，塞给 language model 让它回答问题。

这个算是一个 workaround，但是本身也有很多自己的问题，比如很多时候在 receive 的过程会有一些精度的问题，当然这个 depends on 你怎么去做 receiver，但大概会做一些 embedding business，所以本身会有一些精度的误差。

第二个是 language model 在回答的时候会有 hallucination 问题，比如关于企业本身 FAQ，这个工具怎么用或者有没有什么相关的条例不允许做什么事情，这种 factual 的事情，它可以先 receive 到相关的 tutorial 或者相关的条例，然后放到 chat 上，即使这种情况下的回答不一定能够针对你的 retrieve， 它的这种 content 去做一个 faithful 的一个 response。

也是有几个原因，一个是本身的 data 可能不是一个 structure 的 data，比如是在网页上爬的，一些格式或者是其他不相关的信息也会干扰到 language mode 本身，如果要做 clean 的话，也不是现在大家喜闻乐见的事情。

总结一下，第一个是私有的数据上，如果所有 reshave 会有一些各种各样问题；第二个是 hallucination 问题；第三个是大家还是很多会愿意去。如果 language model 足够厉害，把所有的数据全塞给他，他自己学、自己用、自己针对所有的数据去回答，不要让去做 hacking，说是 retrieval 做 chunking 。

对他们是最方便的一个模式，language model 本身也是基于它的 architecture 本身的特点，所以在长度上也会有限制。

大家现在也会 prefer，比如像 anthropic 他们的 context length 可能到 200K，或者是对其它的类似 offering，可能是 work around，但是毕竟比如说你的 training data 或者你的 instruction tuning 的 data 不一定是在这种 long context 情况下去做，maybe 会有一些顾此失彼 consideration。

刚刚说到 receive、hallucination、contact length，最后主要还会 care latency。

现在大家都发现模型是越大越好，但是很多场景的 latency，如果不能在一秒或者几秒钟之内得到 response，其实也不是很实际的应用，所以大家也会考虑到去做一些小模型的 fine tuning 或者 designation，然后希望在某一个特定的功能或者需求上能够达到或者超过大模型的能力，同时在 latency 方面也有优势。

特别是在 serving 的时候会遇到的一些问题，最后可能还有一些小点，比如企业客户自己的数据本身也是有各种各样不同的私有化管理，比如企业自己的数据可能不是企业所有人都能看到，有些只能 CEO 看，有些比较 sensitive 的。不能说一股脑全把数据塞进去调整，是不是要做权限管理，或者分开 train 等等，有一些技术和挑战。

提问：你所谓的精度的阈值，或者真正产品化或商业化的门槛，有些 Benchmark 吗？

Google DeepMind 戴涵俊：

一个是他们自己有些标注好的数据，他们可以自己测，他们也 handcrafted 的一些 case。

另外，现在竞争也是比较激烈，他们字节会 shop around 各个不同的提供服务，提供上 admin 就 language model 提供上，他们也会做自己的，也会有 comparison，自己心里也会有一个标杆。

提问：现在他们是如何解决，你刚才提到的问题的？

Google DeepMind 戴涵俊：

这个得看企业具体的背景，看他们自己有没有，比如说 AI 部门，或者还是纯粹谈依赖 Google Cloud AI 提供的 solution。

从我能看到的 case，既然是找到 Google 这边，他们还是希望把问题反馈给 Google，毕竟用的是 Google 的模型，Google 得比 responsible for that。

但是有自己 AI 团队的，会自己尝试一些额外的开源的东西，当然我们这边也看不到，肯定自己也会 depends on 自己的 AI 研发能力，或者是对团队的情况有相应的措施。

提问：Copilot 在产品落地到客户相应场景的时候，需要做哪些适配和调优。

Microsoft 韩露：

Copilot 在微软里面还处于非常早期的阶段。

比如 meeting 里面，在 teams 里面，可能就是做 summarization，这些肯定要去跟具体场景去做适配，我们也是希望所有 ST 500 各行业的人都可以使用这个功能，所以会做的怎么 general 怎么办，不会去按照行业去做调配，会按照具体的场景去做一些调整。

企业协同产品的突破和特殊性

Microsoft 韩露：

我自己是产品经理，使用后的体验是，当我开完会不想做 minutes 和 notes 的时候，它会直接给一些最重要的 bullet points，激发我 take notes down 意愿，马上发一个 follow up Email，会有这样的一个好处。它作为一个 starting point 来讲，肯定是从无到有是更好的。

提问：你刚才描述的 summary 是以怎样的载体出现的？

Microsoft 韩露：

如果是 record the meeting，开到最后的话会把 meeting record 存在云端。

比如说 one drive share point，一般来说是 share point 因为是在公司里，one drive 是对于个人来讲，所以说 share point 是对一个 team 来讲，所以它会存在云端的 Share point 里面。

但其实对于 minutes 来讲， 它其实是 transcribe audio 而不是 video，然后在文字版的基础上然后做 summarization。

提问：meeting 可大可小，有的时候可能有大几十人，是如何控制不同人、不同时间得到 summary 的？

Microsoft 韩露：

如果现在 record the meeting ，所有的 video 会在 teams meeting chat 里面，可以接 access 那些文档，可以让大家开始去 take meeting notes。

提问：有没有遇到一些客户，写作的时候用 teams，开会的时候用其它第三方的软件，比如 Zoom 之类的，这类情况 Copilot 也能 integrate，然后把 summary 做好吗？

Microsoft 韩露：

目前就是 teams，没有在做任何 integration。我有看到有一些第三方的会议纪要的软件还不错，可以在 Zoom、Google Meet 或者 teams 里面 integrate。

提问：从技术角度看，客户在部署或落地 LM 的时候的话有哪些瓶颈？哪些部门部署 LLM 意愿最强烈，以及付费意愿如何？

Google Cloud Yixin Wang：

第一个是 factuality。他们对 grounding 这种要求特别高，因为他们不希望 bot 有一些不好的言论，以损企业的形象，或者以企业的名义去 promise something that it cannot promise，这是 factuality。

第二个是 freshness。因为有些公司做 chatbot 需要跟顾客打交道，他需要一些最新价格资讯和新闻的资讯，所以 freshness 是一个比较大的需求。

第三个是 latency。他们实时性要求比个人用户要高很多，包括 service 的 SLA。现在我们知道的 Open AI 的 SLA 对外公开的，对很多企业用户来说并不是很够，尤其是在 chatbot 方面，它是一个 interactive 的过程，不是 offline 离线的 batch processing，所以对于 latency 的要求会相对的高一些。

Customer service 部门需求比较高，他们需要用 bot triaging 是比较常规的需求，进一步的需求可能是 bot 需要有一些能力去主动 reach out to customer，帮他们提供一些服务。

另外一些就是帮助企业内部提高效率，包括一些 summarization 和 retrieval 的 use case。比如 enterprise search、企业内部的 document search 之类的，这种 use case 也是比较多的，总体来说，比较大的 sector 是 financial Institute 和 digital native 比较多一些，比较大的 use case 可能是 summarization 和 retrieval 会比较多一些。

提问：对企业来说话，他们对于 documentation 反馈是怎么样？

Google Cloud Yixin Wang：

在 form 上 document 的 error 来源于很多原因。

第一，如果是 PDF 文档，那么 OCR 做得好不好是一个事情；第二，如果是 HTML ，需要去爬网页，然后 index 做得好不好是另一个事情；第三，有了这些文本之后给 documents 做 chunking 和 embedding，embedding 的质量好不好；第四，retrieval 的时候， Vector DB tune 得好不好；第五，retrieve 之后，搞个语言模型给它 summarize 起来， summarization 和 question answering 的质量好不好；所以每一个环节如果都会 error 去 accumulate 的话，其实还是有一些需要解决的问题在。

提问：客户会怎么解决？

Google Cloud Yixin Wang：

有两种解决方式，一种是技术能力比较强的公司，他们有自己的 LLM 和 ML Infra 团队，希望能够做自己的 retrieval、search，有 DIY 的一套解决方案，最优的 solution。

第二种是技术相对不那么成熟的厂，比如传统工业的厂，或者不那么 Tech Savvy 的厂，他们希望用 out of the box 的解决方案。

谷歌云有提供一个 offering，叫 unified cloud search，它是一个 out of the box 的东西，它会做的一件事情是，你给它企业网站的 URL，它会去扒企业网站里的所有的链接，然后 crawl 下来再做 search 。

提问：分享一下金融领域的落地场景和应用？

迅兔科技 罗丹：

迅兔科技是一个面向金融行业的信息服务公司。之前也在金融场景里面去使用 GPT，并且生成一些能够服务投研客户的一些场景。

最重要的一个场景就是会议纪要，因为金融行业，从业者的很大特色是每天 70- 80% 的时间，在听各种路演、听各种会、做会议纪要，形成报告或分析内容。

我们在调研的时候，发现金融行业的一些痛点。第一，疫情期间整个线上会议增长了差不多 20 倍，信息爆炸是这个行业当下面临最大的一个问题。

第二，信息平台是非常割裂的，比如路演或会议平台就有 7 -8 个，如何在海量的信息里，获取一些 Insights，这对于金融行业从业者是刚需的痛点，

第三，金融行业是唯一一个是信息直接创造资本运作的行业，信息流驱动资金流，如何处理信息，直接关系到行业的产值、行业的 GDP 。

因此我们在做应用 GPT 的时候抓住了是路演的场景，把路演的视频和音频传给我们，我们可以把多模态信息，最后处理成非常简要的投研要点。

提问：像科大讯飞、海外的一些软件也具备文字转纪要的功能，为什么金融从业者，还需要一个专门的产品？

迅兔科技 罗丹：

核心的原因是，分析师做阅读纪要的时候有一定的规律和习惯。第一是，信息一定要非常的精简、密度很高。第二是，有面向不同场景的格式的需求，比如面向业绩会的场景，需要把公司相关的要点，产能、产值、对未来的期望、管理层的综述等等，变成第一个部分，第二部分是变成非常详细的 Q&A 的过程。

产生的每一篇纪要和面向每一种不同场景的纪要，相对知识化，又同时满足金融行业从业者习惯的产品。

我们上线的两个月里面，用户增长了 8-9 倍，过程中我们发现，用户会做一些自传播，比如说小红书、微信的朋友圈里做一些评测。

提问：金融行业的会议纪，是因为出现一些特别的格式或者 format，让大家觉得体验好吗？

迅兔科技 罗丹：

我觉得里面可能有几块，一块是 format 的一个形式。无论标题分段，还有数据处理，都有比较独特的用户习惯。

另外一块是，整个处理效果方面，最后产生的会议纪要，首先观点是 MESE 的，整个 flow 非常清晰的，这个过程中我们在技术端做了几个关键的 事情。

第一是 segmentation，语义的分段，我们底层也是用的 GPT，每次 prompt 进去的时候段落其实是有长度限制的，所以每次需要根据长度做语义切割，切割的越准确，最后回应出来信息的效果肯定是越好。

第二是，怎么去做 prompt 的过程之中，我们也做了很多案例进去，我们会告诉机器，最后大概想形成一个什么样的一个效果，同时不能丢失一些重要的数据和信息，在这个过程中我们慢慢就把它调教成差不多 70-80 分的分析师的效果。

提问：你所说的 meeting，指是金融行业内部还是外部的会议？哪一种效果更好？

迅兔科技 罗丹：

金融市场有两种会议，一种是一对多的会议，券商对市场所有的买方同一时间开一个会，本质上是针对行业的公开信息，所以此类信息直接就按照以上说的的方式处理。

另一种，头部的构大部分信息是一对一的，也就是券商对一家公司去做，大概 10-20 人或 5-10 人的小范围的会议，这个时候我们的商业模式就会发生改变。

我们会把产品本身变成一种服务，目前做的形式是，和客户拉个群，他们会把想去参加的会议，想去录的会，想去做的会议纪，要直接丢在这个群里面，最后我们会以一个私域的形式，提供给他们信息和服务。

这是产品形式和信息形式的两种区别，一个是 localized，一个是在云端的。目前是做了比较高频的业绩会的讨论和纪要场景。

还有一种不同类型会议的区别，第二个场景是向基金经理调研，关注基金经理是怎么分析、怎么看问题的，我们要去 prompt 一个新的模板出来。

所以每一个模板其实针对的场景都不太一样，我们大概把金融里场景里面的会议和路演，分成了 5- 6 种。现在第一种基本已经完成，现在做第二、第三个 SKU。

提问：SKU 如何规划的？

迅兔科技 罗丹：

我们的场景的一个序列是从怎么去培养一个分析师类的，最基础的高频刚需的动作去做，然后再匹配 ChatGPT 是不是能满足这方面的功能。

GPT 的核心几块，一个是 summarization 归纳总结，一个是 retravel 检索信息，第三个我觉得比较重要的是意图识别，以前这些 SKU 的能力用小模型也能做，但是去理解用户的需求的时候，会变得很困难。所以一旦要做长尾的个性化需求的时候，我们要开发很多很多不同的 GUI，成本非常高。

当有了 GPT 之后，我们把 GPT 对于用户问题的理解的能力，路由到我们背后的 SKU。

这 SKU 不一定是大模型做的，有很多是小模型，甚至是说规则化模型去做的，因为在金融行业里面有很多是数值匹配和计算的问题。

无论背后是怎样的 skill set，本质上去运用了大模型做函数和功能调用，同时在最后一层再做了一个 summarization，所以整个过程是 chain off models，是大模型、小模型、规则模型、数据流工程捆绑在一块儿的东西，所以能够把一个 SKU 能够打磨到 70-80 分才有可能让用户买单。

现在有很多通用的软件和工具，但是它们的价值是有限的，因为作为 B 端用户企业，不会为一个 60-70 分的产品买单，起码是 80 分以上的产品。所以就我们觉得打磨 SKU 还是很关键的路径。

提问：客户能接受的定价范围是多少？

迅兔科技 罗丹：

本地化服务，是与机构需求不同而收费不同的，合作的机构在 30-50 万一年不等。

云端 SaaS，包括调研的日程、会议纪要、路演等等不同的功能，之前我们是免费试用的模式，也是希望客户能体验我们产品，并且在越来越多的客户体验中，我们不断接受需求改进，磨合成一个更加成熟、稳定的产品。今年下半年会开启收费模式大概 8 月会向市场公布，目前的定价与内测的客户沟通下来，大家也是比较 buy in 的。

提问：客户大概有多少人，会用到这样的产品？

迅兔科技 罗丹：

看不同客户属性，比如私募人数比较少，一般是 5-10 人、10-15 人的规模。

公募基金人比较多，一个机构有 50-60 名研究员，40-50 名基金经理，加起来差不多 100 多名客户，对大机构会有一些优惠。

提问：在电商或电商服务场景，是否用到 Copilot 类的助手产品？

来赞宝 胡海川：

第一块是自己做电商零售；第二块是我们把物流能力去对外输出给客户，第三是给东南亚的个小商户去输出我们的供应链能力，所以我们是既有 To C，又有 To B 的一个公司。

对 AI 的应用还没怎么真实的开始落地，还在做内部研究和观察阶段，对于公司的经济模型和成本结构会带来很大改变。

电商是一个人力密集型行业，管人、管团队是一个很低效和高成本的事情，所以大家会考虑采用阿里巴这种用利益激励的模式，降低管理成本和提升管理的半径。

通过 AI 替代人工去解决部分电商运营工作，电商运营的工作机械、重复性比较高，它不是一个特别体现创造性和思维性的工作职能，可以预知大量的机会，能够用 AI 进一步去赋能，或者取代。

第二，我们在做 ToB 的时候，有很多小 B，你需要 sales、需要去运营、需要运营增加复购和增加粘性。这些也都可以通过 agent 来做。可以想象每一个 sales people 都可以变成一个 agent，或者每一个 sales person 管很多的 AI 的 agent ，去直接做 To B 服务，也能省下很多的人力，这背后都是成本和销售费用，省下一两个、两三个点应该是非常可以期待。

提问：就你刚才讲到物流是什么意思？或者是你在探索的物流跟 AI 的结合会是在哪里？

来赞宝 胡海川：

物流是个链路，这个链路不是很标准化、数据化、自动化，只需要做 match make，是需要做匹配的，但是网络建立起来之后有很多的智能可以应用的。

比如，以前就是没有 AGI 的时候，物流网络之间的调度都靠运筹学，运筹在今天是可以被通用人工智能进一步升级的，这是一个比较远的东西。

我们在东南亚只是一个比较简单的跨境物流网络和一个海外仓网络。

还有另一个是跟物流相关的，电商零售范畴的备货，所有零售都面临备货的问题，从沃尔玛、到家乐福、到京东、到 Amazon，大家内部有很多的工具和算法，去把备货的做的更加智能化、更加科学化。

提问：现在如果有一个问答机器人给到独立站前台页面，和消费者进行互动，引导售前、订单转化，你们尝试过吗？或看过类似的产品吗？

来赞宝 胡海川：

这个显然是一个比较早，会比较容易的落地的产品，而且之前有很多公司一直在做，可能是弱 AI 背景下的产品 。

这其实和刚才讲的供应链 To B 的销售和服务是属于一个角度，肯定是一个能够用得起来的场景。

我们的客户都东南亚本地的小语种客户，越南语、泰语、马来西亚语，不是特别确定，在语言规模偏小的地方 ChatGPT 训练的效果怎么样。 我们也有看到一批新的 AI 的电商工具，目前落地还很浅。

提问：在电商行业，公司内部开始用 Copilot 或 AI 助手类产品了吗？刚才聊的场景有哪些观察？

蘑菇街 WeShop Lynn：

第一点，WeShop 去年 11 月调研这个方向，今年 1 月、2 月份开始认真的 pick up 这个项目，5 月底的时候正式上线收费版，目前三周左右，注册用户、付费率都还不错，超出我们的预期。

我们目前服务的还是国内的中长尾商家比较多，他们在淘宝或者别的电商平台上，没有特别强的请模特或者拍摄的能力，所以对于他们来说 WeShop 能够帮他们直接上传图，选择好的模特来换，很适合他们的需求

也有一些大的客户来找我们，服装类的比较多，但他们客制化的需求会比较强，目前我们团队在能力方面还希望更加聚焦在把现有 SaaS 产品做得更好上，

第二点，这个算是是公司这么多年以来，跑得比较快的产品，我们用的最多的确实是 ChatGPT，以前程序员很多问题会上 Stack overflow 去问，但现在就越来越少了。

我们自己对于什么东西比较适合，比如电商 Copilot，现在做的类的比较多，对于视频、文字还没有完全切入。

很多客户也跟我们讲说，如果在千牛上，能够直接有一个产品帮助他们完成现有工作。比如上传一个白色夏天长裙，告诉他们怎么样的标题比较好，商品详情页每一个点怎么写，包括材质、码数、再有、有视频。

最近淘宝希望大家能够上传更多的视频，所以现在还没有一个很好的产品在千牛上帮助这些商家很好用到、文字、视频三点结合。

商家希望所有东西都能归在一起，我告诉你，我要一个连衣裙，然后你把文字、、视频都帮我找到了，甚至直通车要怎么投都帮我想好，所以我感觉，接下来应该每一个部分的服务商，可能都会想要扩展到别的地方，这是对未来的一些想法。

提问：给一个 idea 生成文字图案，这相当于一个运营和设计部门的 Copilot 产品是吗？

蘑菇街 WeShop Lynn：

应该更算电商运营，服装类，国内的一些小众品牌，他们确实会有一个瓶颈，就是需要有几个设计师去找 idea，然后再返回来设计，对于设计师的 Copilot 又是另外一个领域了。

刚刚讲到的更多是电商运营，已经有这个品了，现在只能根据他们的经验知道，怎么写，能帮助用户在淘宝或者别的平台搜到产品，算是某程度的 SEO。

现在有一些接了 open AI 帮他们做这个事情，但是没有足够多的淘宝或者别的平台数据做出来，不太符合淘宝或者是国内电商对 SEO 方面需求标准。

提问：运营的同学在什么场景之中用类 ChatGPT 或者 AI 助手产品？

蘑菇街 WeShop Lynn：

还挺多的，我们会写自己的一些教程，教用户怎么做用 WeShop 产品，类似客户使用的手册，我们先写一个 online，然后 ChatGPT 帮我们扩展延伸，能很好的就是写出来给用户，这算是一个很强的点。

提问：搭建 AI 客服机器人，内部或外部考量的标准哪些方面？

蘑菇街 WeShop Lynn：

对我们来说最主要的还是部署的速度，和对于技术的损耗时间，技术的认知是要花最多的时间花在产品迭代积累的部分，比如 train 自己的人像的模型，或者在工程上的设置。

如果需要花技术几天才能做完，那我们就要考虑一下，是不是出去找别的第三方来帮忙。

我们现在是部署在云上，我们目前还没有特别多敏感的数据，如果去外面找一个机器人接入，肯定是希望部署到我们自己云上面。