LLM 核心架构：程序员大语言模型技术指南

我们也可以让 LLM 来告诉我们答案，只是它可能没有这样的创新能力。

应用篇：LLM 下的应用架构设计

未来的 AI 编程模式是什么？在那篇《渐近式 AI 编程模式》文章里，可以看到几个基本的思考：

• Prompt 即是代码，代码不再是代码？
• 现有的编程体系适合于 AI 编程吗？
• Serverless 会是结合 AI 编程的答案吗？
• 需求详细化会成为你的新瓶颈吗？

对于它的思考，促使我设计了 Unit Mesh 架构，详细见《Unit Mesh 架构的设计思路与探索》。

除了新的架构模式本身，我们还面临一个挑战：在现有的 LLM 下，我们应该如何设计应用架构？

2.1 新的交互设计：Chat 模式

在习惯了 ChatGPT 之后，Chat 模式作为基础的 LLM 元素加入了 UI 设计中。诸如于不那么好用的 New Bing，已经可以帮你总结一下相关的链接，虽然不可靠，但是大家都认可了。所以，无论是我们构建的 ClickPrompt，还是 AutoDev 这样的 IDE 辅助编程插件，都将 Chat 作为基础的 UI 模式加入到了系统。

而在 LangChain 的文档中，我们又会看到新一代的框架、工具文档模式，文档作为外挂的知识库，可以直接让开发人员通过对话来学习，并编写一些示例代码。就这一点而言，它大大改善了过去那不太好友好的文档体验。

所以，对于开发前端框架的人来说，这又带来了新的 KPI 机会。毕竟，谁会拒绝这么一个有挑战性的东西。另外一个点是，构建一个不同语言的 LangChain，经典企业的技术架构都优先考虑 JVM。

2.2 新的工序：大模型友好的流程

基于上述的新交互方式，现有的每一个应用都可能被重写。所以，我们开始探索对于软件开发的改变，也就有了《AI 应用开发新工序》。

对于当前的 AI 应用来说，主要有三种模式：直接 prompt 模式、知识外挂、微调。

1. 模型 1：直接 prompt。即 API + prompt 直接接入现有的流程中，以性价比最高的方式提效。
2. 模式 2：知识外挂。简单来说，就是采用 LangChain 这样的动态 prompt 工具，以根据用户的不同输入，来动态生成 prompt。又或者是，在本地采用相关性模型与算法，优化 prompt。
3. 模式 3：微调 —— 领域知识强化。即通过微调的方式，来让输出结果更适合于现有的工具与流程。

不同的模式之下，带给开发人员的挑战也是不一样的，依旧是由易到难。而其中的核心点是：寻找一种合理的 DSL（领域特定语言），以将现有的流程结合到 LLM。

2.3 架构设计的新变化

随着越来越多的大语言模型有了自己的类似 LangChain 工具（如 ChatGLM-LangChain）、越来越多的编程语言社区出了自己版本的 LangChain 版本（如 LangChain Go）。现有的软件架构又来了一些新的变化：

• 插件化与智能体（Agent）。诸如于 ChatGPT Plugin、LangChain 便是采用智能体 + 插件化的方式，大大方便我们构建基于 LLM 的应用扩展，并且结合各式的 LangFlow、LLaMaHub 工具，我们可以构建更智能的流程与系统。
• 矢量数据库。AI 的火爆使得越来越多的矢量数据进入了我们的视角，也成为了非常纠结的架构造型元素 —— 因为作为工程师的我们，还没有建立一个全面的认知，也缺少评估数据。

而由于 Token 很贵，我们需要管理好 token，以降低 token 的花销。我们还需要：

• 本地小模型。如 GitHub Copilot、Bloop 借助于本地的模型来进行相关性等的计算，以在本地构建动态的 prompt，而不需要消耗服务器的资源。
• 就地机器学习。犹如几年前，我只是因为喜欢《TinyML：基于 TensorFlow Lite 在 Arduino 和超低功耗微控制器上部署机器学习》的书名而买了这本书一样，我觉得 AI 不应该只在非消费级 GPU 上能跑，而是应该无处不在。

而这些依旧只是基于现状的观察，毕竟在外挂知识库、结合知识图谱方面，我们还有大量的工作和试验仍然在进行中。

高级篇：面向特定场景的 LLM 应用

每个不同的通用大语言模型，受限于语料、算法、强化方式，在能力上是不同的差异。而对于现有的、开源的大语言模型来说，这种差异就更加明显了。所以，我们需要针对于不同的场景，构建适合的策略，如编程场景、智能客服场景、需求完善场景等。

而由于微调后的模型是指针特定领域的，所以我们需要考虑适用于自身场景 LLM 架构方案：

• 动态的 LoRA 加载。诸如于针对不同场景下，可以动态经过不同的 LoRA 来处理数据。
• 通用大模型配合微调小模型。即通过一大一小的方式，由大模型给出工序，由小模型完善大模型不具备的细节能力。
• 多模型配合。诸如于结合 ChatGPT、StableDiffusion 和 VITS 等构建轻小说应用。

随着时间的推移，这方面的方案会越来越完善。

3.1 特定场景的模型微调

如果想利用大语言模型的能力，我们需要让它是大模型友好的，还需要构建一个工程化的模式。也就是我们在探索 API 新工序时，总结的基本思路：

1. 流程过程梳理与资产化：将业务逻辑转化为数据资产。
2. 对资产进行'语言建模'：以适用于大模型。
3. 构建 MVP 产品，并进行试验：快速验证假设。
4. 设计增量的指标，以引导系统演进：监控效果。
5. 围绕上下文的工程化思维：确保上下文一致性。
6. 持续反馈的软件工程，以完善系统准确度：闭环优化。

而对于微调来说，主要是前半部分：DSL 化、数据工程，以将现有的数据转换为模型可用的数据，进而整合到现有的工具链中。诸如于，将系统架构图转换为 PlantUML，以这些数据微调，进而简化现有的架构呈现方式。

微调技术栈

• 全量微调 (Full Fine-tuning)：适合数据量大且算力充足的情况。
• LoRA (Low-Rank Adaptation)：高效参数微调，冻结主权重，训练低秩矩阵。
• QLoRA：量化后的 LoRA，进一步降低显存需求。

# 示例：使用 HuggingFace Trainer 进行微调配置
from transformers import TrainingArguments
training_args = TrainingArguments(
    output_dir="./results",
    per_device_train_batch_size=4,
    num_train_epochs=3,
    # ... 其他参数
)

3.2 上下文工程：LLM 应用的核心

在我们探索 GitHub Copilot 的过程中，有感于 GitHub 程序员在此做的努力，于是总结了《上下文工程实践》。**如何对于高效的构建全面的上下文，以让 LLM 生成更准确的结果？**这便是我们在未来所要做的活动。结合上述的内容，几个潜在需要考虑的点是：

• 结合本地小模型，就地计算上下文。诸如于 Sentence-Transformers 进行语义相似度计算。
• 本地 Token 计算，以计算最合适的上下文。避免超出最大窗口限制。
• 上下文计算策略，以提供最需要的上下文。例如 RAG（检索增强生成）策略。

若是想充分运用大模型，我们需要控制好 Prompt，而其中的关键就是对于上下文的工程化。

总结

本文介绍了以 LLM 为核心的程序员技术指南，包括应用篇、高级篇和上下文工程。其中，应用篇介绍了 Chat 模式和大模型友好的流程，高级篇介绍了面向特定场景的 LLM 应用，上下文工程则是 LLM 应用的核心。

除此之外，文中还提到了当前 AI 应用的三种模式：直接 prompt 模式、知识外挂模式和微调模式，并介绍了针对不同场景构建适合的策略的重要性。同时，文章探讨了如何让 LLM 是大模型友好的，并建议采用语言建模、构建 MVP 产品并进行试验、设计增量的指标、围绕上下文的工程化思维和持续反馈的软件工程等方法来实现。

此外，文章还提到了随着时间推移，针对 LLM 的外挂知识库和结合知识图谱等方面的方案会不断完善，并讨论了如何构建动态的 LoRA 加载、通用大模型配合微调小模型以及多模型配合等方案。

总之，本文提供了一份全面的 LLM 技术指南，为程序员和开发人员提供了在这一领域提高效率的方法和策略。未来的编程将更加智能化，开发者需要从单纯编写代码转向设计提示词、管理上下文和优化模型交互流程。掌握这些技能将成为新时代程序员的核心竞争力。