背景
LLM的应用场景
| 通用场景 | 应用举例 |
|---|---|
| 内容创作 | 生成所需创意内容的 “草稿” 版本，然后供用户进行参考和修改。 |
| 问题解答 | 使用户能够直接得到输入答案，无需再进一步查阅关联文档。 |
| 辅助写作 | 文本优化，例如语法校验以及专业化内容。 |
| 内容摘要 | 提供对话、文章、电子邮件以及网页的摘要总结生成。 |
| 信息简化 | 标题、大纲、关键内容等智能提取或生成 |
| 文本分类 | 针对特定用例对文本进行分类，例如通过情感或话题来聚合。 |
| 对话 | 开放域闲聊等，此外还可以利用意图识别，实体提取来提升对话效果。 |
简单概括就是：
Prompt -> LLM -> Content
这种模式下的LLM应用场景以及覆盖范围受限于prompt的内容，对于开放式的场景有极大挑战。比如：高考的作文评分怎么打？我们需要一整套严格的prompt，给出大量的thought-chain，描述是否偏离题意，是否超出字数限制，文笔怎么样等等，然后根据这些推理以及举例告诉LLM如何评分。
Langchain/Auto-gpt
在chatGPT爆火之后的时间里，人们开始思考对于LLM的更多能力拓展，auto-gpt完善了思维链，而langchain的出现，则标志着全新的LLM架构模式出现，其架构的最显著特点是将LLM的模型置于整条链路的最末端，前置做了更大的上下文拓展以及提供了api调用功能，最常见的场景如图：
Langchain的出现可以说是LLM的第二段高潮，人们看到的，是除了AIGC之外，LLM全面进入商业化应用的可能，也是网络应用程序的下一步革命。
Server Render
近几年我们可以发现，为了解决客户端在LCP方面的瓶颈，前端社区把工作重心放在了server render方面的技术，包括react18的suspense，以及还在dev阶段的server component也是为了有更好的ssr体验。
当然ssr不是这篇文章的重点，所以我们用一句话概括，SSR能更快的核心原因是务器功能更加强大，并且在物理上更接近数据源，它能高速处理计算密集型渲染，并仅向客户端发送交互式代码片段。更少的内容，更快的数据响应，这是ssr给我们带来的变化。
变革
可以预见到的是，以后所有的网络应用程序都会出现一个对话框。对话框会作为所有LLM AI能力的入口，毕竟LLM擅长的是处理自然语言，必须有对应的自然语言输入。
如图：sentry近期新上的Sentry Bot功能，用户与bot沟通，bot会
总结提炼文档中的内容，并且将文档中位置贴出。
但这种交互模式并非在LLM出现之后体现的，在LLM普及之前，许多文档类站点就已经拥抱了ai技术，比如vue或者react官网中的algolia.ai提供的搜索框，虽然不能提供自然语言对话功能，但也能在文档中准确定位链接位置。
就现状而言，ai对网络应用程序带来的最大变化，也许是文档搜索更容易了？更人性化了？
目前，这个对话框在各种应用中承担的最大功能，就是第一章LLM介绍中提到的【对话】【问题解答】【内容摘要】，这个场景局限于文档类的、存在大量静态html数据的站点。但未来绝非如此而已，Langchain出现之后，人们对这个对话框的想象开始丰富了起来。
考虑以下场景，在性能监控平台中，对ai发起如下会话：
很明显，就目前而言，你会得到这样的回答“很抱歉，作为一个AI语言模型，我无法直接提供A项目的TTI数据。”
但当我们接入了Langchain，并为其提供了tti的数据库以及上下文，显然，它可以给我们一份表格。
拓展到更多的场景，我们能不能在所有的管理后台都做成这种模式，在庞大复杂的管理后台系统中，通过一个对话框，既能回答用户的问题减轻心智负担学习成本，又能一步到位直接满足客户的需求。两全其美！谁不喜欢这样方便的交互呢。我不喜欢，全是markdown排版，狗都不看，按周一排序我还得再发一句话？不能点一下表格交互一下？
另一面，当我们对langchain类的LLM应用链路分析时我们不禁会思考一个问题，前端在这有啥用？
这一整条链路都在围绕后端做文章，前端写个对话框就完事了。糟糕，前端又死了。但我们深入思考之后会发现，前端不仅没有死，反而出现了一片蓝海，首先，这个对话框模式不会取代传统网页，只会作为额外功能出现；其次，这个模式早就有了，甚至在20年前就革过一波命（黄页被搜索引擎取代）。而对于我们熟悉的百度而言，在我们输入某些词条触发关键词之后，出现的是什么？
没错，是推广页，这个推广页需要提供核心内容展示以及自定义的交互，属于完全的前端内容，但它是由服务端直接发送，如果我没猜错，这应该还是php做的。是不是很熟悉，回到SSR近两年热门内容React Server Component经典质疑：《RSC跟php有什么不同》。规模化的server render技术其实一直在被应用，尤其是在面对千人千面的场景，前端渲染与数据强耦合的场景。而React 之前的世界。使用 php 这样的语言，我们在客户端和服务器之间建立了更紧密的关系。在整体架构中，您可以访问服务器以直接在您正在创建的页面内调用数据。然而，它也存在缺点，即由于跨团队依赖和高流量需求而难以扩展单体应用程序。
这个缺点不管，我们能不能把这个推广页直接放对话框里，并且创造一个可交互的component区域？
前端未来
话已至此，融合起之前提到的全部内容，包括让我介绍一下崭新的交互架构。
这个架构在LLM这层做了一些工作，为的是利用LLM的自然语言识别能力将用户意图与产品功能链接，随后会对我们的server层发起一次请求，这一层通常是指前端架设的BFF层，对于这层BFF，我们需要做的内容也稍微有点多，毕竟期望的是不影响原有的功能，单单这里，我们就需要根据不同的url请求，同时支持server render与client render，所以这边的架构该怎么做，将会做成什么样。同时在背后我们需要做什么去支撑LLM所需的上下文。我会在下期单独分析。
