大模型(以下称作LLM)经历了2023元年的爆发,和以往的热点不一样,它的热潮依旧没有褪去,时间在证明着这次 LLM 革命性的价值。
然而到目前为止,大部分人的视角,似乎仍然停留在 chat 聊天的层面。这里有两个层面的原因。第一是大模型底层的整个运转逻辑并不被大部分产品、老板、投资人等非技人清晰明了。人们更多的容易被 AGI、聊天等这类空洞或者显而易见的讨论所吸收。真正理解并熟悉大模型应用运转机制的人不多,甚至大量技术领域的人员,也分不清模型训练、提示工程的区分,对 RAG,或者ReAct 之类理解的概念也少之又少,至于中文网上甚至出现了卖课卖出上千万利润的荒唐现象。
另外一个层面,对于从事专业技术,或者 AI 相关行业的人通常又不屑于关注应用和产品层面的理解,他们对大模型的兴趣更容易在底层研究。这是任何新技术早期经常有的现象。
由于近期从事了大量和 LLM 相关的落地工程,深刻的体会到 LLM 应用在真正落地过程各种阻力,以及工作和生活等存在大量误区(也是工作阻力)。我们亟需让 LLM 技术可以更广泛的被理解、被运用、被推动。
本篇是针对想对技术和产品有更好结合的人群,旨在降低产品和技术理解的信息差。
这是一个非常普遍的误解。很多人认为,要让 LLM 在特定业务场景下发挥作用,必须对其进行针对性的训练,灌输业务知识。这些误区可能是来源一些公众号,或者是一些行业模型基座的宣传。
但事实上,通用 LLM 已经具备了广泛的知识和理解能力,通过精心设计的提示和任务描述,就可以引导 LLM 完成特定的业务任务。LLM 的重点能力不在特定知识,而是通用逻辑推理能力。想象一个智商超群,知识能力广泛的毕业生,但“他”入职一家大型金融公司做临时工,规定他期间不允许记忆任何公司机密(我们假设)。虽然在这之前, 他从未学习过公司的业务规则,但是当交代一个客户回访任务,我们只需要给定这个临时宫内部信息资料的查询权限,交代回访的目标、客户信息、相关业务规则手册。这位临时工,将会使用他的通用逻辑能力,先去理解目标,写下来、再去拆解任务,写下来,再根据子任务分门别类去查询每个文档,最后再汇总信息得到结果。最终我们可以发现这个临时工可以不运用任何记忆功能,完成了这一目标。
通用大模型就像这个“临时工”,核心能力在于“通用逻辑推理能力”,而不是业务知识的记忆。
我们在实践中也验证过,即没有经过专门训练的通用 LLM,也能够通过合理的提示,快速适应不同的业务场景,给出令人满意的结果。
得益于 chatgpt 的广泛传播,进入公众视角的 LLM 应用就是聊天。大量诸如编码、文案编写确实可以在 LLM一问一答的对话聊天中获任务结果,但是仅仅依靠一段对话完成任务在使用场景、及效果上会大大受限。
在实际应用中,我们需要将任务分解为一系列的子任务,通过多轮对话和交互,引导 LLM 逐步完成任务。这个过程需要精心设计任务流程和提示策略,而不是简单的一问一答。
这其实就是经常说的 Agent (智能体代理),这种智能体通过结合大语言模型与关键模块,如规划和记忆,来执行任务。构建这类智能体时,LLM充当着控制中心或“大脑”的角色,负责管理完成任务或响应用户请求所需的一系列操作。
形象点说就是上面这个“大学毕业生案例”。一段对话不足以解决一个问题,而是通过多段对化,加上临时记忆功能,拆解不同的任务分支,最终完成复杂的任务。大部分场景都需要多段对话进行强化,而不是简单的调用一个问答 API。
很多人会误以为,掌握了提问的技巧,就掌握了提示工程。但实际上,提示工程远不止如何提问这么简单。它涉及到任务分解、上下文管理、知识引导、结果评估等多个方面。对于多轮对话,整个 Agent 逻辑的设计都是提示工程的一部分,因为我们和大模型交互最终都是通过文本沟通。
设计一个有效的提示,需要深入理解任务的需求和 LLM 的特性(不同模型的反馈有巨大差异),需要不断尝试和优化,需要权衡效果和成本。我们在项目中发现, 仅仅使用类似 COT、TOT等业界已知方案是不够的,大量场景是需要自己反复设计,测试、验证,最终得到在特定业务场景中准确率更高的 Agent 组合。最终结果是一个看似简单的任务,设计出优秀的提示也可能需要几十次迭代。
许多人对 LLM 的性能和能力有着过高的期望,认为只有使用最先进的模型,如 GPT-4,才能实现良好的应用落地。我们在业务验证中,也很经常拿 GPT-4 做测试,效果上可能非常完美的时候,但再转向自己内部的离线模型,如果你只是复制粘体 gpt4 的提示词,失落的神情不可避免。
开源的离线模型和行业 top 肯定在体验效果上的差距不可置否。但我们的经验表明,对于大多数应用场景,目前已经开源的 LLM,如ChatGLM、Qwen、llma2等,已经足以应对。相比模型本身,更重要的是基于模型能力设计合理的 Agent 应用方案,并进行充分的调试和优化。过度追求模型的先进性,反而可能带来成本和效率的问题。我们应该聚焦于应用本身,充分利用现有的模型能力,而不是一味等待更先进的模型出现。
在 LLM 应用的开发过程中,最痛苦的感受是工具和基础设施的匮乏。与传统的软件开发相比,LLM 应用开发缺乏成熟的 IDE、调试器、测试框架等工具支持。
大型语言模型应用通常由多个 LLM 对话调用链式组合而成, prompt 工程技术如提示模版、TOT、ReAct等,都需要将任务拆解成多个细小的对话步骤,才能得到较佳的预测质量。类似 LangChian 这种工具只能解决开发环节的一小环。
例如一个应用包含3个链式调用步骤,在调试阶段同时使用10个样例数据,就需要对 LLM 模型发起30次请求。传统做法是手写代码并执行这些调用,将 LLM 逻辑与具体语言的执行代码混合在一起。根据大量实践,这种方式在探索和调试 LLM 应用时效率低下,因为每次微调交互逻辑都需要重构已有代码。
很多时候,我们只能通过不断的尝试和观察,来判断模型的行为是否符合预期。这种原始的开发方式,导致开发效率低下,迭代周期长,bug 难以发现和定位。除此以外,还有大量日志、提示词回溯、数据验证部署等问题。
LLM 应用开发的工具链还处于非常初级的阶段,远不能满足工程化的需求。我们急需 LLM 领域的 "Visual Studio"、"PyCharm"、"Jira" 等专业工具的出现,帮助我们提高开发和运维效率,推动 LLM 应用的工程化进程。这也是 LLM 应用落地必须解决的一大阻力。
LLM 应用的另一个瓶颈是实时性能。由于 LLM 模型体量巨大,推理过程非常耗时,很难满足实时交互的需求。我们在开发调试过程中,非常容易遇到请求超时、响应延迟、批跑耗时等性能问题,严重影响了开发效率。在产品交互中,如客服、助手、实时检测等也构成了巨大的挑战。
我认为,解决这一问题的关键有两个方面。一是继续优化 LLM 的推理效率,通过算法创新、硬件加速等手段,减少单次推理的时间开销,这里需要底层技术人员的继续努力。二是在应用层做设计优化, 针对具体应用场景,设计合理的交互方式和任务流程,尽量减少实时推理的需求。比如,可以预生成问答,或者提前批跑做缓存等减轻实时交互的压力。后者是大部分产品层需要重点关注和理解的。
计算资源昂贵本身也是制约实时性的根本原因。众所周知,训练和推理 LLM 需要大量的算力支持,动辄就是成百上千的 GPU。这对于许多中小企业和创业团队来说,是一个巨大的成本压力。目前,大量云厂商都在加大对 LLM 领域的投,推出了一些专门针对 LLM 的计算实例和加速卡。这在一定程度上降低了中小企业的使用门槛。但总的来说,LLM 的计算成本仍然高于传统的软件开发。
在 LLM 应用落地时, 公司/团队预算要更加审慎地评估成本和收益,选择最合适的技术方案。
尽管目前 LLM 应用落地还面临诸多阻力,但我对其未来的发展前景充满信心。在最近的调研和开发实践中,我们也在尝试构建自己的 LLM 应用工具,以简化大模型落地的工程化阻力。
随着技术的不断进步和产业的持续探索,LLM 应用必将迎来爆发式增长。而支撑这一增长的关键,是要建立一个完备的 LLM 应用开发生态。
Sam Altman 在twitter发文提出新版摩尔定律:指全球AI的运算量每隔18个月就会提升一倍。这是因为一个行业发展和资金持续投入成比例,而 AI 算力无疑是行业焦点。在大量投入下,科研人员会尝试各种架构、算法等创新,从而给新摩尔定律提供支持。
我相信,随着算力成本的下降,LLM 应用将迎来更大的发展空间。许多受限于成本而无法落地的应用场景,都将变得可行。这将极大地促进 LLM 技术在各行各业的创新应用,带来新一轮的产业变革。
最后,我想谈谈关于 AGI的话题。许多人开始憧憬 AGI 的到来,认为只有实现了通用人工智能,LLM 才能真正发挥作用。
但我认为,这种观点是有一定局限性的。诚然,AGI (达到人类水平通用人工智能)是人工智能的终极目标,但它并不是 LLM 应用落地的必要条件。即使在当前的技术水平下,LLM 已经可以在许多领域取得显著的成效,为企业和用户创造巨大的价值。
与其过度强调 AGI,不如脚踏实地地探索 LLM 在不同场景下的应用,充分发挥其在垂直领域的优势。毕竟,大部分商业应用并不需要通用智能,而是需要在特定场景下提供专业、高效、智能的服务。LLM 技术完全可以满足这一需求。
但是我们仍然要对致力于 AGI 伟大先驱和科研人员进行致敬,AGI是一个远大的目标,不管它什么时候到来,它将会对产品形态产生更深远影响。