AI的试用平台账号（如果您还没有，可以扫描文末的二维码联系员外进行获取，记得提供公司名称和使用场景）。通过上面的视频，大家能看到在官网挂载一个客服机器人有多么简单，而且TorchV

以下是我在2024年6月29日上午在北京富力万丽酒店举行的稀土掘金开发者大会RAG专场的分享内容，包括文字稿，一并分享给大家！朋友们，上午好！我叫卢向东，来自杭州，今天为大家分享的是我们在大模型应用的企业落地时碰到的一些关于RAG的难点和创新。可能很多朋友认识我是因为公众号“土猛的员外”，从去年6、7月份开始持续分享了关于RAG和大模型的一些文章和观点。现正在和几个伙伴一起创业，担任杭州萌嘉网络科技（也就是TorchV）的CEO。今天在这里想和大家分享的主要内容，是关于我们在大模型应用的企业落地场景中遇到的一些问题，以及一些落地的产品案例。我一共会分享四个难点，三个应用案例，然后把一些个人对这一领域的思考放在最后面。希望能从不同视角给大家带来一些大模型应用在企业落地实践中的内容。OK，那现在我们就进入第一Part，来讲讲我们在实践中遇到的问题。第一个问题，是文件解析，或者说是知识解析。目前整个RAG流程中，第一步往往都是从文件解析开始的，如果咱们把文件上传上去，结果系统都无法识别，那后面也就没有RAG什么事情了。所以我们在具体的客户落地实施过程中，首先遇到的就是各类复杂文件的解析，企业里面的各类文件的类型是很广的，甚至有些都是我第一次听说的类型，比如“.vnp”。当然，最常见的问题主要出现在老文件上，比如“.doc”的解析上，以及各类有数字签名、带图片的pdf解析上。我们发现市面上很多同类产品是不支持“.doc”这样的老文件的，一般都只支持到“.docx”，但是你在企业应用中会发现，这太常见了，而且很多toG场景也是一样的，“.doc”很多。而且大部分情况下，你要是手工转成“.docx”依然是无效的，所以要真正去做企业的大模型应用，这些都是必须具备的能力。另外就是PDF的各种问题，PDF应该是我们碰到最常见的文件类型了，原来觉得PDF是最省心的，但是接触的实际场景越来越多之后，你会发现没见过的情况太多了，包括PDF的扫描件、布局问题，还有一些数字签名怎么绕过去，都是问题。这些都需要一一想办法去解决，包括用OCR去识别，有时候需要解读PDF的文件流，从根源上去获取它的数据结构和数据内容。关于PDF我还会在下一页讲一下表格处理。当然，文件解析的问题还有很多，包括在图文格式下如何处理，在检测到哪些情况的时候去启动OCR等等，我不一一展开讲了。还有就是布局识别，这是一个很难的事情，和OCR不同。OCR基本上就是去识别文字，有一些简单的布局识别，但是不够。真正的布局识别更多的是要知道内容在什么位置，这个位置代表的意义是什么。比如一张飞机票，1510，1540，代表的是登机时间/起飞时间？还是什么，我们是需要去根据布局上的点线和多边形来判断的。在这一块目前有一些多模态的模型可以做到60%-70%的布局识别能力，但是真正要用到企业应用中，要做到90分的效果，那还需要再等等基础模型的发展。说到这里呢，就顺便讲一下在PDF表格解析中的一些问题。这是我们自己开发的一个比较强大的PDF解析工具，基于Apache

最近两个多月写文章的频率明显低了很多，不是因为懒了，而是忙着做LLM应用的客户场景落地去了。今天把客户场景落地中的一些心得总结分享一下，希望对广大期望LLM应用落地的企业有一些帮助。前述与很多企业客户的深度接触之后，发现绝大多数企业在LLM应用落地中存在三个显著问题，这些企业包括世界500强企业、央企、著名品牌公司，也包括和我们一样但非AI行业的创业公司，所以从样本上来说应该有一定的参考性。然后再分享一下我们在落地过程中碰到的各种难点和需要客户一起决策的点。下面先说过总概。三个问题AI思维：就像以前大家常说的“互联网思维”一样，AI思维接下来肯定会被越来越多提及。其实所谓的“XX思维”没这么玄乎，说到点子上，其实就是想了解更多已经在开展的案例，然后结合自身情况来做“复制”或创新；快速工具：企业工作人员使用LLM很简单，一个浏览器就可以。但是要把LLM的能力结合到自身的业务应用和系统中就没那么容易。需要对接LLM的API、控制幻觉、管理知识库、让RAG的准确度、相关性达到企业应用水平，还需要和自己的应用相结合等。绝大多数企业更希望将自有的研发人员（AI研发人员稀缺是普遍现象）投入到应用开发上，希望基于一个开箱即用、稳定和高质量的LLM应用开发平台来提升他们的业务水平；POC验证：这是大部分企业开始都没有提出来的，但却是最影响签约的环节。企业客户需要一套有说服力的POC评测方案，在评测结果上得到满意效果之后，企业内部决策（购买）才会变得更加顺畅。四个难点私有化部署的环境：包括网络和服务器环境，我们经历了纯内网的客户、GPU版本比较老的客户，以及国产GPU环境，嗯，可以总结的内容很多；交互友好：CUI（命令行/对话方式的交互界面）的交互方式不是万能的，有些场景中，CUI会让使用者会望而却步（我不知道问什么）。有时候把对话的交互形式藏在GUI后面对用户更加友好；意想不到：很多意外情况层出不穷，有些问题可以让你的落地进度滞后半天。解决这类问题，不仅仅需要技术，还需要一个好心态，这一点我们在之前的几千万人使用过的产品研发和运营中已经养成😂；方向选择：绝对不要让你的客户说先试试看，一定要让他做目标和方向的选择，不然后续很难做POC评测。要么就是针对企业客户明确且重要的需求，一起做到90分，要么也可以什么都上，就是一个尝鲜（但要放低期待）。嗯，客户对于LLM使用的方向、他们的预期，以及客户的配合度，对于落地是否成功都非常重要。好吧，下面我们分为几个部分来梳理一下，这几部分没有什么必然联系，我也是想到哪写到哪，分别是RAG、数据、应用和部署。这里我可以先把思维导图贴出来，下文就是对这个图进行说明。图1:LLM应用落地中的问题总览思维导图问题一、RAGRAG在LLM的企业应用中的重要性自然不必多说了，我的公众号讲RAG都把我自己快讲吐了，本文就简要讲讲一些难点。首先是多跳问题图2:多跳多跳问题在我们的落地场景中一般都是发生在报告编写的数据整理环节，比如要从一堆报表中找出企业近三年的复合增长率，要和竞对比较发展情况等，这时候一般的RAG无法满足。在网上也有不少介绍解决多跳问题的方案，较为常见的是使用图数据库，但是在实际落地环境中，这对于数据更新还是有困难的（也可能是我们不熟悉），所以我们最终没选择图数据库，而是采用了去理解意图，然后拆分实体和意图的方式进行RAG。也许在某些环节中对于关联关系没有图数据库那么强大，但维护方便啊，几乎没有额外的人工维护成本。然后是路由问题图3:路有问题，我们也叫外部MoE说实话这个问题我们之前是没有关注的，但是你知道一旦落到实际生产环境中，文件一多，特别相似文件一多，各种问题就出来了。比如公司2021年的财报和2022年的财报中某项数据，有时候只在文件名和一些大标题才有年份，就造成了chunking之后失去年份等关键信息，造成最终结果的错误。这种问题我们目前采用的方式是在文件处理时收录元数据，如标题、时间、区域等。然后在检索的时候，首先对问题进行拆解，识别年份等关键信息，直接路由到相应的年份知识库或目录进行检索，不仅提升效率还解决了内容混淆的问题。二、数据相对于RAG，个人觉得数据处理是企业应用中在技术层面最难的问题。下面我就简单分享四点。结构化数据处理图4:结构化数据处理我们在RAG中处理的都是非结构化数据，比如word、pdf、txt、图片等，激活企业中沉寂状态的绝大多数资源数据，对RAG来说已经“功不可没”了。但是在企业场景中，结构化数据无法逃避，比如企业想把自己的产品数据库加入到基于LLM的应用中，在问答、统计分析等场景中就可以使用这些结构化数据。我们的对结构化数据的处理方式比较淳朴，没有把DB、excel等进行向量化处理，而是仅仅提取了结构化数据的资源名录和说明内容，或者是数据里面的表名、表描述和schema等元数据，只做元数据的embedding，然后加入到应用中，后续通过function

Use）：链接其他系统去做一些事情，比如把我电脑里面的未归档文件做好归档；规划（Planning）：类似于思维链，分解复杂任务，找到路径；协作（Multiagent

AI包含了诸多企业AI应用搭建的功能，但从快速使用来说其实只需三步：创建和维护知识库；使用Chatbot开始试用，如果您只是进行试用，到此已经完成了；如果您想将TorchV

注意：本文【非技术文章】，适用于所有想通过最新的AI技术优化自己的工作和业务的朋友。在大部分企业和事业单位，非结构化数据占比远大于结构化数据，挖掘非结构化数据的价值，为人们所用，任重道远。连接的价值“连接”可以发挥更大的价值王坚博士的《在线》是一本相对有争议的书，当年出版不久，我记得身边的朋友里就有人踩有人捧。虽然他当时讲的更多是基于云计算和大数据的一些未来发展看法，但是其中有一个重要观点，我觉得在AI时代依然适用，那就是“连接”。连接讲的是数据与互联网的连接，是数据与各类业务系统的连接，只有发生了连接，数据的价值才会像石油遇见内燃机，交流电遇见电动机一样，价值成倍上升。没有连接的数据就只能变成“沉默数据”，在掸去尘灰再次被人发现之前，这些资料文件毫无价值。这里讲的更多还是结构化数据，那么数量更加庞大的非结构化数据呢？从我二十年前开始接触计算机开始，数据更多指的就是结构化数据，比如存在关系型数据库里面的有严格schema的数据，或者存在非关系型数据库里面的带有properties（属性）的JSON格式数据，甚至我们在之前基于NLP的AI智能客服里的corpus（语料库），那也是带有结构关系的QA问答对，需要人工进行抽取再填入。但是这里的问题是，我们可以采取的数据收集方式除了基于系统定义的方式在运行中产生之外，就是只有通过人工进行清洗和导入（ETL）的。而对于一个企业或者事业单位来说，非结构化的数据才是更大占比的存在，比如合同文本、会议纪要、新闻稿、采购单、发票、项目群里的交流记录、电子邮件、财务报表、日报周报、工作计划，还有大量的PPT、Excel和Word/Markdown格式的各类文档等等。我去年从老东家离职的时候，在交还的Macbook

RAG），RAG是属于系统1，还是属于系统2呢？RAG从成千上万的文件片段中快速检索召回最“贴合”问题的那些片段，然后再Rerank，按最终的分值（Score）取top

RAG和其他中间件，在下文会具体描述其作用。中间件层是为了更好地帮助应用使用LLMs的能力，如减少幻觉、提高时效性、数据安全等，也包括更好的交互方式，更经济的推理成本等；基线产品：TorchV

概述在昨天员外分享的《TorchV的RAG实践分享（1）——RAG的定位、技术选型和RAG技术文章目录》一文中介绍了TorchV的由来，也分享了我们的几个基线产品和应用架构的方向，我们想的是在创业的过程中，将我们自己的一些产品理念、技术心得都通过公众号发文的方式分享出来，更多的和行业内的专家们共同交流，这对我们自己也是一种提升和锻炼，也期待和客户一起共创成长，逐步把产品打磨好。在目前大模型应用技术架构中，通过召回上下文来回答用户的问题是解决大模型当下的幻觉问题最靠谱/经济实惠的一种解决方案,RAG检索增强技术在整个LLM技术架构体系中的作用越来越明显。而检索召回和用户的query问句的质量则直接关系到最终大模型的生成结果。在向量数据库基础设施普及的今天，仅仅通过语义搜索召回已经无法满足企业级的需求，大家发现传统的搜索技术(基于关键词、词频等相关性的搜索)的作用也显得尤为重要，混合检索也成为了目前在RAG的技术架构中的主流检索方式，混合检索通过扬长避短的方式，在不同的业务应用场景中形成了很好的互补，对于不同的业务场景需求中，可以更灵活的进行配置满足业务需要，是RAG技术架构体系中非常重要的重要一环。本文中所提到的混合检索主要是两种搜索技术的结合，主要如下：相关性搜索：

AI的Mixtral-8x7B，为多个不同能力专长的大模型做一个LLM选择和切换。实践心得这样的架构可以让我们成员有限的产研团队聚焦在RAG这一线集中发力，而不是东一榔头西一棒槌。TorchV

昨晚和小明在讨论elasticsearch的检索，整整写了三黑板。主要原因是elasticsearch的检索有knn（其实是ann，前面文章有讲过《Rerank——RAG中百尺竿头更进一步的神器，从原理到解决方案》）和bm25两种，如何在不同的场景（针对不同客户）设置不同的boost比例就变得非常重要。昨晚讨论的最终结果是在针对不同的客户（租户）都分别拉出五个参数，便于在面对不同客户场景时可以将检索准确度做到最佳。可以简单展示一下其中的三个参数：boost：这是es自带的参数，取值0-1，一般是用来控制混合检索中BM25和KNN的分值占比的。我们内部会写成boost

本文主要内容：大模型LLM为什么会有幻觉？“消灭”幻觉的四个主要方法幻觉如何检测在之前我一篇文章比较受欢迎的文章《大模型主流应用RAG的介绍——从架构到技术细节》中提到了大语言模型（LLM）的主要缺点有三点：幻觉问题：大模型的底层原理是基于概率，所以它有时候会一本正经胡说八道，比如我们问大模型的问答系统，“良渚博物院下周一开门吗？”我相信这样的问题你不能连续问，因为大模型会有一定的几率告诉你开门。而如果游客真的在下周一去了良渚博物院，那估计就要失望了，如果这个Chat还是博物院官方提供的，那事情最终会演变成一通12345的投诉电话。所以在很多需要非常精确的场景，仅仅依赖GPT的这种生成式回答是很不严谨的，而且看起来很难消除。新鲜度问题：规模越大（参数越多、tokens越多），大模型训练的成本越高。类似OpenAI的ChatGPT3.5，目前的数据新鲜度依然保留在2021年，对于之后的事情就不知道了。而且对于一些高时效性的事情，大模型更加无能为力，比如帮我看看今天晚上有什么电影值得去看？这种任务是需要去淘票票、猫眼等网站先去获取最新电影信息的，大模型本身无法完成这个任务。数据安全：OpenAI已经遭到过几次隐私数据的投诉，而对于企业来说，如果把自己的经营数据、合同文件等机密文件和数据上传到互联网上的大模型，那想想都可怕。如果企业人员想提一个类似这样的问题：“帮我看看3月份XX部门的销售环比数据与哪些兄弟部门的增长是密切相关的？”，这需要打穿企业内部的很多数据。既要保证安全，又要借助AI能力，那么最好的方式就是把数据全部放在本地，企业数据的业务计算全部在本地完成。而在线的大模型仅仅完成一个归纳的功能，甚至，LLM都可以完全本地化部署。这三个问题中，“新鲜度问题”已经基本上被解决了，像GPT-4

本文重点：用弹子球机来展示大语言模型的一些内部原理如何去调整参数，以达到我们想要的模型输出效果今年5月份的时候我说国内真正使用过ChatGPT的人不超过5%，但是到了11月份，我再和企业、政府等的一些客户交流时，已经很难再碰到整个交谈过程中不说大语言模型（LLM）的了。但是说实话，大部分人对于LLM的了解还是很“新闻”化的，看到了现象但不达本质，往往造成了对LLM的“神化”。所以今天这篇文章，我希望用相对不那么技术化的描述来讲讲LLM的一些原理和概念，让大家对LLM有更近一步了解，也许对大家后面使用LLM及LLM应用有一定的帮助。首先做个说明：本文不会讲太多数学公式，我会尽量保证非数学、统计专业的朋友可以看懂。弹子球机今年2月份我写过一篇关于GPT的文章《ChatGPT会给文旅行业带来什么改变》，里面提了一下ChatGPT的原理，如下图所示。图1：我自己在iPad上画的弹子球机，我们需要去调整里面的柱子完成不同颜色球的分拣当时说的是假设我们有一个弹子球机器，把各种不同（颜色、重量、尺寸）的球从顶部扔进去，球会和里面的这些柱子（杯子上方的这些圈圈）相碰撞，最终掉下来，落进最下面的杯子里。我们期望机器可以做到”红色的球最终掉进红色的杯子，蓝色球掉进蓝色杯子，依次类推“，我们可以做的事情是调整机器里面的柱子（假设这些柱子表面是不规则的，而且我们可以旋转这些柱子）。如果我们一次次进行试验，然后不断去调整里面的柱子，是可以达到一个比较理想的状态的。需要注意的是，这里我们采用计算机来做试验，所以如果试验100次不够，那就1亿次，如果柱子的层数不够而引起达不到理想的状态，那么我们可以不断增加柱子，就像图里面，每个柱子其实又可以细化成无数的柱子。最终让红球落到红杯子，蓝球落到蓝杯子，......

本文主要内容先找找OpenAI等巨头不做什么再看看我们自己应该打造什么核心能力上周算是我正式离职创业的第一周，拜访客户、行业交流、选办公场地、置办办公设备等等，很多时间不在电脑面前，所以上周没更新任何文章。嗯，那就这周补上，发两篇！图1：办公室已经付了房租，夜景还是很赞的，目前等待办公家具入场，准备11月底开始办公今天这篇是上周本来就想写的，就是OpenAI

本文主要内容：为什么一般情况下RAG的检索相关性存在问题？Rerank为什么可以解决这个问题？几种常用Rerank组合评测；如何在自己的产品中使用Rerank？检索增强生成（RAG）是解决大语言模型（LLM）实际使用中的一套完整的技术，它可以有效解决LLM的三个主要问题：数据时效性、幻觉和数据安全问题（在我之前的文章《大模型主流应用RAG的介绍——从架构到技术细节》中有详细介绍）。但是随着RAG越来越火热，使用者越来越多，我们也会发现用的好的人/团队其实还是不多的。这也是RAG常被人吐槽的一点：入门简单，用好却非常难！对于RAG的效果，我们之前已经做了很多方面的优化了，包括：优化内容提取的方法：从源头解决内容提取的有效性，包括文本内容、表格内容（保留制表符）和图片内容（OCR识别）等，可以参看我之前的文章《完全指南——使用python提取PDF中的文本信息（包括表格和图片OCR）》；优化chunking：从最开始的512固定长度切分，到后面的句切分，再到后面的NLTK和SpaCy，具体可参见我之前写的《最详细的文本分块(Chunking)方法——可以直接影响基于LLM应用效果》；再之后是优化embedding模型：Embedding模型的选择其实很魔性，我们在优化过程中也会不断否定之前的一些判断。比如我们最开始用m3e，后面用bge，再后面还用了通义千问的embedding模型。总体来说，收费的通义千问还是好一些，但是不明显，有些方面却不如bge。最近一朋友也向我推荐了Jina

本文主要内容：ChatGLM3-6B是否可以解决目前的性价比问题ChatGLM2-6B、ChatGLM3-6B、Baichuan2-13B和ChatGPT-3.5评测针对7个问题评测（实体提取、逻辑计算、英文翻译、归纳、计数、SQL生成和生成代码展示分析图表）结论有惊喜，哈ChatGLM3-6B来了上周又新出来一个新的国产大语言模型——ChatGLM3-6B，据说这次他们还另外上线了3B和1.5B两个模型，但是没有选择开源。这类小体量的模型如果能力OK的话，应用前景是非常广的，可以作为桌面应用，甚至在手机上就可以部署。好，不说这么多，今天我们先来看看ChatGLM3-6B的能力相比之前的ChatGLM2-6B是否有较大提升。周末的时候我下载了ChatGLM3-6B的模型文件，这次的文件大小和ChatGLM2-6B几乎是差不多的。甚至我开始都觉得可能是同一份model文件，但是使用ll命令看详细字节数，每个文件的大小是不同的，所以我还是重新下载了一份。图1：ChatGLM2-6B和ChatGLM3-6B的models大小几乎差不多说实话，对于ChatGLM2-6B我还是比较失望的，从年初的惊艳，到后面的泯然众人，ChatGLM2-6B在我们RAG应用中已经完全不适用了，连基本的归纳都做不好，我们本来是把离线大模型的希望都寄托给它的。后续在一些应用中，我们使用在线大模型是智谱（ChatGLM所属公司）的Lite版和Pro版，这两个能力上还行。但是离线需求肯定是一个刚需，特别是对于企业客户，他们不希望自己的机密数据文件被上传到在线大模型，所以后面Baichuan2-13B出来之后，离线的大模型，我们就开始转向了百川。但是百川的13B也有个问题，就是对GPU要求很高，非负载状态下需要18GB的显存，也就是需要至少4090的显卡（24GB），而目前市面上数量较多的3090显卡（24GB，性能稍差一点）则无法胜任。所以对于此次ChatGLM3-6B的公布，我很激动，希望可以为后面的RAG应用做一个相对性价比较高的配置方案。测试方法首先我必须说，我不去做科学的对比测试，如果你需要看官方评测，我也可以贴一个ChatGLM官方给出的2和3的比较：ModelGSM8KMATHBBHMMLUC-EvalCMMLUMBPPAGIEvalChatGLM2-6B-Base32.46.533.747.951.750.0--Best

本文主要内容：近期关于RAG的一些行业交流RAG过度依赖ChatGPT好吗？RAG存在的一些问题5个改善RAG性能的方法近期行业交流的收获近两周我们也在做一些RAG方面接地气的探索，所谓接地气，就是不仅仅研究产品技术，还包括和一些行业人士交流RAG在他们的业务场景中的需求。包括与金融、法律、高校、生产型工厂、贸易公司、电商、餐饮、知识产权和文旅等行业的人士交流，后续还安排了和政务、医疗、通信、能源、教育（非义务教育）和交通等行业的人士交流。说实在的，现在大家需要的基本都是Chat——快速根据已有文档，建立知识对话系统。但是随着交流的深入，我们和行业专家也发现了一些有意思的应用，绕开了问答系统，而且，这些系统往往更加适配行业客户的需要。图1：RAG应该算是核心底层，适配各行各业，依然需要基础组件和各行业的适配应用。增加行业交流，是做产品PMF中的一个基础工作，使我们可以知道技术能带来什么产品，而产品能为使用者带去什么价值。我们会保持和行业用户继续交流，但是会把重心锁定在其中的两三个行业，做好真正有价值的产品。通过近期的交流，也发现了一些问题，和大家分享一下。RAG过度依赖ChatGPT好吗？假设我们有一个可以无限输入tokens长度的LLM，输入字符串的长度对生成式LLM的精度没有影响。除此之外，它的行为与所有其他流行的大语言模型完全相同。我们称这个模型为完美LLM。我们认为它是完美的，不是因为它有出色的性能，而是因为它有理想的无限输入tokens长度，这在今天是不可能的。无限制的输入tokens长度确实是一个吸引人的特性。事实上，像ClaudeAI就允许输入的tokens长度为100万！但是，100万tokens够了吗？因为它只相当于4-5MB，仍然比实际业务中的大量文档要小得多。现在的问题是：当你拥有如此完美的LLM时，你还会考虑RAG架构吗？具有无限输入长度的完美LLM减少了构建复杂RAG的必要性。然而，可能是的，您仍然需要考虑RAG体系结构。RAG架构不仅克服了LLM输入长度的限制，而且降低了LLM调用的成本，提高了处理速度。生成式大语言模型必须按顺序处理内容：输入越长，速度越慢。关于调用成本我想多说一句，传统的应用程序，随着并发量增加，其实边际成本是在下降的。当然它也有一个临界点，比如1千并发和1万并发需要的硬件资源会急剧上升。但是总体上来说，边际成本还是会随着并发量增加而下降。但是，这种情况目前在GPU算力主导的LLM身上没有发生，现在基本上还是存在着并发越高成本也越高的情况。也许后面会有所改善，但是目前我还没有看到这个迹象，如果你有看到不同的信息，也可以分享一下。但这里我想提一个相反的意见！我们可以看到有很多关于如何构建RAG应用程序的示例代码和开源框架（如LlamaIndex和Langchain），目前它们产出一些技术和代码案例，使用的托底LLM基本上都是OpenAI的ChatGPT。我们碰的一些已经在做RAG应用的企业，也是无一例外的在使用OpenAI。就像上面说的，这本身是正确的逻辑，因为先用目前的上限做测试，至少我们”未来可期“——等国产大模型慢慢追上来。但不得不说，ChatGPT虽然还不完美，但已经很强大了。看了这些案例之后，我们也能发现完全基于ChatGPT好像有点背离我们构建RAG的初衷，也存在一些风险：违背设计初衷：RAG的设计初衷是减轻LLM的各类问题，比如前面说到的减少幻觉、减少费用，增加实时性。但重度依赖ChatGPT反而把RAG做成了一个大模型的客户端，有点违背帮LLM分担压力的初衷；国内使用风险：在国内使用ChatGPT属于是两头堵的状况，OpenAI对中国大陆用户是明确禁用的，国家对于非可控信源也是有严格的使用说明的。如果你只是自己搭建在家里或者公司内容研究用，那可能风险相对较小。但是如果要基于LLM和RAG技术对外提供经营服务，那基本上你还是需要退回到使用国内经过网信办审核的大模型。而像我们这样使用国产大模型，或使用自己本地部署的开源大模型，确实在整体效果上和OpenAI是存在一些差距的，有时候事倍功半，想想还是挺气人的。我们需要为大模型本身的能力差距做很多”胶水组件“，其实就是很多中间件，比如表格处理，使用OpenAI的话我们可以直接使用开源的PandasAI（我之前也介绍过这个库），它会产生一些代码执行语句，给到ChatGPT，就能生产很好的结果。但是在国产大模型里面，没有这么强的程序执行能力，我们就需要做一些表格存储、处理和计算的额外功能，像这样的例子还有很多。但是这样做的好处是我们对RAG整个体系中各个环节都越来越清楚，可以快速定位到问题，知道怎么做一个胶水组件去解决问题。假以时日，国产大模型追上了GPT-3.5的水平了，那精通RAG内部各个细节的你，做出来的应用应该也会比别人的更优秀。RAG性能预期我们直接将Prompt输入到LLM中，LLM会直接消化输入文本中的所有信息，最终结果的准确性仅取决于生成式LLM的性能。图2：直接使用LLM对于普通的RAG应用程序，还有两个影响最终性能的组件：语义搜索方法和RAG实现。RAG架构使用Embedding模型来生成真实知识和查询的向量。然后使用向量相似度匹配算法来检索最相关的内容。Embedding模型从文本中提取表征向量的能力是非常关键的。除了Embedding模型之外，在RAG开发中还有很多实现细节，这些细节也会严重影响最终的结果。也就是说，RAG输出的准确率等于LLM的准确率

本文导读：实际业务中应该如何使用大模型的思考记录一款大模型产品的0到1过程在公司已经六年多收获很多成长，从纯研发leader开始，先后带过大数据产研团队、AI产研团队和运营团队，而且还作为独立销售和解决方案获得一些著名客户的订单，从一个coder变成了多面手。所以，在即将离别之际，不去讲其他纷争，只从产品角度去写两篇文章总结过去。上篇写今年之前三年的一些感想，主要记录力石小知的成长——《总结一下过去三年的产品心路》。这篇写的就是今年，在大语言模型（LLM）开始进入国内之后，我们如何思考它带来的影响，以及如何务实去落地一款产品。本文有7000多字，有点长，Enjoy！一、对大模型技术的积累看过上篇的朋友应该知道，我们在2019年就已经开始了AI产品的研发，并且这几年有一定的市场品牌口碑和数据积累。也正因为有这样的“AI传统”，我们才有一定的人才储备（比如我们的小胡，B站ID：良睦路程序员，Github：yuanzhoulvpi2017），所以当今年大模型这波新的AI浪潮袭来的时候，我们算是入局比较早的：参与大模型社区：在今年2月份，我们团队发布了最早的ChatGLM-6B社区版LoRA版本代码——（见下图）获得智谱官方PPT的介绍，这个Github

基于大模型的最新产品算是完成了v0.8版本，周五或周六会发一篇这个最新产品的总结，包括产品创意、风险选择、技术选择、用户体验大于一切、如何将大模型结合到实际场景中等等。在这之前，先发三月份写的产品心路，做一下预热，哈。本文的主要内容：AI产品力石小知的0-1市场、推广对于产品最终成功的重要性我自己总结的“产品-市场对角线”理论和实践Enjoy！在前几天公司的年度启动会上，周老师（副总裁）展示的PPT上有一页让我印象深刻，他展示了公司目前现有的8大主力产品在项目中的复用率，小知是唯一一款复用率100%的产品。当然，我知道这个100%是在一定时间段内来说的，如果时间拉长到三年半的区间，小知不可能做到100%的复用率，况且加上小知的知识运营、数据运营等工作，100%也就仅限于软件产品层面了。虽然作为当事人，我会感觉到其中的筚路蓝缕，且SaaS道路一直未真正打开。不过这些都没关系，小知作为一个团队的努力成果，依然有很多值得和大家分享的地方，特别是在产品的0到1过程中的点点滴滴。在开始分享前，先对复用率给出我的观点：产品复用率这事情，和产品经理的关系可能没想象中那么大，顶多只占1/4。好了，接下来我开始分享小知的三年产品成长心路，看完之后你应该能同意我的一些观点，并且看到我们在做产品上的一些方法。一、艰难起步01

这是LlamaIndex学习的系列文章第一篇。本文主要内容：LlamaIndex简介什么是索引（Index）普通索引、向量索引、树索引和关键词索引的介绍最近一直和小明在搞RAG，我们认为这对于大部分公司和个人来说，就是大模型的未来，有应用才能更好推动大模型发展，至少近三年内应该是。前面也输出了一些RAG方面的文章，也有了一套精确度相对较高的技术产品。但是你知道的，RAG领域也在不断发展，而且我们确实也还面临着一些实际的问题，所以最近开始细细研究LlamaIndex——我觉得适用于RAG领域的话，可能会比LangChain更优秀。今天我们先来看看LlamaIndex的索引。什么是LlamaIndex这是我自己列的一个结构图，当然是按我自己的理解画的，您只做参考吧，哈哈。我自己梳理的草稿框架图LlamaIndex是一个大型语言模型(大语言模型)的数据框架，提供以下工具:数据摄取：LlamaIndex提供数据连接器来摄取您现有的数据源和数据格式(api,

图1：RAG的架构流程，by作者创作本文主要内容：RAG应用私有化部署时LLM的选择标准；多个开源可商用大模型试用；Baichuan2-13B手工量化成8bits版本。经过之前一段时间的捣腾，个人感觉我们的RAG应用已经来到了一个全新的层面，在语义理解（相关度）和准确度上都有了长足进步。但是问题来了。之前和菊厂的业务交流中，对方明确提出一些客户的私有化部署意愿是很明确，主要原因是数据安全。这段时间和一些销售人员、潜在客户交流的时候也收到了类似信息。而我们现在的整套技术栈中，唯一还不能私有化的是LLM。而这也是最终客户最担心的问题——他们的数据被送进云上的公共LLM，不管这些LLM在数据安全上如何申明，对于一些数据就是资产的客户来说依然存在忧虑。所以我们最近就在开始做LLM的本地化测试。一、LLM选择标准在选本地化的LLM之前，我们先根据实际情况定义一些选择标准：归纳优先：我们不需要LLM在各个方面都很优秀，不需要它们会很强的coding和复杂逻辑推理能力，RAG最重要的还是出色的归纳能力；体量考虑：不要太大，最好在13B及以下，因为再大就需要一张A100等专业显卡，或者要多张消费级显卡。我们的目标是一张RTX

Fusion可以捕获用户信息需求的多个方面，从而提供整体输出并与对用户意图进行增强。3、自动为用户查询输入纠错该系统不仅可以解释用户的查询，还可以精炼用户的查询。通过生成多个查询变体，RAG

前面有朋友一直问我，提取有什么好的方法，那我就补一篇。本文将讲述从PDF中将表格、图像和纯文本提取出文本信息的完整过程，主要内容：PDF的分类：文本型、OCR和扫描型针对不同类型的PDF，我们提取的理论依据环境安装编写提取纯文本的函数编写提取图像中文本的函数编写提取表格的文本内容的函数最后的整合处理写在前面随着大型语言模型(LLM)的应用不断发展，从简单的文本摘要和翻译，到基于情绪和财务报告主题预测股票表现，再到复杂的检索（如RAG），都需要我们首先从真实世界提取文本数据。有许多类型的文档共享这种非结构化信息，从网络文章、博客文章到手写信件和图表。然而，这些文本数据的很大一部分是以PDF格式存储和传输的（我们做的更极端，即使原先不是PDF，一般也会先把文字进行处理好，转换为PDF）。因此，从PDF文档中提取信息，是很多类似RAG这样的应用第一步要处理的事情，在这个环节，我们需要做好三件事：提取出来的文本要保持信息完整性，也就是准确性；提出的结果需要有附加信息，也就是要保存元数据；提取过程要完成自动化，也就是流程化。然而，在我们开始之前，我们需要指定目前不同类型的pdf，更具体地说，是出现最频繁的三种:机器生成的pdf文件：这些pdf文件是在计算机上使用W3C技术(如HTML、CSS和Javascript)或其他软件(如Adobe

本文主要内容：1.为什么目前的市场对独立开发者越来越友好？从三个方面分析：价值导向、付费渠道和AI赋能。2.独立开发者需要注意哪些事项？5点。前些天国内的独立开发者圈子可是发生了不少事情：OpenAI等国外大模型的接入限制问题；APP接下来需要备案；承德remote开发者的罚款问题。这些事件无一不在国内开发者社区掀起轩然大波，很多人觉得独立开发者时代进入尾声……但我觉得恰恰相反，从整个经济发展规律来看，接下来应该是独立开发者（或团队）真正迎来蓬勃发展时代。我的理由是以下几个点：1.

关注“土猛的员外”公众号的朋友应该都知道我最近写了不少检索增强生成（RAG）的文章，远比大语言模型（LLM）要多。原因很简单，我觉得对于绝大多数的公司和开发者来说这是很务实的做法，那种需要太多显卡（Money）的事情本身就是一种门槛。所以我觉得去研究和实践基于LLM的应用更实际，而RAG就是非常好的一个方向，这对于很多企业来说是刚需。RAG是各方面综合之后的最优解但是就像前面我说的，RAG入门很简单，但是要能让客户买单却很难，我已经看到好几个失败案例了...下面我们来看看会有哪些方面会引起RAG的失败（下面的举例并不完全，还有一些本次来不及写了）。1.分块（Chunking）策略和Top-k算法一个成熟的RAG应该支持灵活的分块，并且可以添加一点重叠以防止信息丢失。一般来说，分块过程忽略了文本的内容，这就产生了问题。块的理想内容应该围绕单个主题保持一致，以便Embedding模型更好地工作。他们不应该从一个话题跳到另一个话题，他们不应该改变场景。比如长篇大论的论文和140字上限的微博内容的分析就会需要适配不同的分块策略，用固定的、不适合的分块策略会造成相关度下降。除了chunk，我们需要考虑参数top_k的影响。RAG系统使用top_k来选择得分达到多少的文本chunk才能送到LLM里面进行生成（Gen）操作。在大多数设计中，top_k是一个固定的数字。因此，如果块大小太小或块中的信息不够密集，我们可能无法从向量数据库中提取所有必要的信息。对于熟悉机器学习模型调优的人来说会对chunk_size和top_k非常敏感，为了确保RAG系统以最佳状态运行，需要对块大小和top_k进行调优，以确保它们是最合适的。机器学习里面参数调优的古老智慧仍然适用，唯一的区别是它们的调优成本更高。2.世界知识缺失考虑这样一个场景：我们正在构建一个《西游记》的问答系统。我们已经把所有的《西游记》的故事导入到一个向量数据库中。现在，我们问它：人有几个头?最有可能的是，系统会回答3个，因为里面提到了哪吒有“三头六臂”，也有可能会说很多个，因为孙悟空在车迟国的时候砍了很多次头。而问题的关键是小说里面不会正儿八经地去描述人有多少个头，所以RAG的数据有可能会和真实世界知识脱离。“今天的AI和机器学习真的很糟糕。人类有常识，而机器没有。”——Yann

security…--------------------------------------------------------------------------------2023-08-9

https://d18rn0p25nwr6d.cloudfront.net/CIK-0001045810/4e9abe7b-fdc7-4cd2-8487-dc3a99f30e98.pdf

本文主要内容：大语言模型（LLM）在实际应用中存在的问题；什么是RAG——检索增强生成；RAG架构解析RAG技术架构的细节展示写在前面如果你问我现在基于LLM（大语言模型，本文有时候也会将该名词描述为“大模型”）最火热的应用是什么，那我必须主推检索增强生成（RAG，Retrieval

本文主要内容：RAG中涉及的技术环节什么是分块分块需要考虑的四种因素分块的多种方法RAG是一个考验技术的工作这两周发的文章大模型偏多，但如果你有阅读过前面的文章，你会发现我其实不是为了说大模型而说大模型（有点绕），我更多的是在写怎么解决企业应用中真正的难题。这个真正难题我在前面的文章中《一些LLM的声音总结》中提到过，基于大模型的企业应用中很大一部分需求就是RAG——检索增强生成。这个流程依然无法描述RAG的复杂性RAG涉及的内容其实广泛，包括Embedding、分词分块、检索召回（相似度匹配）、chat系统、ReAct和Prompt优化等，最后还有与LLM的交互，整个过程技术复杂度很高。如果你用的LLM非常好，反而大模型这一块是你最不需要关心的。而这些环节里面我们每个都没达到1（比如0.9、0.7...），那么最终的结果可能是这些小数点的乘积。如果我们每个环节都可以做到>1.0，那么最终的结果会比上一个结果高出很多。今天我们来聊聊分块，很重要的一个环节（没有哪个环节不重要），但它也许是我们容易做到高质量的一个环节。什么是分块？在构建RAG这类基于LLM的应用程序中，分块（chunking）是将大块文本分解成小段的过程。当我们使用LLM

本文你大概会看到以下内容：大模型的主要应用场景主流中文embedding模型embedding的技术原理几种语义相似度算法在生产环境中使用embedding的案例我们现在一说到大模型，往往说的就是ChatGPT、Llama，或者国产的ChatGLM、文心一言等等。但是，那些大模型一般只属于大厂，对于大部分人来说，我们更多的角色是大模型的使用者，或者是基于大模型来开发应用。大模型主要应用目前如果是就文本方面，大模型应用主要聚焦在两类：问答（chat）机器人：这部分目前也是大模型最被人所知的应用，但chat功能我们已经有ChatGPT、Claude、文心一言、通义千问等一众产品可以用，对于大部分人来说，我们是消费者；企业检索应用：企业应用中最常见的就是更高级的检索，我们可以一般叫它检索增强生成（RAG），这个场景在企业本地化应用中比较受欢迎，可以保护企业数据安全，又可以让企业借助AI提升生产效率。而在企业检索应用中，我相信做过这一块应用的人都会遇到embedding的问题，你的embedding模型会直接影响检索和生成的效率，虽然它不是唯一的影响因素。主流中文embedding模型现在主流的中文embedding模型其实也不是太多，以下就是主要的embedding模型了，目前我们用的m3e，但效果感觉还有待提升。排名上看，BGE好像还比较不错。当然，包括像阿里的商用embedding模型也是不错的，1500+维的。本文我们从基础开始，了解一下向量Embeddings的人工智能搜索功能。使用的是Redis的功能，学习和创建模型。以下文章内容参考了《Vector

面对LLM的风起云涌，希望大家可以找个时间，找个舒服的坐位，然后耐心地阅读一下LLM的核心技术Transformer，有时候很多大模型中的神奇现象都可以在Transformer里面找到答案。对了，本文适合真正想了解大模型的朋友。Transformer模型于2017年发明，并首次在开创性论文“Attention

RAM，您可以仅使用CPU进行推理。量化本身是非常昂贵的。值得庆幸的是，我们已经可以在网上找到量化的版本。TheBloke：https://huggingface.co/TheBloke

最近把LLM（大语言模型）的一些思考总结一下。有些来自于播客，有些来自于文章，但都是我自己思考过，认可的内容。这波LLM，巨头和创业者/小公司其实处在同一起跑线，但是小公司/创业者真的没必要去做LLM，还是应该聚焦在基于AI的应用上，需要去做错位竞争。主要原因有二：这次LLM是在第一时间给市场看到了最好的产品——ChatGPT，其他竞争对手和OpenAI都还存在代差。一些国内外的Benchmark大家看看就得了，只要他们声称自己的新模型超过GPT-3.5，接近GPT-4.0，那在全领域来比较多半还差距很大，所以不要全信。后面大模型的竞争首先会成为卡的竞争，也就是钱。对于大部分企业来说，无法获得如此多的资金，而且去All

上周去看了诺兰的《奥本海默》，说真的，要深刻了解这个片子，没有一些辅助的资料还是很难的，特别是当时的背景和时局发展，后半段对奥本海默的审批，以及各种闪现的配角（诺贝尔奖得主）。当然，本篇不想过多解读审判这条主线，更多想说说研发原子弹的庞大工程——曼哈顿计划的主持人为什么是奥本海默，他有什么过人之处，以及我们可以学到什么。为了把这个问题讨论清楚，我们还是分四个章节来讲，分别是：曼哈顿计划的历史背景——先把整体的情况捋一下；为什么是奥本海默——选他的原因，以及他如何成功；我们学到了什么——对于创新型产品研发的启示；说说第二主角格罗夫斯——管理的艺术。一、曼哈顿计划背景为了让大家可以对整体的背景有一些了解，这一章节会先简要介绍背景和数据。起因原子弹工程的起因是1939年德国科学家哈恩和斯特拉斯曼发表了铀原子核裂变的论文，很短时间内，世界各国科学家在自己的实验室复现了该实验，并且发现可以实现链式反应，极其微量的铀235就可以释放出巨大能力。由于当时英法已经对德宣战，二战的大规模战争开始，于是这马上引起了科学界的警觉，匈牙利赴美的科学家齐拉得·莱奥呼吁大家警惕这种全新的科技会被用于战争。果不其然，德国任命量子力学奠基人之一海森堡开始了原子弹研究。电影剧照：爱因斯坦和奥本海默在美国这边，爱因斯坦（不用介绍了）和西伯格（“钚之父”，诺贝尔化学奖）给当时美国总统罗斯福写了一封倡议研发原子弹的信，希望总统下令全力研制核武器——德国人已经在海森堡的主持下率先开始了工作，如果这种超级炸弹掌握在泯灭人性的纳粹手里，那将是谁也不敢想象的一种结局。而后万尼瓦尔·布什（著名科学家、香农的导师，互联网、鼠标、图形界面等一系列产物的原始提出者）作为总负责人发起了原子弹制造计划。军方派出的总指挥是格罗夫斯准将（Leslie

本文讨论的是互联网出现之后，不断衍生的各种商业模式。好像任何一家目前已知的互联网和软件公司都在这31种商业模式里面。今天我们先介绍1-10种，如果你是企业家、独立开发者，也许对你会有帮助。首先，让我们来看看不同类型的创业公司。1.

本文需要一点阅读基础，最好您使用过大模型，如ChatGPT、Claude.ai或Llama，当然也不排斥ChatGLM、通义千问、文心一言等。本文还有一篇基础篇，如果您真的想学习prompt，成为一个可以“掌控”大模型的人，那么，最好从这篇文章开始读。一文讲清楚实用Prompt工程

注：本文中，提示和prompt几乎是等效的。这是一篇非常全面介绍Prompt的文章，包括prompt作用于大模型的一些内在机制，和prompt可以如何对大模型进行“微调”。讲清楚了我们常常听到的一些名词的具体意思，包括zero-shot、few-shot、微调、对齐、指令、角色扮演等等。文章主要目的是为了让大家可以通过prompt工程来提高对大模型的使用能力。由于LLMs的文本到文本格式，它们能够用单个模型解决各种各样的任务。这种能力最初是通过GPT-2和GPT-3等模型的zero-shot和few-shot学习来证明的。然而，当经过微调以符合人类偏好和指令时，大语言模型变得更加引人注目，使流行的生成应用程序成为可能，例如编码助手，信息搜索对话助理，基于聊天的搜索引擎体验。由于它们使应用成为可能，大语言模型在研究界和流行文化中都迅速成名。在此过程中，我们也见证了一个新的互补领域的发展:prompt工程。在高层次上，大语言模型的操作方式是

五一小长假回来这一周，虽只有三天，对我来说却是翻天覆地的！我回到了研发中心研发中心是我2017年来力石的第一站，当时担任研发部经理，那会儿就相当于现在的研发总监。2019年初离开研发中心，后面辗转到大数据产品中心、BOD中心和运营中心。四年后，又回到了研发中心。此研发中心非彼研发中心，而是“产品研发中心”。另外还有一个负责项目开发的“项目研发中心”。因为AI浪潮而回来这次回到产品研发中心最大的原因ChatGPT带来的这波AI浪潮，AI太热了，热到身边几乎无人不知，且有“妖魔化”的趋势，言必大模型。对于大模型来势汹汹，至少在目前的能力范围内，我们还算做了一些事情。相比于国内大多数人是在看热闹，我们已经做了几件事：3月份已经搭建了大模型，并在公司内部进行了内测，也邀请了几个客户进行了测试，内测效果还算不错；目前团队已经可以自主训练大模型，包括ChatGLM-6B、LLaMa系列和GPT-Neox（如Dolly2）等，且开源了一个30亿参数的Lora版本大模型训练项目；结合大模型已经出来两个应用Demo，比如根据给定的文件资料来提问题，答案会限定在给定资料范围内。因为以上这些原因，加上公司对“力石小知”这个产品一直以来的期望，所以公司层面上也是极力主张我放掉手上的“活”，全力带着小知团队突进起来。关于销售工作的感悟最近一年不到，除了直属团队的管理之外，我做的最认真的工作是销售。其实我不是销售小白，之前自己两次创业：一次2B、一次2C，也都兼任着销售的，但是这一年做的更多是2G的销售。那是真的不一样啊，与人相处，还要处理各种复杂的人际关系，这一点和前面的销售面临的难题是完全不一样的。2C的时候，我销售的是已经存在的服务和产品；而2G，我卖的是对客户需求的理解以及公司的交付能力。从去年6月开始，陆陆续续手上也拿了5个项目，成绩上我自己认为还算可以。最重要的，通过这一年，我也更加认识了自己：作为销售，我是有点愚笨的，从几个客户和我的对话中，虽然委婉客气，我也能感觉到哈哈哈。乐观的角度来看是：我比较真诚，不会工于心计；作为一个“资深”老研发，一个懂产品的人，做销售真的很有优势。其中有两个项目，我自己完成了商务销售、业务架构、售前文档、可研方案编写的工作，还在后面一大段时间兼任了项目经理。不要脸一点讲，说到产品、需求等，谁能比我（们）懂，如果我在和客户的相处中再“八面玲珑”一点，那应该是“有前途”的哈哈；但是现在停下来仔细想，问自己，发现自己是不喜欢项目类型的销售工作的。我更喜欢的是产品，是一种可扩展、可复制、融入自己的产品观、边际成本更低的方式去服务客户；我以前很排斥所谓的“方法论”，因为我觉得事物是发展变化的，方法论代表的是迂腐。但是这一年销售工作中遇到的棘手麻烦，都有一些方法论帮我渡过难关。这些方法论大多是一些思维模型，可以用draw.io把图画出来，就能推导出整个问题的突破口在哪里，也就发现了“解题钥匙”。接下来有时间，我会再好好总结一下这一年的经验收获，对我自己肯定是很有帮助的。接下来的工作这周把手上的项目都交接掉了，但是近一个月内应该还会帮着过渡一段时间。接下来会更加潜心在小知这个产品上，期待着“她”能翻天覆地，守得云开见月明！新领导让我多关注PMF的事情，也就是寻找和调整产品-市场的匹配点，之前老板也和我说过这一点。说明在他们眼里，PMF是我的一个标签。这时候不自觉地想到老板说的一句话——公司不缺你这么一个销售，你去做销售不划算！嗯，那就好好搞产品吧，从前台一线回到中台，就像插秧一样，退步方为向前！最后感谢老华这一年的互相扶助和照顾，你差点把我培养成3T（IT、DT、OT）人才了，哈哈哈。最后这段时间变动会有点大，但是工作中每段过程都是成长，送给我团队的每个小伙伴。

今年的第八篇，这是一篇邀稿，由文旅行业从业者“心晴”撰写。注：本文是“心晴”从游客角度出发撰写的体验和问题分析文章，并不代表“土猛的员外”和相关公司的观点。一X游：表示一机游、一码游、一键游...首先，笔者想先以旅游从业者且是旅游信息化从业者的角度，简单讲一下“一X游”的基本情况。2017年是一个分界线，虽然从2014年开始，国内旅游信息化建设大体上也是分为服务、管理和营销三个方向，但服务侧都相对分散，没有形成一个体系，更多侧侧重点在于门票电商。而2017年“一部手机游云南”开始，国内开启了“一X游”模式，从全域的视角整合目的地的文旅资源，包括门票、酒店、民宿、特产等，在类OTA电商功能的基础上，丰富公共服务和体验服务，实现与OTA部分程度上的差异化，服务占据了信息化建设很大一部分比重，直到目前依然是这种形态。这种形态主导的国内旅游信息化建设面向游客端的服务，一般会划分为游前、游中和游后三个阶段。游前：提供资讯、咨询、预订等服务，如信息查看、攻略查询、票务/酒店预订等；游中：提供体验相关的服务，如导游导览、语音讲解、导航等；游后：提供投诉建议、特产预订等服务。一般前两者会是重点，下文的游客体验方面的叙述也会从这三方面开启。其次，再解释一下为什么上文一直用的是“旅游信息化”这个词，而不是“智慧旅游”。因为在笔者看来，“信息化”是一个过程，一个工具或者说一种手段，而“智慧旅游”是一个目标，一个结果或者说是一种状态，而目前国内旅游信息化离这个目标还有很长一段距离。这里，我先以一个旅游爱好者的身份，分享一下笔者的几次出行经历，看看“一X游”是否有给笔者带来什么便利或者价值。01在说具体案例之前，笔者可以先简单说说通病，以便大家可以更好地理解后面的具体例子。在2019年和2020年，笔者多次出行，去了国内多个城市。出发之前自然是交通和住宿的安排，也就是游前的过程，这两项笔者都是在OTA上完成的，这是一个养成的习惯。到达目的地后，也就是游中的过程，笔者分别去了这几个城市的著名景区和博物馆。去这些地方游玩时，所有的门票都是到达景区后，在景区门口买的，用的也都是景区自己搭建的自营平台。对于一些文化底蕴很厚重的景区和博物馆，自己看的话无疑是走马观花，就分别现场请了导游（或讲解员），一是没看到线下有这次城市已建的“一X游”线上引导的入口，二是也担心“一X游”的实际服务覆盖能力有限，选择景区自己提供的服务会更精确、响应更及时。回顾这几次出行的整个过程，完全没有这几个城市“一X游”的使用场景，虽然笔者作为参与者，也参与了其中一个城市“一X游”的建设工作，但是在实际出行的过程中，笔者完全没有想起过要使用它，也就是这个平台没有占据笔者的消费心理。一方面，它确实没有成为笔者的消费习惯，另一方面，笔者在游玩的过程中，没有看到它的入口和宣传，也就没有启动提示作用，导致它被笔者忽视。好了，下面举两个具体的例子，但是需要事先说明的是，这两个例子已经是笔者认为国内目前“一X游”的“翘楚”了，我们来看看具体的问题。022021年，“一码游贵州”已经是业内仅次于“一部手机游云南”的存在了，无论是宣传上，还是功能上。但是作为游客的笔者，去贵州的时候与它的交道依然很少。基于各种原因，笔者去贵州选择的是跟团游，在选定跟团游的行程前，笔者线上在UGC平台做了相关攻略，明确了要去的几个景区，然后在OTA上选择了一个较为合适的线路，并预定了大交通，这是游前的过程。在做这些之前，笔者有意在“一码游贵州”上看了下相关的攻略，可能是习惯问题，平台上的攻略不太能满足需求，所以还是决定在UGC平台上完成这个过程。由于是跟团游，在贵州出行期间的酒店、交通和门票都是旅行社帮忙解决的，但是每个景区的参观导游是没办法一直在一起的，这个时候笔者有意尝试用“一码游贵州”的导游导览功能，功能页面如下图，这其实是要求笔者要知道自己所在的景点是什么，有目的地选择讲解语音，相对来说不是很便利，也就没有使用。

翻一翻，以前还写过这样的文章再好的产品也需要有好的产品故事来包装，不然酒香也怕巷子深！说到产品故事，也许你脑子里一下子不太能蹦出来一个清晰的印象，那么我们先来看看下面这两句产品描述，感受一下：A.

2023年的52篇文章——05最近只要你接触互联网，一定被ChatGPT疯狂刷屏了。确实ChatGPT作为AI领域的应用服务，据说出发布到1亿使用者只用了60天，而且还在以指数级的速度增长用户，给全世界在AI方向上带来了全新的想象空间。因为我一直在主导公司的AI产品“力石小知”，所以最近也被多位客户和同事问到ChatGPT的事情，那今天就来聊聊我自己的理解，ChatGPT可能给文旅行业带来什么影响。下面我会从以下几项内容来讲述：ChatGPT是什么；缩小到文旅行业，ChatGPT有无法解决的问题；ChatGPT会给文旅行业带来哪些改变，包括游客习惯、从业者思维和产品形态等；聊聊给行业的启示。一、ChatGPT是什么其实大家上网搜一下，已经有太多ChatGPT的介绍了，我不太想复制黏贴，就用我自己的语言来简单介绍一下吧，尽量让所有朋友都能看得懂。ChatGPT是OpenAI这个组织的一个产品，OpenAI的创始人叫山姆·阿尔特曼（Sam

2023年的52篇文章——03第一次对“数字化”三个字有深刻的印象，还是几年前听一个在政府工作的朋友说的一个小段子开始的：有一次他们给一位大领导汇报“数智化”，这位大领导听了之后就和他们说，你们还是想想怎么把“数字化”研究透、做扎实。不久之后，数字化改革就从浙江开始蔓延，变成了一条不容忽视的赛道。今天不想讨论数智化和数字化的区别，只想谈谈我自己理解的数字化，以及在数字化浪潮中我们应该怎么做。01

本文的主要内容：文旅数字化项目中的“交钥匙工程”什么是业务架构设计和一些具体案例如何做业务架构设计现状——交钥匙工程在文旅行业里面，有一个问题是从业者不太愿意说，但却无法回避：就是大部分的项目其实在交付之后并没有发挥出真正的价值。这些项目往往有一个统一的名字——“交钥匙工程”，这可不是一个褒义词，而是交付之后，这个项目的整个生命周期就完结了，因为多数情况下是无法继续运营起来的。造成无法运营的原因有很多，比如很大一部分人认为是没有合适的运营团队和运营投入造成的。而我觉得这个锅不能完全让运营来背，根本原因是在项目开始阶段，就缺少合理的业务架构设计，以至于在交付之后，运营人员的运营路径和系统是不匹配的。那么什么是业务架构设计呢？作为一个十多年的码农，我本来更适合讲的是系统架构，而不是业务架构，但是最近三年的从业经历中的一些亲身体验以及见过的一些“灾难级”项目，觉得还是要和大家分享一下我自己对业务架构设计的理解，能给哪怕一两位从业者带来一些新的思考也是好的。我认为的业务架构设计包含了规划设计、最终价值目标确定、价值目标的分解，以及实现目标所需要的抓手和配套的运营动作和工具。大部分的项目在开始的时候客户肯定就会有一个最初的目的，如何去理解这个目的，然后逐级分解推演到运营工作计划和系统功能清单，就是业务架构设计的工作。设计过程中是需要和最终的运营团队有深入交流的，如果在设计阶段还没有确定运营团队，那么对架构师的能力要求则会更高，就需要他们本身有较强的运营能力。业务架构设计的越好，后续的系统研发会非常有明确指向，运营团队接管后也会有非常匹配的各种抓手助力他们运营，才能真正把项目持续的运营起来。讲一个真实的案例以上说了这么多生硬的“道理”，接下来我们先来看一个真实的例子，为了不泄露太多信息，会去除一些重要信息，但可展示的内容应该也能说明白业务架构设计的重要性了。这是一个华东地区的景区，我们称这个景区为“A”，它拥有滑雪场、亲子游玩项目、度假酒店、餐饮和其他一些项目。最初的方案中，我看到的客户现状和痛点分析是数据孤岛、没有私域流量运营等几个痛点，但是在方案的后续内容中对于数据打通之后客户能得到什么，私域流量如何去打造等问题并没有去做合理化解决，而是直接开始上整体系统架构图，开始把各类产品堆进去，比如中台、比如旅游商城，还有各类综合管控系统等。各位，这并不仅仅是我们的特点，这是行业通病，而且我自己接触过的非常多的大厂架构师也不能免俗。当然，有个别几个大厂架构师是确实有很强的业务架构设计能力的，但是大厂的KPI考核有时候也让他们会把一些按客户体量来说实际上用不到的高价产品塞进去。那么面对这样的一个客户，我们更合理的处理方式应该是怎么样的呢？首先需要做的是和客户更深入的交流，包括客户的决策者和实际的运营团队，然后去挖掘哪些点可能是客户的核心竞争力。在A景区的项目中，我们最终确定下来在数字化层面上的客户核心竞争力是“做好游客的复游率”——提出了“每年必来一次”的主要slogan。因为类似于A这样的景区（或度假区）在华东地区超过10家，各自的获客竞争是非常激烈的，假设每获客成本是100元（线上线下各种渠道的推广），那么增加复游率，就可以将每获客成本大大降低，比如每获客成本变成60元，这就是景区在竞争中的核心竞争力之一。其次去分解“每年必来一次”这个主目标，一般会分成三个主要二级指标，这里我只举其中的一个，就是老客的差异化服务。简单列几个措施包括：景区大门、休息室等门禁的人脸身份识别，会有语音反馈，比如“尊敬的X先生，欢迎您再次来XXXX”，“我们为您和家人准备了XXXX”等，体现尊荣感；酒店服务上，假设普通客人是1位服务人员对应20个房间的话，老客户获得的是1位服务人员对应6个房间的服务，而且在服务、物品上也会有差异；老客大礼包，包括景交车、矿泉水、停车费等方面的减免券等。这些措施都会在老客游前就进行营销，转化率是一个检验有效性的可量化指标。然后再根据这些指标和措施进行具体的工具与运营动作的落实。比如在工具方面，这里就需要人脸识别系统和门禁、语音智能系统、改造过的PMS、电商会员系统和核销功能、营销效果数据分析系统等，以及作为底座的数据中心。在运营上，老客尊荣服务的设计和执行，礼品的筹备和发放、人员服务用语的培训等等，都是非常具体的运营动作。其实在整个业务架构的设计上，“每年必来一次”虽然是最大的目标，为了实现它而设计的软硬件系统却可能只会占30%，但这已经够了。其他70%部分，依然可以是传统的安全管控、人员管理、可视化数据驾驶舱等，毕竟这些是标准件，虽然不能为项目凸显特色，但客户也是需要的。如何做业务架构设计？接下来说说业务架构的设计步骤，也会再举一个真实的案例来配合说明。我自己整理的设计步骤是以下五步：和客户充分沟通，整理需求；挖掘和定义主指标，也就是最主要的一个大目标，或slogan；分解这个大目标，一般会分解成2-3个二级目标，并论证这些二级目标可以支撑大目标的实现；为每个二级目标制定抓手，这些抓手是为了支撑这些二级目标的，抓手一般可以是一句话的解决方案或指标，比如“人均打开次数3.1次”、“人均停留时间86秒”等；制作运营动作和工具（系统）清单，为各自的抓手服务，然后可以将一些可以共用的系统抽出来，将运营清单和功能清单合理化。这里再讲一个案例，是分布在城市里的某沉浸式文化类体验馆的项目，我们暂称为B项目。B项目我就不说具体的过程了，直接上一些图例。这里略过了客户沟通和需求整理，以及大目标（因为一看就能看出是哪个客户），只从二级目标开始，再到抓手，再到最后的运营动作和工具。当然，上图并不是最终版本的方案，整个方案有很多非常详细的单独分析拆解内容，这里只放一个集合稿的截图了。可以从二级目标或抓手开始做业务架构设计前面讲的都是从客户需求和规划阶段就开始的业务架构设计，但是很多情况是在你介入的时候，顶层的规划可能已经定义好了，这时候依然是可以进行设计，无非是从二级目标，或者抓手开始。曾经经历过一个项目，项目负责人们对于这个运营项目需要做什么已经定义的非常清晰，而且，我也觉得确实是非常有开创性，对于客户是非常有价值的。但项目在开始的第一年却进行的非常挣扎，特别是在产品和研发工作开展上，一度是找不到契合的实施方向的。

2023年的52篇文章——01新的一年开始，相信很多朋友已经开始计划这一年要干的大事情了，因为今天我也在思考。但是翻看前年、去年的年初计划，发现自己完成度是非常低的，比如列出了一年内要看完的书，要把产品做到什么程度，要学习一项新技能...但，好像近两年的完成度都没有过30%。我肯定不会把自己归为懒人，我自认为多少还是有点勤奋的^_^。那么是什么原因让自己的计划屡屡落空呢？我觉得仅仅做计划是不够的，甚至，太过细致的计划是有害的，一旦在实际执行过程中错过了一些计划项，很可能会对信心造成打击，影响到后续计划的执行。其实大多数的事情都贵在坚持，在这方面，2022年下半年我似乎找到了一些方法，并且获得了一些好的收获。这个方法的本身并不是计划，而是提示。在继续往下讲之前，我想先借助一个思想工具：福格行为模型。其核心思想是影响行为的因素有三个：动机+能力+提示，只有三位一体，才能使行为发生。就思想工具而言，是非常简单的，但真正理解之后，会有奇效，下面展开讲一讲。影响我们去做一件事，特别是一些需要坚持的事情，动机肯定是很重要的，但是作为成年人，动机反而可以是放在最后面的因素。而且动机这玩意儿，太不单纯了，很容易“背叛”我们，就像昨天你想为中华崛起而读书，今天想安安静静过好这一生也不错。像那句话：“明白了很多道理，却依然过不好这一生”，真正让我们的人生道路发生改变的并不是你意识到了什么，那些真正让改变发生的更大因素恰恰是能力和提示。我们先来看能力能力其实很好解释，就是完成这件事对你来说的难易程度。我们当然会崇拜披肩斩棘、筚路蓝缕般的迎难而上，但这样事情极难持续，也就是我们说的做成一次就可以吹一辈子。如果我们要持续坚持做好一件事，那么最好的方式是把事情拆简单一点，再简单一点。说回计划这件事，可以做的大块一点、含糊一点，不要过于细致，太细致反而是很难执行的，因为你每天会碰到各种不得已，不要为了错过一次规划的“行为”而懊恼，也不要因为连续错过三次就放弃。当然，能力是需要去提升的，这会帮助我们每次做好更困难一点的事情。提升的方式主要有两种：学习，刻意训练，提升技能；借助工具、向朋友求助，以及用金钱换时间。最重要的，我们来看提示其实我主要想讲的就是提示，这是2022年下半年，让我获得一些实际好处的助力因素。先从我身上发生的两个例子说起。第一个例子是跑步，我是从2022年的5月份开始正儿八经跑步的，每周大概2-3次，每周跑满10公里。跑步对我这样BMI接近30的人来说肯定是有巨大好处的，动机很明确，但是光有动机没用，难道我是今年才知道这个道理吗？这些年我一直没能坚持下来。去年坚持下来的主要原因，我觉得就是经常给自己设置提示——如果明天早晨要跑步（我一般是周二、周四和周六早上跑步），那么我就会在今晚把跑鞋、运动服和腰包放在副驾驶座。第二天一早，把儿子送到学校之后，看着这些装备，我怎么好意思不跑呢！就这样，我坚持了半年，目前是阳康阶段，只能到春节后再跑了。当然，除了提示，还有一点非常重要，就是鼓励。我会把跑步数据放在朋友圈，有不止30位朋友、同事和我当面聊过跑步的事情，一些同事最经常说的就是“你真的瘦了”。是的，这种鼓励是很重要的，其实它也是一种“提示”，因为提示除了物品提示，还有人的提示。当然还有就是情境的提示，每次开车经过丽水路，看着运河边的绿道，那份心痒痒、脚痒痒也是让我们坚持下来的动力之一。第二个例子是项目的推进。下半年我作为销售的一个项目，在内部产研推进上一开始非常不顺，这里有内外部各方面的原因。有那么一段时间我很焦虑，都有马上要掉头发的感觉了。甚至我自己都躬身入局到产研侧，讲大道理，讲项目的重要性，讲做好这个项目对每位参与者带来的好处，在公司内部刷脸请专家帮助项目组解决问题，等等。还给项目组做时间节点计划，除了代码不写之外，貌似什么事情都亲自下场了，但无济于事。幸好没过多久，我在小宇宙（任鑫的播客）中听到了福格行为模型，马上找书看了一下，发现确实可以解决我面临的一些问题。于是，我也不去给项目组做什么细致到时间节点的规划了，而是几乎每天会找相关的产品经理、开发负责人聊聊天，哪怕只是一句“怎么样了？”、“有遇到什么问题吗？”。我现在可以确切地说，这种每天的提示，让项目组的人的行为更加有效了。比我之前给他们做时间节点计划，然后三五天或者一周去问一次有效得多。这两个例子在讲的都是提示，第一个是给自己设计各种提示，让自己把跑步坚持下来；第二个是为团队做每天的提示，让大家的行为可以均匀持续地发生着。特别是第二个例子，我觉得去强调做好这个项目，你们以后简历上都会有一个光鲜的客户案例，这样的动机对于产研同学来说又有谁不知道呢，但是他们更多的时候是羁绊在各种压力中，迷失在随时可能产生的小挫折中，我们需要用持续的提示去让他们的行为发生，这种提示可以是关心、询问、鼓励，甚至也偶尔是小吵吵。说了这么多，其实并不是让大家不要做规划了，而是觉得大家更应该在这一年的历程中给自己设计更多的提示，不忘事、不苟且！去试试看，设计各种提示，就像在你前行的道路上提前扔下各种路标、补给，让你可以科学地、稳健地走下去——别太相信毅力这东西，我们大部分人都不太有。不断提示、持续行动，2023才会心想事成！

本文会讨论的以下几个问题：为什么景区数字化营销无法落地？是否真的存在创新的方法来解决景区精准营销问题？从务实的角度来看，我们应该怎么做景区数字化营销？在我的记忆中，从2015年开始整个行业就已经在关注景区的营销问题，那时候叫“智慧营销”，属于“智慧景区”或“智慧旅游”里面的一大组成板块。但是直到2022年，我也没有发现在景区游客营销方面非常有说服力的案例，特别是在山水类景区（游乐场类型的还是有个别案例的，但是更多手段的并不是数字化营销或所谓的智慧营销）。当然，不否认我孤陋寡闻，大家可以留言拍砖。还要一点要强调的就是，本文指的营销是指除景区门票、索道等项目之外，如景区内的收费服务、收费游玩项目、文创、餐饮和住宿等消费项目的营销。那么为什么在电商、金融等其他行业已经非常成熟的数字化营销在景区应用中就水土不服呢？我相信要剖析这个问题，首先需要从景区的固有特点来切入分析。下面我列了5个造成景区数字化营销失败的可能的原因。数据维度缺失在电商行业的几个头部应用上面，采集到的用户数据维度是极其丰富的，比如淘宝/天猫、京东、拼多多等。特别像淘宝，用户的个人信息，对商品的喜爱偏好数据，购买力的推测，根据购物车和收藏等数据的预判。以及你在某个产品页上看了又看，推测出来的价格敏感度或某些功能特性的担忧，一应俱全。再可能结合支付宝在生活服务和金融方面的覆盖，结合高德在出行方面的覆盖，完全可以推测出用户的收入层次、职业、家庭成员数量和品位等方面的信息。所以，基于内容的推荐，基于大数据协同过滤的推荐，以及通过贝叶斯、隐马尔可夫等算法为基础的预测分析，可以有效地形成精准营销的能力。而我们回到景区的现状，这些年在数字化层面上确实有进步，至少实名预约解决了游客身份信息和手机号码数据的收集。在这之前，游客身份信息数据收集几乎也是非常不全面的。就像早些年让我印象深刻的是绍兴的鲁迅故里-沈园景区，他们将其中的鲁迅故里（三味书屋、百草园等）作为免费景区，但前提是游客需要刷身份证入园，目的是为了收集游客数据，以便在游客身份信息，比如客源地、年龄、性别等。这些数据确实可以有效地帮助景区在门票渠道上实现更精准的价格策略，以及在市场营销上更有目的性。但，这些数据对于游客的数字化营销有多大价值呢？很直接的一个问题：你可以在游客想吃臭豆腐的时候推荐他最正宗的店，或者给他优惠券吗？所以，第一个困难点就是景区依然缺少对游客更精确的数据维度收集。营销窗口期短在淘宝等平台上，用户会经常性地拿出手机登上去看看，而且很多时候已经成为人们在放松时段打发时间的方式，天天可以拆快递的人生才是有盼头的人生，专业上说就是月活数据非常高。所以，这些平台的营销窗口期是非常长的。但是景区呢，我可以负责任地说，大部分景区是没有回头客的。哪怕是很多著名5A景区，对于大部分游客来说也就是一辈子只有一次交集的机会。也就意味着在游客和你发生连接的时间段内如果无法完成营销，那也就没有机会了。我们可以用水池和水管来形容两者的区别，淘宝等电商平台的用户是可以进入蓄水池的，有足够的时间来做营销转化；而景区的游客更像是水管里面的水，你无法在水通过这段管子的过程中实现营销，那就没有机会了。所以，传统的RFM模型（衡量客户价值和客户创造利益能力的重要工具），以及大数据分析，都会显得时效性太慢，就像用自行车是无法追上高速行驶的高铁的。缺乏触达手段淘宝、京东等APP本身就是服务商触达用户的渠道，营销可以在其上面完成。但是景区在触达手段上却显得非常贫乏，即使现在通过公众号和小程序购票已经非常普遍，但是游客在心里就是抵触你的营销的，所以买了门票、索道等刚需服务之后，基本上不太会再次打开景区的应用。当然，现在很多景区对这个问题也非常重视，所以通过景区地图导览、语音讲解等游客服务应用，确实也在增加游客打开景区应用的频次。但是问题又来了，游客还是天然有抵触其他营销的情绪，那么数字化营销如何继续？景区服务和游客需求不匹配在电商APP上，我们往往可以被推荐那些我们确实有需要的产品，甚至未退出之前的亚马逊，对于图书的推荐我是感到惊讶的。有一些我确实想找，但是我不知道怎么输入搜索关键字的书，总能被系统一次次地推荐到我面前，我会如获至宝，马上下单。但是在景区服务中，我们知道游客的需求吗？他在景区的某个区域，某个时段，会有什么样的需求，我们能知道吗？而且我们可以将确实符合他们需求的服务和产品推荐给他们吗？这种服务和需求匹配上的鸿沟，让我们在对游客进行数字化营销的时候困难重重。匹配上了，那是瞌睡了就送来了枕头，如果没匹配上，那就和美发店里面的推销一样，烦透了。所以，要做好数字化营销，如何感知游客心里那瞬时的想法非常重要。缺乏服务和产品亮点这一点我其实不太想谈，因为在这一块问题的解决上，数字化能力也许不是最佳解题关键，景区自身的产品打造、IP打造、热点制造才是关键，包括有口碑的产品，有本地鲜明特色的产品等等，是更加重要的解题手段。但是数字化也许多少也能帮上一些忙。这里讲一个我们在实操中的案例。比如在我们服务的一个国内著名头部景区的过程中，多次向景区提出数据分析上得出的一些建议，其中包括平均每个月有近300次关于哪里可以寄存行李的咨询。在今年年初，该景区终于上线了行李管家应用和一系列的服务。再比如，在分析某景区的主要游客诉求是拜佛、祈愿之后，帮助景区包装了一款热门文创产品，用一句“不要临时抱佛脚，带个佛脚杯回去每天抱着喝水”，将文创产品和游客诉求很好地结合了起来。所以，数字化需要帮助景区去发现游客会有什么样的密集需求，帮助景区去提升产品和服务的亮点。------------不能只提问题----------说了这么多，无非是为了说明电商和金融等领域已经证明非常成功的数字化营销方式并不适合景区。那么，景区应该如何去做数字化营销方面的创新呢？要在景区数字化营销上做到创新和实效，那必须先摆正价值观，要真正给游客提供他们需要的价值。我觉得所有的创新都是为了游客获得更大的游玩体验，我们可以从以下三方面展开：帮助游客可以舒心地游玩，解决他们旅途中的焦虑，比如“最后一班回去的车是什么时候？”，“附近哪里有厕所？”这些问题都不应该成为问题；要真心去服务游客，就像上面提到过的，我想瞌睡你要给我送枕头。这就需要了解游客心里的需求，然后快速反馈，满足游客需求。真心的服务才是完成数字化营销的根本；要让游客在游玩过程中有获得感，除了拍照、拍照还是拍照之外，对于一些文化历史浓厚的景区，可以将文化比重加大，好的文化输出是最能引起游客共鸣的。在这些方面，作为混迹在文旅行业多年的退役程序员，我也一直在探究。也许今天我们先不对第三点做回答，但是对于第一、第二点，以及上面提出的五个存在问题，我给出的创新解决方案是AI游客服务助手。对于游客来说，他感知到的是一个好用的、有什么问题都能帮助他提供很有价值的答案的微信小程序。可以帮助他解决旅途中的绝大多数焦虑，可以在他有需求的时候提出问题，得到满意的答案和可以匹配他需求的服务推荐。对于景区来说，游客在提问时采集的定位数据（GIS数据）、时间，和最重要的文本数据，是可以被进行实时分析的。比如游客在早上7点钟问附近有永和大王吗？这不就已经是把需求告诉我们了吗，他现在的需求是吃一顿高质量的早餐。如果恰好附近有永和大王，那么推荐给他地址，如果没有，是否可以推荐给他另外几家附近非常不错的餐点店的优惠券呢？其实这比传统的大数据多维度要更加精确，而且可以实时分析和反馈，做到我们上面说的在水管内就把数字化营销完成掉。另外，AI游客服务助手的使用过程中，游客是主动咨询，及时得到回复，也有了一个非常完美的营销触达渠道。我们尽量不要想着用短信等方式去“骚扰”游客，一方面你无法精确找到这个游客，另外一方面短信这种主动营销方式被拒绝的概率极高。---------