建设网站说只给前端源码是什么意思,家政服务网站模板,做教育视频网站用什么平台好,wap建站程序合集每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗#xff1f;订阅我们的简报#xff0c;深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同#xff0c;从行业内部的深度分析和实用指南中受益。不要错过这个机会#xff0c;成为AI领… 每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗订阅我们的简报深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同从行业内部的深度分析和实用指南中受益。不要错过这个机会成为AI领域的领跑者。点击订阅与未来同行 订阅https://rengongzhineng.io/ 几年前人工智能还是为数不多、钱包鼓得像气球的科技公司的专利玩意儿。但转眼到了今天找个不急着把AI塞进它们流程和产品里的科技公司都难了——哪怕他们自己对这东西长啥样还一头雾水。
这篇文章我们就来探索这块新兴领域。如今的AI辅助应用是怎么运作的呢它们用的是什么架构为什么在其他方法摔跟头的地方它们却能大放异彩
“货架上直接拿”的AI 虽然AI给人感觉挺震撼的但它其实不是啥新鲜事。多年来科技行业的领头羊们已经在大型应用中使用了机器学习——比如Netflix优化内容编码Uber计算美食推荐亚马逊规划配送。这些AI特性都非常专业普通软件供应商的工具箱里是找不到的。
今儿个形势有了变化随着即用型AI技术的爆炸式增长一些经验丰富的开发团队即使没有巨额预算和专门的机器学习知识也能将这些功能整合到他们的应用中。
这种向即用型工具的转变主要集中在AI领域的一个相对较小且非常具体的部分大型语言模型即LLMs。从更广的视角来看LLMs可能只是软件开发中可访问AI演进的第一步。未来我们会有更多工具和更好的模式来将AI特性集成到定制软件中。现在已经很清楚当前的LLMs并不是许多场景下的完美工具——它们有自己的怪癖、限制和意外的复杂性。但是获取即用型AI的吸引力非常强大大多数公司都不在乎这些。他们不愿等待打算尽可能快地从这项技术中挖掘出每一种可能的用途。
定制化的基本要求 那么为什么LLMs在其他类型的AI因过于复杂而难以广泛采用的地方却能取得成功呢有几个原因但没有基础模型的兴起这种转变是不可能的。
本质上基础模型是像OpenAI、谷歌和Facebook这样的公司构建的巨大的、通用目的模型。你可以直接使用一个基础模型就像ChatGPT所做的。但真正的诀窍在于调整基础模型以适应个别用例而不是从头开始训练一个新模型。这是一个重要的区别因为训练是既耗资金又需要专业知识的部分。
这听起来很有希望但挑战在于要能够足够定制模型以满足不同行业和不同领域的需求——换句话说就是独立软件供应商工作并盈利的那些细分市场。一个基础模型本身可能并不令人兴奋但如果软件公司能够定制它以适用于医疗记录或技术支持票据那就大不相同了。
但这里有个问题——基础模型并不那么容易定制。你可以尝试用新知识来微调它们但模型已经知道的内容往往会主导你希望它们学习的新信息因为这些模型非常庞大。虽然微调并不像从头开始训练那样复杂和昂贵但它仍然需要时间和关键资源。
因此目前普遍接受的方法是使用上下文学习。虽然有几种不同的技术但总的想法是在你当前的请求上下文中给LLM提供所需的信息。这可能意味着展示一些你想要的例子例如“按照这种格式”或在你的提示中包括一些额外的数据例如“使用这块数据回答问题”。这些技术都不是新的但也没有哪一种成为完全定型的最佳实践因为LLMs还在快速变化。但核心思想是上下文学习给开发者提供了他们需要的东西一个只需最少量定制就能构建适当软件功能的基础模型。
大型语言模型LLM应用程序的经典架构
既然我们已经了解了所有背景信息现在是时候仔细研究人们今天正在构建的LLM应用程序了。
首先想象一种天真的方法——一个应用程序简单地坐在用户和LLM之间转发所有请求和响应。这种情况看起来是这样的 代理到一个LLM 改善这种情况的第一种方法是通过提示工程——换句话说是在你发送给LLM之前对用户的请求进行正式化和改进。这里有一个例子它采用用户数据并将其与应用程序指令结合起来构建最终的提示 提示工程 现在仍然只有一个提示被发送到LLM但现在它是一个详细的指令文档分成了清晰的几部分用户的数据嵌入其中。
准备一个提示是一个关键步骤但还有更多可以做的。将应用程序视为LLM上的一个独立的抽象层有助于思考。换句话说应用程序可以为LLM交互添加新的可能性和功能。例如你可以获取用户的请求推断他们想要执行的任务并使用该任务来发起多个LLM请求。有时一个请求会使用从前一个请求返回的数据这是一种称为提示链的技术 提示链 我们还没有看到今天LLM应用的主导模式即检索增强生成RAG。这里的想法是从另一个来源提取一块相关的、特定领域的信息并使用该信息在你发送给LLM的提示中。检索到的信息可以包括私有数据给基础模型提供它以前从未见过的信息。 检索增强生成RAG RAG的概念看起来很直接。然而它引入了两个重大挑战
数据的数量
你不能把LLM可能需要的所有东西都塞进你的提示中。例如如果你想要一个LLM使用《战争与和平》中的引用来构建论点你不能把整本书的文本放入提示中因为那超出了LLM的上下文窗口可用的空间。上下文窗口是LLM一次可以考虑的所有新数据的度量。即将到来的LLM可能会有明显更大的上下文窗口可能解决这个问题。然而专家们仍然相信将大量数据塞进上下文窗口在可预见的未来将是极其缓慢和昂贵的。
数据的相关性
如果你不能使用所有东西你给LLM的东西最好是相关的。例如如果你在询问关于《战争与和平》的问题你应该选择可能包含你希望LLM分析的内容的摘录。要使这项工作你需要另一种AI驱动的能力称为语义搜索我们将很快讨论。 这些架构是关键的构建块。当你将这些技术结合在一起时你将看到一些真正新的AI辅助交互的可能性。例如想象你正在创建一个个人健康应用程序。如果你没有这些架构在心中你可能会实现一个非常简单的模式添加一个聊天机器人功能告诉LLM它是一个致力于提供建议的健康专家并让用户提问。但如果你更有野心你可以构建这样工作的软件
首先应用程序采访用户以收集健身目标并创建个人档案不需要AI。接下来应用程序要求LLM根据个人档案创建总体健康目标可能会查看一份经过审核的建议列表或使用一个可信来源。然后根据用户的兴趣和行动应用程序要求LLM构建样本菜单建议正念练习并计划每周的锻炼时间表。
也许你心中有更雄心勃勃的互动想法——例如在日历中添加锻炼提醒将食谱成分放入购物清单寻找当地活动发送电子邮件启动其他应用程序。此时就很清楚LLM不再仅仅是一个文档生成器或智能搜索工具。
这些想法有些还不成熟和实验性。目前我们有很多令人印象深刻的玩具项目但在这个领域还没有突出的成功。但这种情况很可能在几个月内而不是几年内发生变化。
基础建设
在我们迄今为止看到的例子中“应用程序”部分是我们开发者需要构建的我们利用自己的常规技巧和对问题领域及业务的理解来完成这一任务。应用程序外部有两个预构建的成分
大型语言模型LLM向量数据库
让我们深入了解实现这一架构的技术细节。
选择LLM 目前开发者们用来原型设计新LLM应用的最常见的LLM是OpenAI的GPT-4。OpenAI API的优势在于它是最成熟的产品。它是最易于编程使用的LLM其响应最为一致需要的额外工作最少。
开发者创建了概念验证之后会进行实验。更便宜的GPT-3.5 Turbo能否同样有效把它迁移到像Claude或甚至是开源的Llama这样的替代服务上怎么样这两者都可以通过亚马逊Bedrock服务轻松访问如果你雄心勃勃一个开源的LLM模型可以自我托管尽管这自带其挑战目前这还不是一个常见的方法。
选择向量数据库 向量数据库以一种特殊的数值表示形式存储文本块称为向量嵌入。这与LLM理解提示中的文本的过程相同。但拥有嵌入式内容的真正优势在于你可以使用自然语言处理NLP的特性来分析它。最有用的是你可以使用词语的概念含义而非它们的字母来进行搜索。例如“认证”的嵌入可能与“密码”的嵌入类似允许搜索找到相关内容这些内容不一定使用完全相同的词语但覆盖相同的主题。
NLP是支撑LLMs的AI的基础领域。为了为你自己的内容创建嵌入你需要一个嵌入模型。你可以使用一个开源库——有几个——但再次强调最简单的服务是由OpenAI API提供的。 一旦你创建了嵌入就需要将它们存储在数据库中。你需要使用一个向量数据库它将索引你的文本块以便你能高效地搜索它们。目前最常用的向量数据库是Pinecone它是一个完全托管的云服务。然而向量数据库领域几乎与LLMs一样快速发展还有许多其他产品可以尝试。 未来我将更仔细地查看使这些单独部分工作的工具比如不同语言的LLM库。现在你已经对整体架构有了坚实的理解这些细节将更有意义。即使你现在不急于开始构建自己的AI驱动实验这个概览仍然是一个很好的参考点。因为到明年这个时候这个领域肯定会再次发生翻天覆地的变化。
