导语
在许多企业在思考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自己的人像的模型，或者在工程上的设置。
如果需要花技术几天才能做完，那我们就要考虑一下，是不是出去找别的第三方来帮忙。
我们现在是部署在云上，我们目前还没有特别多敏感的数据，如果去外面找一个机器人接入，肯定是希望部署到我们自己云上面。