简介
所有产品都值得用AI去重新做一遍。其根本原因在于当下AI的形态即生成式模型是通过AI辅助来改变和创造新的产品形态，而不是像以往的技术一样只是对现有产品形态的补充。简单来说，产品研发同学可以做的事情更多了。
早期的深度模型专模专用，严重依赖有监督学习，这就需要大量的任务相关的人工标注数据，代价昂贵。天下苦标注久矣，如果能够有一个与具体任务无关的大模型，只要利用任务相关的少量数据微调，就能够大杀四方，岂不美哉。
ChatGPT 的技术结构，大家应该都有被科普到，其实就相当于续写，我们给出上半段，它来生成后半段，所以也被叫做生成式的预训练 Transformer 。而所谓的涌现出的能力，可以理解为我们给它提出不同的问题，它在续写的过程中，或者在不同的能力表现上，达标了过线了，再或者说，能力可用了。随着模型参数指数级的增长，之前，很多问题上不及格的回答，逐步变得及格、变得可用，这就是涌现的逻辑。当然，从结构上来说，大模型是一个数学逻辑，也就是说，底层是数学或者计算，但运作方式上是语文，所有问题，都以对话的形式予以反馈，而它表现出的能力却又是跨学科的。所以我们可以从不同的层面上，用不同的词来形容它。但底层的根本能力，都是计算。这就有点像我们上学时说的题海战术。所谓题海战术，就是我们做的题多了，看到题干，就知道要写什么答案，这个过程，我们可能并没有过多的思考或者甚至没有思考。而对于大模型来说，我们喂给它的语料，就相当于海量的题目，当大模型收到某一个类似的题目时，也就能自然地给出答案。
大模型在两个方面有得天独厚的优势
- 理解能力很强，可以准确的理解人类的自然语音到底是什么意思。
- 推理能力很强，可以根据已有的信息，推断接下来要做什么。
PS：模型越大越好，但7B模型单个GPU就能跑，更适合需要低延迟的任务，比如实时的代码补全。 |模型规模临界点|涌现的技能举例| |—|—| |7B|内容毒性分类（判断文本是否恶劣、有攻击性）| |13B|3位数加减法| |62B|CoT多步推理| |68B|数学概念问题的CoT推理| |175B|4~5位数加减法/讽刺内容识别/针对学生的问题进行解释并评估|
大佬观点
孙志岗：如果你是一个产品经理的话，你可以想想自家的产品中，有哪些部分是文本进文本出。因为大语言模型最擅长处理的就是文本，甚至说只会处理文本。它把所有的内容都当作文本处理。像客服系统就很典型，用户提问，进来一段文本，客服系统回答， 再返回去一段文本。你可以想想哪些场景里是文本进文本出，然后看看能不能用 AI 优化，比如让它变得自动化一些，或者效果好一些、成本低一点。不一定产品的呈现上非得有 AI 味，你可以把 AI 融入到冰山之下。然后在这个基础上，随着多模态能力的提升，你可以再看看能不能有图片进文本出，或者文本进图片出的场景，一步步朝多模态的方向延伸。 池：难道 AI 大模型就没有创造出来新场景吗？ 孙：至少从现在的角度看，我只发现了一个场景是 AI 创造出来的——Character.ai 干的事儿。之前没人觉得和虚拟人物聊天有这么大的需求，现在，大家乐此不疲。并且，没有大模型之前，就算你知道有这种需求，也实现不了。还有 GitHub Copilot 它是完全基于大模型的创新，并且想象空间很大，这些年来，不管是框架，还是低代码之类的产品，其实都在解决代码生成的问题。现在，大模型技术的突破，更优雅又具效率的解决了这一问题。
姚志强：以前我们做的小模型，是就很像是人类的社会分工，直奔目标，比如这个算法就只做人脸识别、车牌识别，我去收集数据标注数据，然后去训练它，未来的可扩展性其实就没有很多。但现在大模型的训练，是将它真正作为一个人来训练。我们用专家知识去引导他，给他启发性的这样思维，真正的去教导他去引导他，这是出现了“涌现”现象的原因。
- 未来，产品和技术演进思路全都要重新迭代，可能我们不会再有所谓的语音识别、自然语言理解、图像识别这些技术分类，剩下的只有AI——你是不是一家AI公司？判断AI基础能力的标准，可能就是大模型做得如何，在这个基础上再谈其他的行业模型、场景应用。
- 对我们整个产品体系来说或产品架构来说其实影响不太大，更多是提升了我们的性能。原先我们可能说要不断的要在这里面添加小模型，那现在，我只要替换成一个大模型。而中间可能会有一些特殊的行业线应用我可能会变成行业模型。
- 我们所说的人工智能三浪，第一浪是做是做单点的AI技术，比如做人脸识别、车牌识别，这是小模型时代了；第二浪是指把很多的技术进行组合，就串联起来，做成一个业务闭环，解决客户的实际问题，这里的流程会比较长，有时候可能不会因为一个点的技术提升就会导致整个流程有很大收益；第三浪是AI将成为未来世界的入口，形成平台和生态。我们认为，现在属于二浪到三浪的共振的时期。改变未来的交互的入口，大模型确实在做这样的事情。
池建强：未来企业，AI 会成为一个生产要素。除了员工之外，还会有一批“AI 员工”。AIGC 在应用上确实是超出所有人预料，但 ChatGPT，从技术视角来看，其实没有太强冲击性。技术的发展是线性的，只是公众的感知是阶段性的。AI 发展，到现在真正有突破性成功的有 4 个阶段。
- 人来写规则，用人的经验来写程序。把专家的经验变成程序这个事现在业界还在实践。
- 机器利用数据，写少量的规则。这时候开始有一些模型，比如决策树、简单的神经网络。
- 机器用海量的数据，写大量的规则。这其实就是深度学习，或者叫专用大模型。广告、人脸识别就是用的这个。每个模型，只能解决一个问题。
- 通用大模型。海量的数据，同一个模型，解决不同的问题。形式都是 Transformer 的续写形式，但能力是多样的，比如问答、总结、扩写。
- 张亚勤：我觉得可以把GPT这个系列的生成式AI模型看作一个由大模型组成的AI操作系统，和PC上的Windows，以及移动的安卓、iOS基本具有相似的意义。一个新的操作系统出来是什么意思？下面的硬件、上面的应用都会被重构、重塑，形成一个新的生态。
- 生成式对话产品会颠覆搜索引擎现有的商业模式，科技公司不得不自我革命。你也会这么认为吗？我觉得不是。要是你没有这个产品的话，别人会革你的命。我们在搜索的时候，其实是在找知识，那现在有了生成式技术，它确实提供了一种找到知识的新能力。
对于2024年初的大模型，我们期待什么？以前门槛很高的各种NLP task，现在统统变成了低成本的Prompt Engineering；以前一项NLP任务需要高阶的算法工程师工作个把月，现在只需一名毕业生写写prompt，一两天就能搞定。以ChatGPT为代表的产品，在非常广泛的领域内证明了这种技术模式的有效性。你可以让ChatGPT帮你写文案，做总结，改写段落，做翻译，提取信息，写代码，等等等等。以前很难想象，这么多艰难的任务，底层都是基于同样的一套技术基础构建出来的。几乎任何问题你都可以向它提问，并得到答案。所以，基于大语言模型的to C的产品，天生就是超级App的形态。但大模型到底学到了哪些能力？当我们试图对这些能力进行分类时，却发现非常困难。我们都知道，在最底层，大模型是通过预测下一个token来工作的。但在如此细的粒度下，我们几乎无法进行有意义的讨论，也没有办法把能力与场景相结合。因此，我们稍微抽象一层，但不追求穷尽的描述（这过于困难）。我们接下来主要讨论其中的两大类能力：一大类是「知识」类能力；另一大类则是「格式生成」类能力。
- 什么是知识呢？这其实又包含两种：
- 事实性的信息。比如历史知识或地理知识，长江的发源地在哪？这些知识在大模型内部的编码，很可能更接近一种低层次的「记忆」。
- 抽象类知识。自洽的、没有逻辑矛盾的一个概念体系，它基本上能够用概念的内涵和概念之间的关系来表达。比如，数学概念和定理，物理学定律和公式，再比如生物分子的结构和功能。从需求角度来说，人们获取事实性的信息，通过信息检索的方式也能完成。而抽象的知识才是大模型能够体现智能的地方。但这两种知识的界限有时候是模糊的，所以很难区分到底哪些问题应该基于检索，哪些问题只是求助于大模型更好。非必要的检索过程很可能带来相关度不高的内容，从而遮蔽了大模型本来的能力，让大模型沦为一个文本润色工具。所以，未来的技术方案肯定要解决两个关键问题：检索的必要性的问题。如何同时利用好模型外部（检索到）的知识和模型内部的知识。
- 它的天花板有多高？它有没有超过人类的潜力？大模型有可能像人类那样，进行更深层次的抽象吗？也就是「深度理解」？比如研发人员在调研一个复杂项目的技术方案，专利人员在评判一个专利的新颖性和创造性，对于这些场景，我们应该抱有正确的期待。几乎可以肯定，大模型不太可能给出深思熟虑的、确定性的答案。但是，相比人类，大模型有它自己的优势：它在训练阶段「阅读」了超大规模的信息，远远超过一个人类专家。它可以给出非确定性的、但具有启发性的思维线索。
- 关于格式生成和自动化。 大模型不一定非要生成自然语言的文本，还可能生成符合某种「格式」的序列。生成自然语言文本，是为了给人看的；而生成JSON或代码，则是为了给机器读的。一旦大模型可以生成可供机器直接读取或解析的序列，就意味着信息从「无结构」的转成了「有结构」的。以前企业中很多不能自动化的流程，就都可以自动化了。信息一旦被转成「有结构」的，就有机会对接到下游的传统企业软件工具上，从而在更长的pipleline上实现自动化。符合JSON语法格式的生成能力，是从概率到确定性的桥梁。不管是信息提取，还是工具调用，都依赖JSON格式的生成。而调用工具的能力，又是构建更复杂的Agent系统的基础。
业务场景
关于大模型技术的三点思考企业日常经营就是在不断地做决策并执行。决策就是说企业处理一个事情的时候，比如营销、分发，有很多种不同的做法，要选择什么样的做法。但决策类 AI 明显不好做。因为决策，上游需要高质量的数据作为输入，下游的具体服务得靠人提供。
- 先说下游执行服务的人。人的不确定性太多了，你出策略，即使 AI 做得再好，只是辅助，执行如果不到位，数字化也不会有进展。 执行，过去我们是人主要驱动的，即使有 CRM、ERP、HR，都是靠人，用非数字化的方式执行了之后，把结果一项一项填到系统里面去。
- 上游输入的数据也是个大问题。数据怎么来呢？完蛋了，执行的过程绝大多数企业压根没收集到数据。这里的“数据”，不是说你没有历史数据，而是你今天正在开展的业务里边没有足够的反馈数据。什么是反馈数据？员工跟企业之间的数据交换其实有三条通道。
- 接受信息、接受培训，比如视频、文字、PPT；
- 人与人之间的交流，跟同事跟主管跟客户的交流；
- 是用系统。
- 做决策，我们只能用系统里边的这些数据去产生策略，但在这三条路径当中，系统能占多少？系统可能 5% 都占不到， 95% 的时间你是在阅读，在跟人聊天，在写 PPT、填表格、开会，所以95% 的数据都不在系统里。95%都是非结构化的、多模态的，我们没法抽象化、标准化，有的甚至都没法数据化。这是数据的困境。
- 为什么让机器下围棋这件事能搞定，但过去很多的决策 AI 却难以落地呢？因为现实环境太复杂，一些领域内没有像围棋软件这样的系统，比如销售，没有一个销售系统可以记录销售过程中的每一步。但无论现实环境如何复杂，都可以转为一种对话式的沟通，不管是供应链，还是营销。因为我们现在做的工作，就是通过一来一回的沟通解决。一定程度上，我们也可以把“一来一回沟通”这件事比作是数字化转型中的围棋软件。过去没有“围棋软件”，是因为系统没有一来一回沟通的能力，而且我们的软件是固化的，围棋专家只知道下围棋的套路，不懂怎么下象棋。各领域只有各自专用的大模型，得分别开发。现如今大模型的出现，意味着系统具备了一来一回沟通的能力，也就意味着有了围棋软件。而且，现如今的软件，相对来讲有流动性较强的、最普遍的基础——交互式对话，再加上 GPT 模型可以用语文的方式学习所有问题，企业就可以用一套软件，萃取不同行业不同员工的优秀经验，并且用沟通的方式，干预稍微差一些员工，让这个软件被所有人用起来。这意味着，生成式 AI 可以通过对话框的形式，实现机器与人的沟通，抓取到原来系统抓取不到的另外 95% 的数据，帮企业做更多数字化的事情，或者提高数字化转型的效率。核心区别就是，过去的执行是人为，而非数字化，即使有 CRM 或者 HR 这样的系统，我们也只是将结果填入到系统而已，就像两人下棋，我们只是将最后的输赢结果填入到系统中一样。但是在生成式 AI 出现后，通过巧妙的软件设计，可以将业务过程中每一步的数据都记录到系统中。当然，以前的也有可以记录每一步的软件，就像「滴滴出行」，但是由于资金、人员等各种限制条件，最终导致了行业软件化的进度缓慢。但有了大模型，这个进度就可以大大提升了。过去我们说的信息化，多是指把所有的业务步骤抽象为表单和流程。但是，抽象为表单和流程，不如抽象为对话加 Word 、PPT、或者 Excel。过去我们经常听到企业自嘲说自己的数字化特别落后，基本都是基于 Excel 在做。其实，这反而是一个比较经济的数字化方式，Excel 功能非常强大，是一种表格式的生成软件，只是很多人不会用，数据难以得到有效利用。现在，生成式的 AI，其实就是用对话的方式，加上一些多模态，来标准化的生成软件，实现了从菜单式到对话式的交互进化。PS： 一个模型一个task，一个工作一个软件（还只是负责了录入的部分），很多工作非标连软件都没有。
- ChatGPT 让业界重拾了对 IM 机器人的重视，都认为对话框是数字化的最佳解法，这应该是轻物理资产、重人力要素的互联网企业的限定答案。在其他场景比如物流、驾驶、医疗中，人和机器的交互可能需要其他形式。医生做手术的时候能点对话框吗，不能，但他可以说话，这是一种交互状态；司机开车的时候能点对话框吗，也不能，但是可以用动作，这也是一种交互状态。所以 AIGC 这个事发展到未来，人和机器一定会是多模态的交互，而且是更接近于人的自然能力。IM 只是中间的一个过渡状态。从软件、表单过渡到 IM，中间从共享文档，变为对话框，再到未来的多模态拟人化交流，这个过程是愈发朝着“人”的角度发展的。我们看早期的输入法，在算力不足的情况下，我们必须要学习五笔字型，后来变为智能拼音、整句智能、语音转写，再到后来的直接语音，这条发展路径，是从人类被迫适应机器，到机器更加符合人性，我们可以跟软件、系统进行无障碍交流。
- 过去我们常说，真正能够成功的 SaaS 系统非常难做。SaaS 公司每天都面临着到底是定制化还是标准化的问题。那我们能不能两者兼得呢？可以的——降低定制化成本，用标准化的成本完成定制化的需求。当然，如果是按照传统表单式、流程式的软件，是无法达成的，但 AIGC 可以：基于生成式的大模型，，将一部分需求转嫁给算力，一部分转嫁给企业自身对业务的理解，同时将中间部分做薄，进而逐步解决问题。PS：一般业务系统通用性停留在一个很低层级，对于特定需求，要么做一个专门的页面（在一些场景这些需求无法穷尽，比如数据分析系统），要么人工把基本功能串起来（对系统很熟），而LLM 有可能基于较低级的通用能力，实现能力的编排，减少这些专门的页面。
KubeEye：Kubernetes 集群自动巡检工具 常规的巡检工具只能给一个错误event统计、按一定规则算个健康分 ==> 使用 ChatGPT 诊断 Kubernetes 问题 - K8sGPT 有了GPT 就可以更进一步怎么办（之前凭借工程师经验），再进一步，可以通过LangChain等工具排除直观一些的比如“版本不匹配”等错误原因。
default_prompt = `Simplify the following Kubernetes error message delimited by triple dashes written in --- %s --- language; --- %s ---.
Provide the most possible solution in a step by step style in no more than 280 characters. Write the output in the following format:
Error: {Explain error here}
Solution: {Step by step solution here}
Error node3 has multiple conditions of type MemoryPressure,DiskPressure,PIDPressure and Ready with reason NodeStatusUnknown caused by Kubelet stopped posting node status. Solution:
1. Restart kubelet service od node3.
2. Check node3's connectivity with the control plane.
3. Check if the kubelet version is compatile with the control plane version.
4. Check for any issue with the underlying hardware.
- 前几年，在数字化转型中，企业将一些简单的体力劳动、能总结出规律的活动，写成具体的程序，通过自动化校对的方式来实现。未来，情况可能会发生变化。大模型不但能够替代一些简单的体力劳动，还能替代一些简单的脑力劳动，甚至包括那些能够从日志里总结出经验的脑力劳动。
- 之前，企业数字化主要针对企业内部的交易数据和核心业务系统，对这些数据通过数据挖掘的方法进行建模，实现降本增效。随着近些年大模型的高速发展，对话数据成为企业愈发重视的数据资源。无论在现阶段还是未来，无论是企业与外部客户沟通还是企业内部员工的培训和协作，对话都一直是最主要、最自然的交互形式。在这期间，会产生很多对话数据，包括线下营销和线上营销、文字沟通和电话沟通等场景。过去，企业的数据只是存了下来，并没有进行结构化的表示和挖掘，更遑论理解这些非结构化数据中蕴含的语义，提取出智能服务。企业希望充分利用对话数据、挖掘对话数据的价值，从而更好地服务于数字化的需求。比如通过电子工牌或呼叫中心将销售过程录下来，采用 ASR 语音转写技术将录音转成文本；再通过对话文本挖掘出用户的意图；随着对话过程不断进行，大模型可以实时生成流程图谱，给销售提供对话建议，分析潜在的话题引导方向，提升销售人员的营销技能，提高成单概率和用户的留存率。
- 简单的应用，比如提供数据源(日历)和弱控制（家电控制），会被大模型系统聚合，这些应用蜕变成一个Plugin接入到这个大模型系统中，成为南向，而大模型系统则变成了一个超级应用，为所有这些plugin提供自然交互和控制能力，典型的例子是ChatGPT Plugin体系。
- 复杂的应用，则会被重构，演进到AI Native的架构，特点就是与大模型结合，使用大模型系统提供的SDK，实现全新的交互、控制和认知能力，成为大模型系统的北向，比如微软 365加持copilot，为365提供：
- 内容生成—释放创造力，word/ppt/excel等内容生成，帮你写草稿；
- 推理和归纳—释放生产力，自动执行任务/内容总结/自动回复邮件等；
- 提升技能：原来90%没有被大家普遍使用的功能和特性，都逐步被挖掘出来，比如在Excel中大量的公式，以前需要熟手才能使用，现在通过自然语言的交互和理解，就可以轻松使用。
从原理到应用，人人都懂的ChatGPT指南按照感知其能力的直观性
- 聊天即交付（Chat to Delivery(C2D)）。聊天能力，GPT的回答就是给客户的交付物，是GPT模型最简单、最直观的用法。
- 套壳聊天机器人
- 场景化问答。 对GPT的回复场景进行了约束。通过限定提示词、嵌入大量特定领域知识以及微调技术，使GPT能够仅基于某类身份回答特定类型的问题。对于其他类型的问题，机器人会告知用户不了解相关内容。
- 语言能力。需要使用one-shot或few-shot（在提示词中给ChatGPT一个或多个示例）来提升ChatGPT的表现。与用户的交互不再局限于聊天窗口，提前预制提示词模板，用户只能输入限定的信息，对应提示词的空槽位。将用户输入 放入预制好提示词模版的指定槽位，传给GPT。
- 文本能力，使用few-shot技巧，能解决训练数据中不存在的问题。
- 推理能力，用ChatGPT理解人类意图的能力，以GPT的推理能力替代手动点击操作流，将带来B端和C端的产品设计的颠覆式变化。
企业会根据三大能力衍生出三大类角色：
- 问题分解者，这类角色很清楚大语言模型能力的边界，能够将一个业务问题有效的分解为GPT能处理的子问题，并能根据问题结果，将子问题进行拼装。
- 提示工程师，这类角色深谙与GPT沟通之道，能够根据不同的问题类型，给出有效的提示词模板，极大提升GPT的输出质量。
- 知识拥有者，这类角色有大量的行业knowhow，并且能够将知识进行结构化，传授给GPT。对应现在的领域专家。
基于某个规则让大模型帮忙筛选简历。一些简历pdf，从中提取特定信息，组成json 返回。再进一步，可以提出自己的需求，让大模型筛选出最接近满足需求的。
LLM 距离 AGI 的一大差距是没法与真实世界连接。LLM 应用开发全栈指南以 SQL 工具为例展示了下 LLM 如何来利用外部工具。根据自然语言生成SQL语句（Text2SQL）大致为以下几个步骤：
- 用户问了一个问题
- 将用户问题和数据库的 meta 信息放到 prompt 里，让 LLM 去生成 SQL
- 利用数据库来执行这个 SQL 查询，这就是工具的调用
- 将数据库查询结果与问题再扔给 LLM 做最终回答
当然这个步骤可以说是由 Chain 定义固定下来的，也可以采用类似 agent/plugin 的方式来让 LLM 自行决定在何时使用什么工具。用户只需要提供 API 的 spec 和描述，就可以快速接入到 plugin 体系中。这两种方式主要的权衡在于可靠性或者是流程的确定程度。Chain 的运作流程是人工定义好的，流程不会出错，且对 LLM 来说生成具体的工具指令也会准确率更高。而 plugin 的优势在于极大的流程灵活度，可以用统一入口满足用户各类诉求。虽然可靠性会下降不少，但也可以考虑引入人工交互来弥补。
2024 年，基于大模型的 Agent 如何在企业落地？ toc
- 个人提效，当下代表性产品：Microsoft 365 Copilot、 WPS AI
- 面对的主要是个人职场需要的通用技能场景，解放重复的脑力劳动，总结汇报，创意探索等。
- 针对专门岗位的工具，比如运营的文案撰写，方案策划；产品经理的 PRD 撰写，利用 AI 做用户洞察/需求分析；帮助律师生成合同审核报告等。
- 内容平台，当前的算法推荐方式是因为内容供给有限，AI 理论上可以带来无限的内容供给，每个用户所需的内容都可以即时生成，那还需要算法推荐吗，比如我想要看皮克斯动画风格的《繁花》，使用相应的提示词直接可以进行另类剧情的演绎，Midjourney 只是用来创建旧媒体的工具，还是说它本身就是一种「新媒体」？
- 虚拟社交类，当下代表性产品：Character.ai、Glow（国内）
- 数字助理，当下代表性产品：软件 Rewind，硬件 AI Pin，端侧模型的能力决定发展的潜力，RWKV值得关注。App 与操作系统定义一套协议接口，系统级别的 AI 助手作为统一入口，可以随意操作 App tob
- toB 工具改造，面对当前的 AI 输出不可控的现状，用 AI 做分析比生成更有潜力，toB 工具 AI 改造是非常有价值的实践方向，强大的 SaaS 工具，往往并不能真正给客户交付结果，因为你太强大了，他不会用。而简单的智能化的系统既可以给用户建议，又能自动化执行，某种程度上就是直接交付结果。
- 重塑工作流
- 作为工作助手（Copilot），在此模式下，人类发出指令，AI 代理执行面向特定软件的操作，以提高员工的办公效率。
- 业务自动巡航，它代表了一个新的用户接口，能够承接大量业务逻辑，无需用户学习即可使用，从而提供更佳的使用体验，如 AutoAgents.ai 平台在航班预订、员工服务和会议管理等方面已初步落地。
- 自主智能体（Autonomous Agents），具备完全自治的能力，能够自主完成目标理解、规划、执行和反馈迭代等多项任务。
大模型元年，万能的淘宝有了万能AI 购物从需要明确知道要买什么，去搜索。变成了只要有需求，都可以询问AI。
大模型BI：商业智能背后的3大关键技术LLM就像一个刚进公司的实习生，名牌大学毕业，基础知识储备扎实，但还是需要一个老师傅告诉他每一步该怎么做，他才可能完成任务执行。如果我提出这样的问题：“我该怎么做才能提高整体销量？”，那就要看是零售行业还是制造行业，每个行业的分析思路差别巨大。如何让大模型从一名实习生成长为一名资深从业人员，解决更有难度的问题，首先要深入行业内部，自己成为那个资深人员，才可能知道如何将行业知识与大模型深度融合，这里不是简单的堆数据做训练，然后发布XXX-GPT。
这一轮技术革命的真正“终局”是什么样子
LLM的强大之一在于其能够将众多的NLP下游任务都转换成统一的形式。即LLM可以定义为求解P(output | input, task)的过程。如，
-
中英文翻译：P(ouput input=中文文本，task=请将中文翻译成英文) -
找反义词：P(output input=中文词语，task=请找出其反义词)
- 任务规划（Planning），CoT让 LLM 将任务分解为可解释的步骤
- 记忆唤醒（Memory），在神经科学研究中，人类的记忆可分为感觉记忆、短期记忆和长期记忆三种类型。
- 感觉记忆，是人体接收到外部信号以后，瞬间保留的视觉、听觉、触觉的记忆片段，在 AI 系统中类似于高维嵌入表示，也就是我们常说的 “Embedding”。
- 短期记忆，是你当前意识中的信息，在 LLM 中类似于提示词（Prompt）中的所有信息。
- 长期记忆，包含了你能回忆的所有信息，在 LLM 中类似于外部向量存储。 LLM 能“消化”的，只有提示词（Prompt）中的短时记忆，所以你需要在长期记忆中选择最重要的内容放入提示词。
- 驾驭工具（Tools）
以上能力汇总下来
- LLM 在得到任务后，会帮助你制定记忆唤醒方案。
- AI 系统执行该方案，生成相关的查询指令，从外部数据中查询数据。PS：调取外部知识
- 我们将这些数据交给 LLM 来判断是否已获得足够完成任务的数据。如果没有，LLM 会生成新的唤醒方案，并循环这个过程。
- LLM 为指定的需求，找到最合适的工具，再下一步OpenAI 推出的 Code Interpreter 可以制作工具
- 判断任务是否完成，如果没有，则重复上述过程。
LLM 应用的技术层次大型语言模型（LLM）在技术应用层面的三个不同层次：LLM Wrapper、Flow（基于有向无环图 DAG 的流程）、以及 Agent（基于循环加反馈的代理）。
- LLM Wrapper：这是最基础的层次，涉及到与 LLM 的单次交互，可能引入了 In-Context Learning（或称为 RAG）。这种方式的能力上限直接受限于模型的复杂推理能力。比如翻译、总结文档、NL2SQL等。
- Flow（DAG）：在这个层次上，业务逻辑通过有向无环图（DAG）构建，实现与 LLM 的多次交互。每次交互专注于解决一个特定问题，例如意图判断、内容改写、提供回答或批评等。避免让LLM承担全局宏观规划（Planner）的角色，主要是利用 LLM 在处理具体细节问题上的能力。这种方法有效克服了单次交互的局限性，支持构建更复杂的应用。适用于那些对如何利用 LLM 解决业务问题有清晰理解的场景，需要处理更复杂逻辑和提高准确度时采用。
- Agent（Loop）：基于 Loop+Feedback 构建的应用层次。在这里，LLM 能够根据人类输入自主决定和执行所需步骤，完成后自我评估是否存在异常，并据此进行调整。通过这种方式，LLM 能够显著提高结果的准确性，并解决更复杂的问题。构建 Agent 的逻辑与传统应用截然不同，其核心思想类似于构建一个团队或公司，每个 Agent 都是具有一定能力的工作力量。通过大量 Agent 的相互补充，最终共同做出相对合理的决策。
是否自建大模型
自建行业大模型的思考是否需要构建行业大模型？
- 通用 LLM会不会大力出奇迹，在没有经过专业领域数据训练的条件下就可以很好的完成专业领域任务？BloombergGPT的论文中实现表明：基于专业领域语料训练的大模型，在领域内的理解要超过通用大模型；
- 能否通过为Prompt填充领域知识的方式，让LLM具备解决专业领域任务的能力？可以，角色扮演就是一个例子
- 优点：灵活多变，可以适应各种场景，几乎没有训练成本，所有的行业知识通过prompt注入
- 缺点：大量领域知识会限制多轮对话或者prompt构造，模型输入有长度限制，如果加入了较多领域知识，就没有空间留给理会对话以及prompt；对于专业词汇的理解可能不准确
- 能否通过检索的方式，从本地知识库中查找出符合要求的答案返回？可以，例如：插件、AutoGPT
- 优点：没有训练成本；返回结果完全可控，即知识库内容
- 缺点：大模型+检索的方式分成两步走，性能会较慢；回答内容单一，缺乏泛化性；对于专业词汇的理解可能不准确
自建 or 购买
- 购买。
- 数据安全风险；比如使用 ChatCompletion 的接口，需要传入大量的上下文信息。
- 缺乏商业护城河；
- 不够灵活：新的需求和模型效果提升可能需要重新签订协议购买
- 自建。训练成本较高：数据成本、算力成本、试错成本；模型效果难以保证；对于模型训练算法工程师有较高要求。
- 从头预训练大模型实践经验 未细读。
- 如何构建一个好的基座大模型？ 值得细读。
自建大语言模型可能遇到的问题
- 容易解决的问题
- 模型训练方案容易实现，现阶段开源LLM都有完善的训练和推理流程；
- 效果优异的基座模型，虽然中文开源LLM效果还没有英文的那么多、那么好，但是也已经达到了够用的水平；
- 不容易解决的问题
- 明确的LLM需求
- 高级收益需求：某个功能以前无法实现，LLM可以助力实现，并为公司带来较高收益；
- 次级收益需求：某个已经实现的功能，LLM可以对其优化，降本增效；
- 训练数据难以构建，训练数据应该具备一下特征：训练大模型需要巨量数据；涵盖多种问题，同一问题还应该有多种表达方式；数据应该尽量准确，不能含有有毒数据；要包含大量通用文本语料，在二次训练过程中会有灾难性遗忘问题，需要通用语料保持LLM通用语言能力；要包含本公司业务领域的文本语料，提升LLM对于行业数据理解能力；最好包含多轮对话语料，使模型具备连续对话的能力；最好能有同一个问题的不同得分的回答，实现RLHF的训练
- 部署成本高昂：
- LLM模型参数量巨大，一般自建模型参数量最小是7B，需要占用大量显存；
- 即使使用量化技术，推理服务QPS也不会很高；字节跳动提出高性能 transformer 推理库，获 IPDPS 2023 最佳论文奖 针对自然语言处理常见的可变长输入，论文提出了一套优化算法，这些算法在保证运算正确性的前提下，成功避免了传统实现中的冗余运算，实现了端到端的推理过程的大幅优化。
- 使用量化技术会让模型虽然会提升性能，降低显存占用，但是会极大损害效果；
- 较长的sequence length会占用大量的显存，增加计算消耗（时间复杂度是sequence length的平方）；
- 高性能GPU服务器成本较高
- 大语言模型生成结果不可控：生成模型普遍存在生成结果不可控的问题；需要尝试不同的prompt才能得到令人满意的结果。
- 明确的LLM需求
行业大模型
- 很多人认为行业大模型是用一个7B/13B的模型架构完全用领域数据训练一个模型，因为参数量达到了“大”的标准，数据完全用的是行业数据，就称作行业大模型了。我是很反对这个做法的，大模型（foundation model其实是更准确的说法）的过人之处不是因为参数量大，而是因为通用（跨领域的通用）以及追求通用的过程中涌现出来的能力，完全用领域数据只是之前模型训练方法的改变，和大模型的核心“通用”没有任何关系。这类做法只是对大模型的生搬硬套，对解决领域问题和传统方法并没有很大的帮助。
- 行业领域数据，有两类用法，第一类是用行业数据对通用模型进行继续训练、微调等一系列改变模型权重的方法；第二类是不改变通用大模型的权重，用in context learning的能力通过prompt注入领域知识，或者利用外挂数据库的方式。前者由于改变了模型的权重，可以称作是训练（微调）了一个行业大模型，后者则基本只能认为是通用大模型的应用了，因为模型还是那个模型。大模型解决行业问题的几种做法
- 使用通用数据和领域数据混合，from scratch（从头开始）训练了一个大模型，最典型的代表就是BloombergGPT。
- 在一个通用模型的基础上做continue pretraining（继续预训练，二次预训练），像LawGPT就是做了二次预训练的。身边有很多人尝试过这个方案，但普遍反应效果一般（没有SFT来得直接），很有可能是数据配比的问题。
- 在一个通用模型的基础上做instruction tuning（sft），这也是现在开源社区最普遍的做法，有大量的工作比如Huatuo，ChatLaw等等。这种做法的优势是可以快速看到不错的结果，但会发现要提高上限比较困难。
- 领域知识库加上通用大模型，针对通用大模型见过的知识比较少的问题，利用向量数据库等方式根据问题在领域知识库中找到相关内容，再利用通用大模型强大的summarization和qa的能力生成回复。
- 直接用in context learning的方法，通过构造和领域相关的prompt，由通用大模型直接生成回复。随着业界把context window越做越大，prompt中可以放下越来越多的领域知识，直接用通用大模型也可以对领域问题有很好的回复。
- 可见，训练行业大模型是一个variance特别大的事情，可以像1一样几乎重新训练一遍模型，需要几百张卡，也可以像3一样用几百条数据做做sft，可能几张卡就够了。4和5就只是使用了通用大模型来解决行业问题，很难称之为训练了行业大模型。
- 通用大模型的核心能力可以从两方面来看：「知识」和「能力」。
- 首先，从能力角度看，用简单的比喻可以把能力理解成智商。通用大模型很厉害的一点就是通过对大量通用知识的压缩，训练了一个智商超高的模型，正是因为模型智商超高，才能对大量不同的任务通过in context learning的方式一学就会。
- 从知识角度看，通用大模型看过多少数据就能压缩多少知识，对于没看过的领域数据，通用大模型没有这方面的知识是肯定的。如果模型在使用行业数据微调（重新）训练时见过这方面的知识，就有可能回答出这样的问题。但我们需要通用大模型做的是知识查询类的事情吗？如果是的话，用外挂知识库的方法是不是更容易解决。而对于外延性知识，比如对未来的预测，根据事实进行判断，逻辑推理等，有没有相关知识可能就不是最重要的因素了，更重要的还是模型的能力。
- 因此，行业大模型可能是「通用大模型能力不足时的阶段性产物」。ChatLaw就是个很好的例子，一方面大家需要对一些不常见的法规进行查询，另一方面通用模型对法律问题的处理能力不强需要大量的法律数据进行微调。但长期来看，通用大模型可能是更本质的解决行业问题的方案，可以将行业知识以知识库的方式输入给通用模型，可以是外挂知识库也可以直接就在context里面描述了（行业知识是行业内比较本质的东西，通常不应该特别复杂；比如物理或数学，只要几个公式讲清楚基本逻辑就行了），通用大模型强大的能力可以根据知识进行演化，最后通用大模型在行业问题上会比行业大模型表现地更好。在这种前提下，只需要告诉模型基本的法规，就可以解决所有法律问题，所有的历史案件对模型来说都没有正收益。当然，这个过程可能很长，但如果我们相信通用大模型是相信AGI的话，这应该是一条更正确的路。
- 写一个和行业大模型相关的重要问题：数据配比。经常会被问到的问题是，用了大量的行业数据，模型怎么反而变弱了。
- 由于没有大量的资源做from scratch的通用数据和领域数据配比的实验，个人的经验完全来自于continue pretraining和sft。对continue pretraining来说，如果要让模型不丢失通用能力，比如summarization，qa等，「领域数据的比例要在15%以下」，一旦超过这个阈值，模型的通用能力会下降很明显。所以，在做领域数据continue pretraining的时候，一定更要混大量的通用数据。
- 对sft来说，这个比例就可以提高不少，大概领域数据和通用数据比例在1:1的时候还是有不错的效果的。当然，如果sft的数据量少，混不混数据的差别就不太大了。所以说，做pretraining不仅耗资源，需要大量的卡和数据，还需要大量的实验去调数据配比。
- 所以，个人对解决行业问题的建议是，看要解决什么问题。简单的问题，写写prompt就行了，prompt写好了很多时候比sft还管用，再配上向量数据库，其实70%能解决的行业问题用这个方法就解决了；稍微复杂点的问题，做一下sft，稍微混点通用数据，别全用领域数据做指令了，剩下的30%能解决的行业问题就靠这个方法了；更复杂的问题，再等等吧，通用大模型还没发展到那一步，别期望太高了。
用好大模型
面向领域应用的大模型关键技术ChatGPT这类大模型在开放环境下的人机对话或闲聊已经取得显著效果，但其解决实际工作中的复杂决策任务存在差距。领域应用的本质是复杂决策。通用大模型具备宽广的知识底座，具有宽度有余但深度不足。然而，在解决实际问题时，例如运维问题，如果没有设备相关的知识，是无法胜任运维任务的。因此，大模型需要具备专业知识的深度和长程推理的能力，才能在垂直领域落地应用。另一个无法回避的问题是大模型的”幻觉”问题，即一本正经地胡说八道问题。大模型的幻觉问题，其自身经过优化之后能够解决么？比如使用更多的训练数据，更充分算力的训练。理论上ChatGPT这类大模型是概率化的生成式大模型，只是根据他们所看到的内容生成最有可能的下一个单词，而没有进行任何事实核查或推理，仍然会以一定概率犯错。此外，大模型缺乏对于给定信息的”忠实度”。在领域任务中，我们需要大模型遵循特定领域的规范、制度、流程和知识进行回答。然而，如果没有进行适当的调优，大模型往往会抛开给定的文档或信息，而倾向于利用已习得的通用知识进行自由发挥，大模型的答案仍然有可能超越给定的范围，从而产生错误。
为了让 LLM 能够回答那些它最初未接受训练的内容，用好大模型的第一个层次，是掌握提示词工程(Prompt Engineering)，用好大模型的第二个层次，是大模型的微调(Fine Tuning)。
大模型研发核心：数据工程、自动化评估及与知识图谱的结合 值得细读
评估
ICL 和 CoT 都是大语言模型具有涌现能力的证据。为了证明涌现能力，主流的 LLM 大多采用了人类最古老的方法，那就是“考试”。GPT-4 已经在很多人类的考试中取得了高分，比如 SAT、AP、GRE 等等，甚至还通过了模拟律师考试，分数在应试者排名前 10% 左右。这当然是对涌现能力最直观的证明。根据 Google、Stanford 和 DeepMind 的研究，经验判断是模型参数至少需要达到 68B（十亿级别）的基本门槛，最好超过 100B。不过，这与任务类型和具体模型有关。在 ICL 情况下，一些简单任务，如三位数的加减法，只需要 130 亿参数，而较复杂的任务，如多义词判断，则需要 5400 亿参数。总之，68B 是一个基础门槛，目前效果最好的大语言模型通常超过 100B。PS： 所以70B是工程和能力的平衡。
LLMs评估综述-A Survey on Evaluation of Large Language Models
LMOps的评估环节主要是评估数据集，评估方法。
- CUGE评测集是一个广泛采用的中文分词评测集，用于评估不同分词系统的性能。它包含了大量的中文文本数据和标注好的分词结果，可以用于训练和测试分词模型。
- MMLU 是一个用于在零样本学习和少样本学习设置下评估模型的基准测试集。涵盖了57个科目，包括STEM、人文科学、社会科学等，难度从初级水平到高级专业水平不等，是目前主流的LLM评测数据集。MMLU是一个多项选择题测试，每个问题有四个可能的答案，主题的细粒度和广度使得该基准测试非常适用于发现模型的盲点。
护栏：确保产出质量
试图越狱人工智能模型，让它们说坏话或做坏事，已经成为一项在线运动。虽然有些人可能会觉得让 ChatGPT 发表有争议的言论很有趣，但如果客户支持聊天机器人（带有您的名称和徽标）做同样的事情，那就没那么有趣了。这对于有权使用工具的人工智能系统来说尤其危险。为了解决这个问题，应该首先在系统上设置护栏，以便不会自动执行任何有害操作。例如，未经人工批准，不能执行可以插入、删除或更新数据的 SQL 查询。这种增加的安全性的缺点是它会降低系统速度。
在应用层面，我们不要让用户和模型直接交互，模型只是我们服务用户流程的一个环节，用户提问之后，应用交给模型，最终输出是否靠谱，应用可以再做一层判断。
如果我们无法判断模型生成内容的真实性，则大模型的价值将停留在文本续写、文本摘要、信息抽取、头脑风暴任务上，而决策分析、应急管理等高价值应用场景的贡献是有限的。
BaiChuan2技术报告细节分享&个人想法模型安全性不仅需要模型对齐阶段解决，预训练阶段要需要考虑。
- 预训练阶段：对数据进行清洗，过滤消除暴力、色情、种族歧视、仇恨言论等有害内容，并且构造了中英安全数据预料包含各种积极价值数据，在数据采样过程中，提高这些数据的采样率。
- 对齐阶段：10个有传统互联网安全经验的专家构建6种攻击类型和100+细粒度安全价值类别，由50人标注团队生成200k攻击性提示，进行模型安全性对齐训练。
在LLMs的背景下，防护栏验证LLMs的输出，确保输出不仅听起来好，而且在语法上是正确的、事实准确的，并且没有有害内容。它还包括防范对抗性输入。
- 通过提示来控制模型的回应。
- 验证输出。比如Guardrails包允许用户通过Pydantic风格的验证在LLM输出上添加结构、类型和质量要求。如果检查失败，它可以触发纠正措施，比如对有问题的输出进行过滤或重新生成另一个响应。
技术实现
LLMOps的现在与将来 使用LLMs制作一些很酷的东西很容易，但是很难使它们成为生产型的。LLMOps是针对LLM的MLOps，我们的重点不是从头开始训练LLM，而是适应预训练的LLM用于下游任务。这涉及选择基础模型、在下游任务中使用LLM、评估它们以及部署和监视模型。
- 选择基础模型。主流是Decoder-Only,但Encoder-Decoder仍有前景。如何挑选基座模型：模型的效果，推理速度，context大小、价格开销，能否微调，数据安全，许可协议等。
- 适应下游任务。 主要挑战在于，尽管LLM很强大，但它们并非万能的，因此关键问题是：如何使LLM给出您想要的输出？
- Prompt Engineering，是一种调整输入以使输出与您的期望相匹配的技术，已经出现了像LangChain或HoneyHive的工具，帮助您管理和版本化提示模板。guardrails/guidance封装了输出的结构化检查和修复（如果不符合格式，生成相关错误信息，将上一次的生成内容和检查的错误信息告知 LLM，进行下一次的修正生成，直到生成的内容完全符合我们的要求）。
- 构建高性能 Prompt 之路——结构化 Prompt
- https://github.com/dair-ai/Prompt-Engineering-Guide
- Fine-tuning pre-trained models，可以帮助改善模型在特定任务上的性能。虽然这将增加训练工作量，但它可以减少推理成本。LLM API的成本取决于输入和输出序列长度，因此，减少输入标记的数量可以减少API成本，因为不再需要在提示中提供示例。 一般来说优先选择前者， 尤其是当前开源模型，fine tune 技术都没有那么成熟的情况下。什么时候需要 fine tune 呢？
- 你需要节省成本，比如用更小的模型，不想每次都带一大段 prompt 之类。
- 你有大量的数据，且 retrieval 的方法表现不够理想。
- 低秩适应/LoRA 与 QLoRA 训练技术 https://github.com/microsoft/LoRA 。对预训练好的大模型参数进行冻结，也就是在微调训练的时候，这些模型的参数设置为不可训练。然后往模型中加入额外的网络层，并只训练这些新增的网络层参数。这样可训练的参数就会变的非常少，可以以低成本的 GPU 微调大语言模型。LoRA 在 Transformer 架构的每一层注入可训练的秩分解矩阵，与使用 Adam 微调的 GPT-3 175B 相比，LoRA 可以将可训练参数数量减少 10000 倍，GPU 内存需求减少 3 倍，并且在效果上相比于传统微调技术表现的相当或更好。huggingface/peft
- 量化推理/后训练量化是指在模型训练完成之后进行量化，模型的权重会从 32 位浮点数（或其他较高精度格式）转换为较低精度格式，例如 4 位整数。这种转换大大减小了模型的大小，并减少了运行模型所需的计算量。但是，这也可能会导致一定程度的精度损失。 GPTQ（Generative Pretrained Transformer Quantization）是一种新的后训练量化方法，可以有效地执行对有数百亿参数的模型的量化，并且能够将这些模型压缩到每个参数 3 或 4 位，而不会有显著的精度损失。
- 外部数据，已经有一些工具可用，例如LlamaIndex（GPT Index）、LangChain或DUST，可以作为中央接口连接（“chaining”）LLM和其他代理和外部数据。
- 嵌入/embedding，从LLM API中提取嵌入形式的信息，（例如，电影摘要或产品描述），并在其上构建应用程序（例如，搜索、比较或推荐）。如果 np.array 不足以用于长期存储您的嵌入，可以使用向量数据库，如Pinecone、Weaviate或Milvus。PS：LLM加向量数据库这个范式，很像一个硬盘巨大但内存很小的电脑。随着LLM 支持更长的context，向量数据库可能会过时。
- Prompt Engineering，是一种调整输入以使输出与您的期望相匹配的技术，已经出现了像LangChain或HoneyHive的工具，帮助您管理和版本化提示模板。guardrails/guidance封装了输出的结构化检查和修复（如果不符合格式，生成相关错误信息，将上一次的生成内容和检查的错误信息告知 LLM，进行下一次的修正生成，直到生成的内容完全符合我们的要求）。
- 评估，如何评估LLM的性能？如何确定响应是好还是坏？LLM 的能力非常强大，能处理各种任务，这对其评估造成了很大的困难，比如我们很难判断一篇总结是否比另外一篇总结写得更好。对于不同的 prompt，模型甚至 fine tune 的效果，如何进行快速，低成本且准确的评估是一个大问题。目前，似乎组织正在对其模型进行A/B测试。为了帮助评估LLM，出现了像HoneyHive或HumanLoop这样的工具。PS：一个办法是做好业务与大模型交互的抽象，没事按大模型榜单多换换，看看效果。
- https://github.com/PKU-YuanGroup/ChatLaw 如何合理地评估垂直领域大模型的性能一直是一个问题，因为测试数据和真实场景存在差异，我们暂时没有完美的思路。我们只是收集了十余年的国家司法考试题目，整理出了一个包含2000个问题及其标准答案的测试数据集，用以衡量模型处理法律选择题的能力。
- 部署和监控，例如，OpenAI已经更新了其模型以减轻不当内容的生成，例如仇恨言论。目前已经出现了一些监控LLM的工具，如Whylabs或HumanLoop。
假设一个场景，我希望chatgpt是个咨询专家，他可以回答我的一些问题。我问chatgpt一些问题，它会基于外部数据库和自身的能力给我回复。 这里会有两个问题需要考虑：
- 提问的技巧，就是现在人们在热烈讨论的prompt engineer，是一种调整输入以使输出与您的期望相匹配的技术。PS：有点像 RHLF之后的二次对齐
- 如何利用外部知识，LLM通常缺乏上下文信息（例如，无法访问某些特定文档或电子邮件）并且可能很快过时，因为LLM如果没有足够的信息会产生幻觉，所以我们需要能够给它们提供相关的外部数据。
由于LLM生成结果的不确定性和不准确性，目前还无法仅依靠LLM提供智能化服务。构建GPT应用远远不是调用API。PS：就像操作linux 远远不止调用系统调用，有很多工程问题/发挥空间。
- 它的“脑子”也不完美，OpenAI 的训练数据截止至 2021 年，并且没有任何企业和个人的私有数据，这让模型只能根据自己的“记忆”回答问题，并且经常给出与事实相悖的答案。一个解决方法是在 Prompt 中将知识告诉模型，但是这往往受限于 token 数量，在 GPT-4 之前一般是 4000 个字的限制。
- 它只有“脑子”没有“手臂”，无法在外部世界行动，不论是搜索网页、调用 API 还是查找数据库，这些能力都无法被OpenAI的 API 提供；说白了只使用openAI不是商业应用，不能产品化。
其它
