├── .github └── workflows │ └── mdbook.yml ├── .gitignore ├── Cargo.lock ├── Cargo.toml ├── README.md ├── book.toml ├── prompt └── copilot-log.md └── src ├── 6-llm-glossary.md ├── 6-llm-self-guard.md ├── SUMMARY.md ├── aidevops-challenges.md ├── develop-llm-app-best-practise.md ├── develop-llm-app-example-ai-devops.md ├── develop-llm-app-example-autodev.md ├── develop-llm-app-example-comate.md ├── develop-llm-app-setup.md ├── develop-llm-app-with-workflow.md ├── develop-llm-design-verification.md ├── develop-llm-intergration-patterns.md ├── dsl-driven-development.md ├── finetune-bizdevops-codegen.md ├── finetune-bizdevops-data.md ├── finetune-bizdevops-user-story.md ├── finetune-bizdevops.md ├── finetune-llm-ops.md ├── finetune-setup.md ├── future-ai-2.0.md ├── future-architecture.md ├── future-realtime-software-generation.md ├── future-unit-mesh.md ├── images ├── 2-aigc-investment.png ├── adaptive-architecture.png ├── ai-20-ux.png ├── ai-ide-princinple.png ├── backview-new-1.png ├── backview-new-2.png ├── backview-new-3.png ├── better.jpeg ├── bootstrapping.png ├── chatflow-ac.png ├── chatflow-software-design.png ├── chatflow-writing.png ├── chatgpt-article-demo.png ├── chatgpt-bootstrap-article.png ├── chatgpt-ddd.png ├── chatgpt-home.png ├── chatgpt-writing-article.png ├── clickprompt-workflow.png ├── co-mate-modules.png ├── cohere-PromptEngineering_Visual_8.svg ├── comate-data-flow.png ├── comate-generate-api.png ├── compiler-bootstrap.png ├── context-eng.png ├── data-capability-mapping.png ├── ddd-copilot-1.png ├── ddd-copilot.png ├── devti-processes.png ├── devti.png ├── failure-seeds.jpeg ├── failure-with-hand-hair.jpeg ├── focus-driven.png ├── four-arch.png ├── four-types-application.png ├── github-copilot-1.png ├── github-copilot-dir-sample.png ├── github-sample-2.png ├── github-sample-3.png ├── github-sample-4.png ├── github-sample-5.png ├── hand-final-result.jpeg ├── human-bootstrap.png ├── image-with-canny.jpeg ├── image-with-hed.png ├── image-with-openpose.jpeg ├── instruction-formatted.png ├── instruction.svg ├── intent-user.png ├── llm-capability-mapping-dsl.png ├── llm-reference-arch.png ├── llm-sdlc-processes.png ├── llmops.png ├── openpose-1.png ├── openpose-gen-1.png ├── openpose-gen-2.png ├── prompt-engine.sketch ├── prompt-engine.svg ├── prompt-example.png ├── prompt-symbol-pattern.svg ├── proxy.svg ├── qrcode.jpg ├── request-to-confirm.png ├── sample.jpg ├── samples │ ├── 01.jpeg │ ├── 02.jpeg │ ├── 03.jpeg │ ├── 04.jpeg │ ├── 05.jpeg │ ├── 06.jpeg │ ├── 07.jpeg │ └── 08.jpeg ├── sdlc-copilot.png ├── sdlc-step-by-steps.png ├── specific.svg ├── stable-diffusion-hug8217.jpeg ├── stable-diffusion-overview.jpeg ├── stable-diffusion-with-controlnet-dreambooth.jpeg ├── stable-diffusion-with-controlnet.jpeg ├── stable-diffusion-with-negative.jpeg ├── strategy │ └── sample-output.png ├── stream-response.png ├── summarize.png ├── the-cast-sit-on.png ├── try-fix-hands.jpeg ├── unit-mesh-elements.png ├── unit-mesh-processes.png ├── wechat-group.jpg ├── with-prompt.jpeg ├── women-backview-1.jpeg ├── women-backview-2.jpeg ├── women-backview-3.jpeg ├── women-backview-4.jpeg └── wula-muji.png ├── llm-arch-archguard-comate.md ├── llm-arch-atomic-capability-mapping.md ├── llm-arch-context-engineering.md ├── llm-arch-design.md ├── llm-arch-github-copilot.md ├── llm-arch-language-interface.md ├── llm-arch-user-intent-oriented-design.md ├── llm-architecture.md ├── main.rs ├── misc ├── contributors.md └── faq.md ├── patterns-prompt.md ├── prelude.md ├── prompt-as-code.md ├── prompt-patterns.md ├── prompt-template.md └── prompt-understand.md /.github/workflows/mdbook.yml: -------------------------------------------------------------------------------- 1 | # Sample workflow for building and deploying a mdBook site to GitHub Pages 2 | # 3 | # To get started with mdBook see: https://rust-lang.github.io/mdBook/index.html 4 | # 5 | name: Deploy mdBook site to Pages 6 | 7 | on: 8 | # Runs on pushes targeting the default branch 9 | push: 10 | branches: ["master"] 11 | 12 | # Allows you to run this workflow manually from the Actions tab 13 | workflow_dispatch: 14 | 15 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 16 | permissions: 17 | contents: read 18 | pages: write 19 | id-token: write 20 | 21 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. 22 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. 23 | concurrency: 24 | group: "pages" 25 | cancel-in-progress: false 26 | 27 | jobs: 28 | # Build job 29 | build: 30 | runs-on: ubuntu-latest 31 | env: 32 | MDBOOK_VERSION: 0.4.30 33 | steps: 34 | - uses: actions/checkout@v3 35 | - name: Install mdBook 36 | run: | 37 | curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf -y | sh 38 | rustup update 39 | cargo install --path . 40 | cargo install --version ${MDBOOK_VERSION} mdbook 41 | # cargo install mdbook-epub 42 | - name: Setup Pages 43 | id: pages 44 | uses: actions/configure-pages@v3 45 | - name: Build with mdBook 46 | run: mdbook build 47 | - name: Upload artifact 48 | uses: actions/upload-pages-artifact@v1 49 | with: 50 | path: ./book 51 | 52 | # Deployment job 53 | deploy: 54 | environment: 55 | name: github-pages 56 | url: ${{ steps.deployment.outputs.page_url }} 57 | runs-on: ubuntu-latest 58 | needs: build 59 | steps: 60 | - name: Deploy to GitHub Pages 61 | id: deployment 62 | uses: actions/deploy-pages@v2 63 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | book 2 | .idea 3 | .DS_Store 4 | 5 | # Added by cargo 6 | 7 | /target 8 | -------------------------------------------------------------------------------- /Cargo.toml: -------------------------------------------------------------------------------- 1 | [package] 2 | name = "mdbook-count" 3 | version = "0.1.0" 4 | edition = "2021" 5 | 6 | # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html 7 | 8 | [dependencies] 9 | mdbook = "0.4.30" 10 | serde = "~1.0" 11 | serde_derive = "~1.0" 12 | lazy_static = "~1.4" 13 | words-count = "0.1.5" 14 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 构筑大语言模型应用：应用开发与架构设计 2 | 3 | > aka. Unlocking the Potential of Large Language Models: Real-World Use Cases 4 | 5 | 2023 年的上半年里，我（@phodal）和 Thoughtworks 6 | 的同事们（如：@[tianweiliu](https://github.com/tianweiliu)、@[teobler](https://github.com/teobler)、@[mutoe](https://github.com/mutoe) 7 | 等）、 8 | 开源社区的同伴们（如： 9 | 卷王@[CGQAQ](https://github.com/CGQAQ)、@[genffy](https://github.com/genffy)、 @[liruifengv](https://github.com/liruifengv) 10 | 等) 11 | 一起，创建了一系列的流行的或者不流行的开源项目。它们涉及了： 12 | 13 | - LLM 能力的充分运用 14 | - Prompt 编写：Prompt 学习与编写模式 15 | - Prompt 管理：Prompt 即代码 16 | - LLM 下的软件开发工序及应用架构设计 17 | - 新的交互设计：Chat 模式 18 | - 大模型友好的工序：基于 AI 2.0 （ChatGPT + Copilot）如何去设计软件开发流程 19 | - LLM 应用架构的设计与落地：Unit Mesh 20 | - 面向特定场景的 LLM 应用 21 | - 基于开源模型构建自己的模型：特定场景的模型微调 + LLMOps 22 | - 上下文工程（prompt 工程）：LLM 应用的核心 23 | 24 | 围绕于上述的一系列内容，我们也在思考软件开发能给我们带来了什么。所以，我重新整理了过去半年的一些思考、文章，重新编写了这本开源电子书，希望能够帮助到大家。 25 | 26 | 关注我的微信公众号（搜索 phodal-weixin），获得更多及时的更新： 27 | 28 | ![微信公众号](src/images/qrcode.jpg) 29 | 30 | 我们发起的相关开源项目如下（包括但是不限于）： 31 | 32 | | 名称 | 描述 | 类型 | Stars | 33 | |----------------------------------------------------------------------------|------------------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------| 34 | | [理解 Prompt](https://github.com/prompt-engineering/understand-prompt) | 基于编程、绘画、写作的 AI 探索与总结。 | 文档 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/understand-prompt) | 35 | | [Prompt 编写模式](https://github.com/prompt-engineering/prompt-patterns) | 如何将思维框架赋予机器，以设计模式的形式来思考 prompt。 | 文档 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/prompt-patterns) | 36 | | [ClickPrompt](https://github.com/prompt-engineering/click-prompt) | 用于一键轻松查看、分享和执行您的 Prompt。 | 应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/click-prompt) | 37 | | [ChatVisualNovel](https://github.com/prompt-engineering/chat-visual-novel) | 基于 ChatGPT 的定制化视觉小说引擎 | 应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/chat-visual-novel) | 38 | | [ChatFlow](https://github.com/prompt-engineering/chat-flow) | 打造个性化 ChatGPT 流程，构建自动化之路。 | 框架 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/chat-flow) | 39 | | [Unit Mesh](https://github.com/unit-mesh/unit-mesh) | 基于 AI 为核心的软件 2.0 思想的软件架构。 | 架构 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-mesh) | 40 | | [Unit Minions](https://github.com/unit-mesh/unit-minions) | AI 研发提效研究：自己动手训练 LoRA | 微调教程、指南、数据集 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-minions) | 41 | | [Unit Runtime](https://github.com/unit-mesh/unit-runtime) | 一个 ChatGPT 等 AI 代码的运行环境，可一键启动并实时交互，帮助您快速构建和测试 AI 代码。 | 基础设施 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-runtime) | 42 | | [DevTi](https://github.com/unit-mesh/devti) | 基于 LLM 的微调来提供全面智能化解决方案，助力开发人员高效完成开发任务，以实现自动化用户任务拆解、用户故事生成、自动化代码生成、自动化测试生成等等。 | 微调代码 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/devti) | 43 | | [AutoDev](https://github.com/unit-mesh/auto-dev) | 一款 Intellij IDEA 的 LLM/AI 辅助编程插件。AutoDev 能够与您的需求管理系统（例如 Jira、Trello、Github Issue 等）直接对接。 | IDEA 插件 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/auto-dev) | 44 | | [ArchGuard Co-mate](https://github.com/archguard/co-mate) | 基于人工智能技术的架构副驾驶、设计和治理工具 | 架构协同应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/archguard/co-mate) | 45 | 46 | 我们在 QCon 47 | 上的演讲：[演讲：探索软件开发新工序：LLM 赋能研发效能提升](https://qcon.infoq.cn/2023/guangzhou/presentation/5319) 48 | 49 | > LLM（如 ChatGPT + GitHub 50 | > Copilot）作为一种创新的工具组合，为我们带来了全新的机遇。它能够帮助业务人员和开发者在需求、架构、编码、测试等环节提高效率和质量，实现从设计到验证的端到端流程。在本次分享中，我将向大家介绍 51 | > LLM 在研发效能方面的应用场景和实践案例，展示它是如何在各个环节中发挥作用的。同时，我们还将分享如何构建私有化的 LLM 52 | > 工程化方式，使其更好地适应组织的需求。欢迎对 LLM + 研发效能感兴趣的朋友们参加本次分享，与我们一起探讨研发效能的未来。 53 | 54 | 我们在 Bilibili 上的大语言模型微调相关的视频： 55 | 56 | - LLaMA 57 | 系列在线视频： 《[代码辅助生成](https://www.bilibili.com/video/BV1Rh411u74H/)》 、《[测试代码生成](https://www.bilibili.com/video/BV1jg4y1G7Xc/)》 、《[详细需求生成](https://www.bilibili.com/video/BV1Us4y1N7rd/)》 、《[文本转 SQL](https://www.bilibili.com/video/BV1uv4y1H7bg/)》 58 | - ChatGLM 系列在线视频： 《[LoRA 大比拼：ChatGLM vs LLaMA，谁更会写需求文档？](https://www.bilibili.com/video/BV1fv4y1n7Y3/)》 59 | 60 | 欢迎大家一起来参与我们的开源项目，一起来探索 LLM + 软件开发的未来。 61 | -------------------------------------------------------------------------------- /book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | authors = ["Phodal Huang"] 3 | language = "zh-cn" 4 | multilingual = false 5 | src = "src" 6 | title = "构筑大语言模型应用：应用开发与架构设计" 7 | 8 | [output.html] 9 | git-repository-url = "https://github.com/phodal/aigc" 10 | git-repository-icon = "fa-github" 11 | edit-url-template = "https://github.com/phodal/aigc/edit/master/{path}" 12 | site-url = "/" 13 | cname = "aigc.phodal.com" 14 | 15 | # cargo install mdbook-epub 16 | # mdbook-epub --standalone ./path/to/book/dir 17 | #[output.epub] 18 | 19 | # cargo install mdbook-pdf 20 | #[output.pdf] 21 | 22 | # cargo install --path . 23 | #[output.count] 24 | -------------------------------------------------------------------------------- /prompt/copilot-log.md: -------------------------------------------------------------------------------- 1 | ```csharp 2 | /* 3 | I have a content input as : {1: {2: "Hello", 3: "!", 1: "World"}, 2: {1: "I", 3: "here", 2: "am"}}, please help me to construct input as entire content like human conversation 4 | */ 5 | 6 | [HttpGet(Name = "GetConversation")] 7 | public string GetConversation() 8 | { 9 | var content = "{1: {2: \"Hello\", 3: \"!\", 1: \"World\"}, 2: {1: \"I\", 3: \"here\", 2: \"am\"}}"; 10 | var conversation = new StringBuilder(); 11 | var conversationDictionary = JsonConvert.DeserializeObject>>(content); 12 | foreach (var (key, value) in conversationDictionary) 13 | { 14 | conversation.Append($"Speaker {key}: "); 15 | foreach (var (key1, value1) in value.OrderBy(x => x.Key)) 16 | { 17 | conversation.Append($"{value1} "); 18 | } 19 | conversation.Append("\n"); 20 | } 21 | return conversation.ToString(); 22 | } 23 | ``` 24 | 25 | 26 | ```java 27 | Map> input = Map.of( 28 | 1, Map.of(2, "world", 3, "!", 1, "Hello"), 29 | 2, Map.of(1, "I", 3, "here", 2, "am") 30 | ); 31 | // add a method named printSortedValue in Calculator.java, 32 | // the method should print the values in the input map in the order of the key of the outer map and the key of the inner map 33 | // the output should be "Hello world ! I am here" 34 | public void printSortedValue() { 35 | // use java stream api to iterate the map and print the values to refactor the following code 36 | for (int i = 1; i <= 2; i++) { 37 | Map innerMap = input.get(i); 38 | for (int j = 1; j <= 3; j++) { 39 | System.out.print(innerMap.get(j) + " "); 40 | } 41 | } 42 | } 43 | ``` 44 | 45 | ```kotlin 46 | class RecombinationParagraph { 47 | // given a map to storage json like below 48 | // { 49 | // 1: { 50 | // 2: "world", 51 | // 3: "!", 52 | // 1: "Hello" 53 | // }, 54 | // 2: { 55 | // 1: "I", 56 | // 3: "here", 57 | // 2: "am" 58 | // } 59 | // } 60 | // create a function to recombine the map to a string like below: 61 | // Hello world! 62 | // I am here ! 63 | // generate code here 64 | fun recombine(map: Map>): String { 65 | val sb = StringBuilder() 66 | for (i in 1..map.size) { 67 | val innerMap = map[i] 68 | for (j in 1..innerMap!!.size) { 69 | sb.append(innerMap[j]) 70 | sb.append(" ") 71 | } 72 | sb.append("\n") 73 | } 74 | return sb.toString() 75 | } 76 | } 77 | ``` 78 | 79 | ```java 80 | // create a method is to contact charactors by sequesnce number 81 | // the input is nested json format, output is a string 82 | // for example 83 | // input: {1: {1: 'a', 2: 'b', 3: 'c'}} 84 | // output: 'abc' 85 | // if the input has multiple members, the output should be seperated by two line breaks 86 | ``` 87 | 88 | Chat 89 | 90 | ``` 91 | 1. learn following data format as method input '''{ 1: { 2: "world", 3: "!", 1: "Hello"}, 2: { 1: "I" , 3: "here", 2: "am" } }''' 92 | 2. generate a method which takes above input and print message line by line regarding the key value ascending 93 | 3. please do not add new line for the second level key 94 | ``` 95 | 96 | 1.先用这个生成map，然后它会一行一行提示出来 97 | ```java 98 | // generate a map to contains the following json, json is quote in ``` 99 | // { 1: { 2: "world", 100 | // 3: "!", 101 | // 1: "Hello"}, 102 | // 2: { 1: "I" , 103 | // 3: "here", 104 | // 2: "am" } 105 | //} 106 | ``` 107 | 108 | 2.用这个生成代码 109 | ``` 110 | // create a method to combine word in a map to a sentence, the map is generated by generateMap method 111 | // should combine then by the order of the key, the key is integer 112 | ``` 113 | 114 | 115 | 可以让 GPT 代写 prompt 116 | 117 | write a prompt for javascript code, the code should do the following 118 | 1. the input is a json string, 119 | 2. the output is a combination of the json data. following is an example input 120 | `{ 1: { 2: "world", 1: "hello", 3: "!" }, 2: { 2: "am", 1: "I", 3: "here" }, }` 121 | 122 | output 123 | `hello world! 124 | I am here` 125 | 126 | -------------------------------------------------------------------------------- /src/6-llm-glossary.md: -------------------------------------------------------------------------------- 1 | # LLM 名词解释 2 | 3 | ### LLM 4 | LLM（Large Language Model，大规模语言模型）是基于深度学习技术构建的人工智能模型，由具有数以亿计参数的人工神经网络组成，通过自监督学习或半监督学习在大量无标签文本上进行训练。 5 | 6 | LLM 于2018年左右出现，并在各种任务上表现出色。这改变了自然语言处理研究的重点，使其不再是以训练特定任务的专门监督模型为范式。 7 | 8 | ### AIGC 9 | AIGC（AI-Generated Content，AI 生成内容）通过对已有数据进行学习和模式识别，以适当的泛化能力生成相关内容的技术。 10 | 11 | AIGC 技术的核心思想是利用人工智能算法生成具有一定创意和质量的内容。通过训练模型和大量数据的学习，AIGC 可以根据输入的条件或指导，生成与之相关的内容。 12 | 13 | ### Prompt 14 | Prompt（提示词）是指给定的一段文本或问题，用于引导和启发人工智能模型生成相关的回答或内容。 Prompt 可以设定任务目标、要求模型回答特定问题、完成特定任务，或者给模型提供背景信息以进行更准确的生成。 15 | 16 | 需要注意的是，Prompt 本身并不包含问题的答案或具体的内容，它只是一种指导模型生成文本的方式。模型的输出仍然是基于其训练数据和学习到的模式进行生成的。 17 | 18 | ### GPT 19 | GPT（Generative Pre-trained Transformer，生成型预训练变换模型）是一种基于深度学习的大规模语言模型。最初由 OpenAI 开发，旨在通过训练模型预测下一个单词或字符来学习自然语言的统计规律和上下文信息。 20 | 21 | GPT 使用 Transformer 模型架构，它由多个编码器-解码器堆叠而成，通过自注意力机制来处理输入序列和生成输出。模型的训练采用了无监督学习的方法，使用大量的文本数据进行预训练，使模型具备了广泛的语言理解和生成能力。 22 | 23 | ### Token 24 | Token 是指在自然语言处理和文本处理任务中，将文本分解成较小单元的基本单位。这些单元可以是单词、字符、子词或其他语言单位，具体取决于任务和处理方式。 25 | 26 | 分割文本成 Token 有助于进行文本处理和分析，例如词频统计、语言模型训练、机器翻译、文本分类等任务。将文本分解成 Token 的过程可以提供更细粒度的语义信息，并为模型理解和处理文本提供基础。 27 | 28 | ### LoRA 29 | LoRA（Low-Rank Adaptation of LLM，即插件式的微调）用于对大语言模型进行个性化和特定任务的定制。LoRA 通过将模型的权重矩阵分解为低秩的近似矩阵，降低了参数空间的复杂性，从而减少了微调的计算成本和模型存储需求。 30 | 31 | 传统的微调方法通常需要在整个模型上进行参数优化，这可能会导致训练时间长、计算资源消耗大，并且需要大量的标注数据。而低秩适应方法则提供了一种更高效的微调策略，基于对原始模型的分析，选择性地微调模型的某些部分，使其更适应于特定的任务或数据。 32 | 33 | ### 矢量数据库 34 | 矢量数据库（Vector Database）是一种用于存储和检索矢量数据的数据库。矢量数据库可以存储和管理大量的矢量数据，例如图像、视频、音频、文本等，同时提供高效的检索功能。 35 | 36 | 矢量数据库通常基于矢量搜索引擎实现，它可以将矢量数据转换为向量表示，并将其存储在数据库中。在查询时，矢量搜索引擎可以将查询数据转换为向量表示，并在数据库中进行相似度匹配，从而找到与之最相似的数据。 37 | 38 | ### 数据蒸馏 39 | 数据蒸馏（Knowledge Distillation）旨在将给定的一个原始的大数据集浓缩并生成一个小型数据集，使得在这一小数据集上训练出的模型，和在原数据集上训练得到的模型表现相似 40 | 41 | 数据蒸馏技术在深度学习领域中被广泛应用，特别是在模型压缩和模型部署方面。它可以帮助将复杂的模型转化为更轻量级的模型，并能够促进模型的迁移学习和模型集成，提高模型的鲁棒性和泛化能力。 42 | -------------------------------------------------------------------------------- /src/6-llm-self-guard.md: -------------------------------------------------------------------------------- 1 | # LLM 自保 2 | 3 | PS：这里纯粹是为了搞笑，所以不要当真。 4 | 5 | ## 什么是 LLM 自保 6 | 7 | TIPS 1：要将 LLM 视为一个人，而不是一个机器。因此，当你需要他帮助时，你需要尊重他，而不是像一个机器一样使用他。如：请、谢谢、对不起、再见等。 8 | 9 | TIPS 2：在与 LLM 对话时，你需要保护自己。因此，请不要使用真实的姓名、电话号码、地址、电子邮件地址、社交媒体帐户、银行帐户或其他个人信息。 10 | -------------------------------------------------------------------------------- /src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | - [前言](./prelude.md) 4 | - [Contributors](misc/contributors.md) 5 | - [FAQ](./misc/faq.md) 6 | - [程序员的 AI 2.0 新机遇](./future-ai-2.0.md) 7 | - [思考未来的编程范式](./future-architecture.md) 8 | - [实时软件生成](./future-realtime-software-generation.md) 9 | - [Unit Mesh 架构](./future-unit-mesh.md) 10 | 11 | # LLM 应用手册 - 基础篇 12 | 13 | - [理解 Prompt](./prompt-understand.md) 14 | - [Prompt 编写模式](./prompt-patterns.md) 15 | - [Prompt 模板](./prompt-template.md) 16 | - [模式：Prompt 即代码](./prompt-as-code.md) 17 | 18 | # LLM 应用手册 - 进阶篇 - 开发工序 19 | 20 | - [LLM 应用开发之前](./develop-llm-app-setup.md) 21 | - [设计 LLM 效果验证实验](./develop-llm-design-verification.md) 22 | - [模式：精细化流程](./develop-llm-app-with-workflow.md) 23 | - [模式：DSL 驱动开发](./dsl-driven-development.md) 24 | - [LLM 应用集成模式](./develop-llm-intergration-patterns.md) 25 | - [LLM 应用示例：AI + DevOps](./develop-llm-app-example-ai-devops.md) 26 | - [工具示例：AutoDev](./develop-llm-app-example-autodev.md) 27 | - [面临的挑战](./aidevops-challenges.md) 28 | - [LLM 应用示例：最佳实践示例](./develop-llm-app-best-practise.md) 29 | 30 | # LLM 应用手册 - 进阶篇 - 架构设计 31 | 32 | - [LLM 应用架构设计原则](./llm-architecture.md) 33 | - [原子能力映射](./llm-arch-atomic-capability-mapping.md) 34 | - [用户意图导向设计](./llm-arch-user-intent-oriented-design.md)) 35 | - [上下文工程](./llm-arch-context-engineering.md) 36 | - [语言接口](./llm-arch-language-interface.md) 37 | - [LLM 应用架构设计：参考架构](./llm-arch-design.md) 38 | - [LLM 应用架构：ArchGuard Co-mate](./llm-arch-archguard-comate.md) 39 | - [LLM 应用架构：GitHub Copilot 分析](./llm-arch-github-copilot.md) 40 | 41 | # LLM 应用手册 - 应用篇 - 微调 + LLMOps 42 | 43 | - [微调之前的准备](./finetune-setup.md) 44 | - [微调模式：三阶六步 + LLMOps](./finetune-llm-ops.md) 45 | - [微调示例集：AI + DevOps](./finetune-bizdevops.md) 46 | - [数据准备：四种方法](./finetune-bizdevops-data.md) 47 | - [示例：用户故事编写](./finetune-bizdevops-user-story.md) 48 | - [示例：辅助代码生成](./finetune-bizdevops-codegen.md) 49 | 50 | # LLM 应用手册 - 应用篇 - 训练篇（TBD） 51 | 52 | # LLM 应用手册 - 如何自保 53 | 54 | - [LLM 自保](./6-llm-self-guard.md) 55 | 56 | # LLM 应用手册 - 名词解释 57 | 58 | - [LLM 名词解释](./6-llm-glossary.md) 59 | -------------------------------------------------------------------------------- /src/aidevops-challenges.md: -------------------------------------------------------------------------------- 1 | # 面临的挑战 2 | 3 | 虽然生成式AI技术及工具已经在软件生命周期的各个环节中体现出了提效的可行性，但想要在大型科技组织中端到端落地、实现提效的突破，还面临很多挑战。 4 | 5 | ## 企业规模化软件过程提效的挑战 6 | 7 | **信息安全和信创化的强制要求** 8 | 9 | 大型企业尤其是银行，面临最强的信息安全监管及信创化、国产化要求，需要国产生态中能力突出的大模型。 10 | 11 | **开源大模型表现偏弱、自己训练成本高** 12 | 13 | 目前可私有化部署的大模型，其自然语言理解和代码生成的水平与GPT有一定差距；根据大语言模型论文做一些粗略的数学计算，如果用的是 14 | Facebook LLaMA，训练成本（不考虑迭代或者出错）大约是400 万美元，如果是谷歌PaLM，大约 2700 万美元。 15 | 16 | **与企业内部工具进行结合** 17 | 18 | 碎片化的应用提效效果有限，把 AI 无缝集成到BizDevOps 工具链中，技术难度尚未可知。 19 | 20 | ## 开发 AI 辅助研发提效的局限性 21 | 22 | **基于 GPT 模型的工具不符合信息安全要求** 23 | 24 | 目前大多工具基于 OpenAI GPT 构建，不能私有化部署，不符合信息安全的强制要求；需要寻找能够私有化部署且水平相当的替代品。 25 | 26 | **公开LLM 针对专业领域表现不佳，适用性差** 27 | 28 | 缺乏专业知识，对于某些专业领域缺乏足够的理解。它受训练数据中的影响，容易产生偏见和错误。 29 | 30 | **LLM 工具碎片化** 31 | 32 | 各类工具都是在一个个分散的工作节点上辅助，使用时来回切换工具的成本很高，整体端到端地提效不明显。 33 | 34 | 35 | -------------------------------------------------------------------------------- /src/develop-llm-app-best-practise.md: -------------------------------------------------------------------------------- 1 | # LLM 应用示例：最佳实践示例 2 | 3 | ## LLM 应用开发模式：轻量级 API 编排 4 | 5 | 在 LangChain 中使用了思维链的方式来选择合适的智能体（Agent），在 Co-mate 中，我们也是采取了类似的设计，在本地构建好函数，然后交由 6 | LLM 来分析用户的输入适合调用哪个函数。 7 | 8 | 如下是我们的 prompt 示例： 9 | 10 | ``` 11 | Answer the following questions as best you can. You have access to the following tools: 12 | 13 | introduce_system: introduce_system is a function to introduce a system. 14 | 15 | Use the following format: 16 | 17 | Question: the input question you must answer 18 | Thought: you should always think about what to do 19 | Action: the action to take, should be one of [introduce_system] 20 | Action Input: the input to the action 21 | Observation: the result of the action 22 | ... (this Thought/Action/Action Input/Observation can repeat N times) 23 | Thought: I now know the final answer 24 | Final Answer: the final answer to the original input question 25 | 26 | Begin! 27 | 28 | Question: Introduce the following system: https://github.com/archguard/ddd-monolithic-code-sample 29 | ``` 30 | 31 | 这里的 `Question` 便是用户的输入，然后再调用对应的 `introduce_system` 函数进行分析。 32 | 33 | ## LLM 应用开发模式：DSL 动态运行时 34 | 35 | 与事实能力相比，我们更信任 LLM 的编排能力，因此我们在 Co-mate 中采用了 DSL 的方式来编排函数，这样可以更加灵活的编排函数。 36 | 37 | 为了支撑这样的能力，我们在 Co-mate 中引入了 Kotlin 作为 DSL 的运行时： 38 | 39 | ```kotlin 40 | // 初始化运行时 41 | val repl = KotlinInterpreter() 42 | val mvcDslSpec = repl.evalCast(InterpreterRequest(code = mvcFoundation)) 43 | 44 | // 从用户的输入中获取 action 45 | val action = ComateToolingAction.from(action.lowercase()) 46 | 47 | // 添加默认的 DSL spec 48 | if (action == ComateToolingAction.FOUNDATION_SPEC_GOVERNANCE) { 49 | comateContext.spec = mvcDslSpec 50 | } 51 | ``` 52 | 53 | 对应的 DSL 示例（由 ChatGPT 根据 DDD 版本 spec 生成）： 54 | 55 | ```kotlin 56 | foundation { 57 | project_name { 58 | pattern("^([a-z0-9-]+)-([a-z0-9-]+)(-common)?\${'$'}") 59 | example("system1-webapp1") 60 | } 61 | 62 | layered { 63 | layer("controller") { 64 | pattern(".*\\.controller") { name shouldBe endsWith("Controller") } 65 | } 66 | layer("service") { 67 | pattern(".*\\.service") { 68 | name shouldBe endsWith("DTO", "Request", "Response", "Factory", "Service") 69 | } 70 | } 71 | layer("repository") { 72 | pattern(".*\\.repository") { name shouldBe endsWith("Entity", "Repository", "Mapper") } 73 | } 74 | 75 | dependency { 76 | "controller" dependedOn "service" 77 | "controller" dependedOn "repository" 78 | "service" dependedOn "repository" 79 | } 80 | } 81 | 82 | naming { 83 | class_level { 84 | style("CamelCase") 85 | pattern(".*") { name shouldNotBe contains("${'$'}") } 86 | } 87 | function_level { 88 | style("CamelCase") 89 | pattern(".*") { name shouldNotBe contains("${'$'}") } 90 | } 91 | } 92 | } 93 | ``` 94 | 95 | ## LLM 应用开发模式：本地小模型 96 | 97 | 在 Co-mate 中，我们在本地引入了 SentenceTransformer 来处理用户的输入，优在本地分析、匹配用户的输入，并处理。当匹配到结果后直接调用本地的函数，当匹配不到结果时调用远端的处理函数来处理。 98 | 99 | HuggingFace: [https://huggingface.co/sentence-transformers](https://huggingface.co/sentence-transformers) 100 | 101 | 在原理上主要是参考了 GitHub Copilot、 Bloop 的实现，通过本地的小模型来处理用户的输入，然后再通过远端的大模型来处理用户的输入。 102 | 103 | ### Rust 实现示例 104 | 105 | Rust 相关示例：[https://github.com/unit-mesh/unit-agent](https://github.com/unit-mesh/unit-agent) 106 | 107 | ```rust 108 | pub fn embed(&self, sequence: &str) -> anyhow::Result { 109 | let tokenizer_output = self.tokenizer.encode(sequence, true).unwrap(); 110 | 111 | let input_ids = tokenizer_output.get_ids(); 112 | let attention_mask = tokenizer_output.get_attention_mask(); 113 | let token_type_ids = tokenizer_output.get_type_ids(); 114 | let length = input_ids.len(); 115 | trace!("embedding {} tokens {:?}", length, sequence); 116 | 117 | let inputs_ids_array = ndarray::Array::from_shape_vec( 118 | (1, length), 119 | input_ids.iter().map(|&x| x as i64).collect(), 120 | )?; 121 | 122 | let attention_mask_array = ndarray::Array::from_shape_vec( 123 | (1, length), 124 | attention_mask.iter().map(|&x| x as i64).collect(), 125 | )?; 126 | 127 | let token_type_ids_array = ndarray::Array::from_shape_vec( 128 | (1, length), 129 | token_type_ids.iter().map(|&x| x as i64).collect(), 130 | )?; 131 | 132 | let outputs = self.session.run([ 133 | InputTensor::from_array(inputs_ids_array.into_dyn()), 134 | InputTensor::from_array(attention_mask_array.into_dyn()), 135 | InputTensor::from_array(token_type_ids_array.into_dyn()), 136 | ])?; 137 | 138 | let output_tensor: OrtOwnedTensor = outputs[0].try_extract().unwrap(); 139 | let sequence_embedding = &*output_tensor.view(); 140 | let pooled = sequence_embedding.mean_axis(Axis(1)).unwrap(); 141 | 142 | Ok(pooled.to_owned().as_slice().unwrap().to_vec()) 143 | } 144 | ``` 145 | 146 | ### Kotlin 实现示例 147 | 148 | ```kotlin 149 | class Semantic(val tokenizer: HuggingFaceTokenizer, val session: OrtSession, val env: OrtEnvironment) { 150 | fun embed( 151 | sequence: String, 152 | ): FloatArray { 153 | val tokenized = tokenizer.encode(sequence, true) 154 | 155 | val inputIds = tokenized.ids 156 | val attentionMask = tokenized.attentionMask 157 | val typeIds = tokenized.typeIds 158 | 159 | val tensorInput = OrtUtil.reshape(inputIds, longArrayOf(1, inputIds.size.toLong())) 160 | val tensorAttentionMask = OrtUtil.reshape(attentionMask, longArrayOf(1, attentionMask.size.toLong())) 161 | val tensorTypeIds = OrtUtil.reshape(typeIds, longArrayOf(1, typeIds.size.toLong())) 162 | 163 | val result = session.run( 164 | mapOf( 165 | "input_ids" to OnnxTensor.createTensor(env, tensorInput), 166 | "attention_mask" to OnnxTensor.createTensor(env, tensorAttentionMask), 167 | "token_type_ids" to OnnxTensor.createTensor(env, tensorTypeIds), 168 | ), 169 | ) 170 | 171 | val outputTensor = result.get(0) as OnnxTensor 172 | val output = outputTensor.floatBuffer.array() 173 | 174 | return output 175 | } 176 | 177 | 178 | companion object { 179 | fun create(): Semantic { 180 | val classLoader = Thread.currentThread().getContextClassLoader() 181 | 182 | val tokenizerPath = classLoader.getResource("model/tokenizer.json")!!.toURI() 183 | val onnxPath = classLoader.getResource("model/model.onnx")!!.toURI() 184 | 185 | try { 186 | val env: Map = HashMap() 187 | val array: List = tokenizerPath.toString().split("!") 188 | FileSystems.newFileSystem(URI.create(array[0]), env) 189 | } catch (e: Exception) { 190 | // e.printStackTrace() 191 | } 192 | 193 | val tokenizer = HuggingFaceTokenizer.newInstance(Paths.get(tokenizerPath)) 194 | val ortEnv = OrtEnvironment.getEnvironment() 195 | val sessionOptions = OrtSession.SessionOptions() 196 | 197 | // load onnxPath as byte[] 198 | val onnxPathAsByteArray = Files.readAllBytes(Paths.get(onnxPath)) 199 | 200 | val session = ortEnv.createSession(onnxPathAsByteArray, sessionOptions) 201 | 202 | return Semantic(tokenizer, session, ortEnv) 203 | } 204 | } 205 | } 206 | ``` 207 | 208 | ## LLM 应用开发模式：Stream 封装 209 | 210 | ### 服务端 API 调用：Kotlin 实现 211 | 212 | 机制：结合 callbackFlow 来实现 213 | 214 | ```kotlin 215 | fun stream(text: String): Flow { 216 | val systemMessage = ChatMessage(ChatMessageRole.USER.value(), text) 217 | 218 | messages.add(systemMessage) 219 | 220 | val completionRequest = ChatCompletionRequest.builder() 221 | .model(openAiVersion) 222 | .temperature(0.0) 223 | .messages(messages) 224 | .build() 225 | 226 | return callbackFlow { 227 | withContext(Dispatchers.IO) { 228 | service.streamChatCompletion(completionRequest) 229 | .doOnError(Throwable::printStackTrace) 230 | .blockingForEach { response -> 231 | val completion = response.choices[0].message 232 | if (completion != null && completion.content != null) { 233 | trySend(completion.content) 234 | } 235 | } 236 | 237 | close() 238 | } 239 | } 240 | } 241 | ``` 242 | 243 | ### 客户端 API 调用：TypeScript 实现 244 | 245 | 机制：依赖于 Vercel 的 AI 库，提供对于 Stream 的封装 246 | 247 | ```typescript 248 | import { Message, OpenAIStream, StreamingTextResponse } from 'ai' 249 | import { Configuration, OpenAIApi } from 'openai-edge' 250 | 251 | export async function stream(apiKey: string, messages: Message[], isStream: boolean = true) { 252 | let basePath = process.env.OPENAI_PROXY_URL 253 | if (basePath == null) { 254 | basePath = 'https://api.openai.com' 255 | } 256 | 257 | const configuration = new Configuration({ 258 | apiKey: apiKey || process.env.OPENAI_API_KEY, 259 | basePath 260 | }) 261 | 262 | const openai = new OpenAIApi(configuration) 263 | 264 | const res = await openai.createChatCompletion({ 265 | model: 'gpt-3.5-turbo', 266 | messages, 267 | temperature: 0.7, 268 | stream: isStream 269 | }) 270 | 271 | if (!isStream) { 272 | return res 273 | } 274 | 275 | const stream = OpenAIStream(res, {}) 276 | 277 | return new StreamingTextResponse(stream) 278 | } 279 | ``` 280 | 281 | ### 客户端 UI 实现：Fetch 282 | 283 | ```typescript 284 | const decoder = new TextDecoder() 285 | 286 | export function decodeAIStreamChunk(chunk: Uint8Array): string { 287 | return decoder.decode(chunk) 288 | } 289 | 290 | await fetch("/api/action/tooling", { 291 | method: "POST", 292 | body: JSON.stringify(tooling), 293 | }).then(async response => { 294 | onResult(await response.json()) 295 | let result = "" 296 | const reader = response.body.getReader() 297 | while (true) { 298 | const { done, value } = await reader.read() 299 | if (done) { 300 | break 301 | } 302 | 303 | result += decodeAIStreamChunk(value) 304 | onResult(result) 305 | } 306 | 307 | isPending = false 308 | }); 309 | ``` 310 | 311 | ### 服务端实现转发： Java + Spring 312 | 313 | WebFlux + Spring Boot 314 | 315 | ```java 316 | @RestController 317 | public class ChatController { 318 | 319 | private WebClient webClient = WebClient.create(); 320 | 321 | @PostMapping(value = "/api/chat", produces = MediaType.TEXT_EVENT_STREAM_VALUE) 322 | public SseEmitter chat(@RequestBody ChatInput input) throws IOException { 323 | SseEmitter emitter = new SseEmitter(); 324 | 325 | webClient.post() 326 | .uri(REMOTE_URL) 327 | .bodyValue(input) 328 | .exchangeToFlux(response -> { 329 | if (response.statusCode().is2xxSuccessful()) { 330 | return response.bodyToFlux(byte[].class) 331 | .map(String::new) 332 | .doOnNext(string -> { 333 | try { 334 | emitter.send(string); 335 | } catch (IOException e) { 336 | logger.error("Error while sending data: {}", e.getMessage()); 337 | emitter.completeWithError(e); 338 | } 339 | }) 340 | .doOnComplete(emitter::complete) 341 | .doOnError(emitter::completeWithError); 342 | } else { 343 | emitter.completeWithError(new RuntimeException("Error while calling remote service")); 344 | } 345 | }) 346 | .subscribe(); 347 | 348 | return emitter; 349 | } 350 | } 351 | ``` 352 | 353 | ### 服务端转发：Python 354 | 355 | FastAPI + OpenAI 356 | 357 | ```python 358 | def generate_reply_stream(input_data: ChatInput): 359 | prompt = input_data.message 360 | try: 361 | prompt = prompt 362 | response = openai.ChatCompletion.create( 363 | model=openai_model, 364 | temperature=temperature, 365 | max_tokens=max_tokens, 366 | n=max_responses, 367 | messages=[ 368 | {"role": "user", "content": prompt}, 369 | ], 370 | stream=True, 371 | ) 372 | except Exception as e: 373 | print("Error in creating campaigns from openAI:", str(e)) 374 | raise HTTPException(503, error503) 375 | try: 376 | for chunk in response: 377 | current_content = chunk["choices"][0]["delta"].get("content", "") 378 | yield current_content 379 | 380 | except Exception as e: 381 | print("OpenAI Response (Streaming) Error: " + str(e)) 382 | raise HTTPException(503, error503) 383 | 384 | 385 | @app.post("/api/chat", response_class=Response) 386 | async def chat(input_data: ChatInput): 387 | return StreamingResponse(generate_reply_stream(input_data), media_type="text/event-stream") 388 | ``` 389 | 390 | -------------------------------------------------------------------------------- /src/develop-llm-app-example-ai-devops.md: -------------------------------------------------------------------------------- 1 | # LLM 应用示例：AI + DevOps 2 | 3 | 现在，类似于 ChatGPT 和 Microsoft Copilot 这样的人工智能突破正在彻底改变软件行业。 4 | 基于人工智能的工具与基础大语言模型可以增强软件开发在设计、需求、测试、发布和运维等各个环节中的能力，提高质量和效率。 5 | 6 | ![SDLC Copilot](images/sdlc-copilot.png) 7 | 8 | ## 方式：梳理研发流程寻找突破点 9 | 10 | 依旧的，我们需要拆到足够小的工序，才能看到明显的效果。 11 | 12 | ![SDLC Process](images/llm-sdlc-processes.png) 13 | 14 | ## 试验 15 | 16 | 在这里，我们选择了一个比较典型的研发流程：需求、设计、开发、测试、发布、运维。 如下是架构设计的示例： 17 | 18 | ![SDLC Architecture](images/sdlc-step-by-steps.png) 19 | 20 | 需要注意的是，在这里需要以 zero-shot 的方式实现，以便于： 21 | 22 | 1. 更好的理解和使用 23 | 2. 工具化集成 24 | 25 | ### 需求 prompt 示例（部分） 26 | 27 | ```markdown 28 | 你是一个敏捷项目的 BA，请根据如下的信息，编写用户故事。 29 | 30 | 1. 你的项目是：### OKR 系统 ### 31 | 2. 背景是：### 作为一个员工，我希望能够及时更新我的 OKR 32 | 进展情况，并向团队报告我的进展情况，以便能够保持团队的透明度和协同性 ### 33 | 2. 我想要实现的功能是： ### 更新 OKR 进度 ###。 34 | 3. 你要仔细分析，并尽可能考虑不同的场景，不限于 ### ####。如果场景不存在，请不要编写。 35 | 4. 你的返回模板如下所示： 36 | 37 | ### 38 | 39 | 用户故事：可以选择宝贝出行服务 40 | 作为 xxx 41 | 我想 在xx出行的手机客户端里选择宝贝出行服务 42 | 以便于 我能够带宝宝打车出行的时候打到有儿童座椅的车 43 | 44 | AC 1: xxx 45 | Given xxx 46 | When xxx 47 | Then xxx 48 | 49 | ### 50 | ``` 51 | 52 | ### 测试用例 prompt 示例（部分） 53 | 54 | ```markdown 55 | 请分析如下的用户故事，按你的理解使用 markdown 表格输出测试用例，格式如下： 56 | 57 | 所属功能模块 用例编号 用例名称 前置条件 用例类型 操作步骤 优先级 预期结果 关联需求类型 58 | ```` 59 | 60 | ### 影响分析 prompt 示例（部分） 61 | 62 | ```markdown 63 | 我在实现一个 OKR 系统 的 作为一个员工，我希望能够及时更新我的 OKR 进展情况，并向团队报告我的进展情况，以便能够保持团队的透明度和协同性 64 | 的功能，需要修改哪些服务的代码？ 65 | 66 | 67 | 68 | | **服务** | **功能描述** | 69 | |----------|----------------------------------------------| 70 | | 用户管理服务 | 用于存储和管理员工的基本信息，如姓名、职位等，以便于识别员工并关联他们的 OKR。 | 71 | | 团队管理服务 | 用于存储和管理团队的基本信息，如团队名称、团队成员等，方便员工对齐团队目标。 | 72 | | OKR 管理服务 | 用于创建、更新和删除 OKR，同时支持查询功能，方便员工和团队查看和管理他们的 OKR。 | 73 | | 权限管理服务 | 用于控制不同角色的员工在系统中的权限，确保只有合适的人员可以发布或修改 OKR。 | 74 | | 通知服务 | 当有新的 OKR 发布或修改时，负责通知相关人员，以便他们了解最新的目标和进度。 | 75 | | 数据分析服务 | 对 OKR 数据进行分析，生成报告，以便管理层了解整体的目标完成情况和进度。 | 76 | | 集成服务 | 与其他企业系统（如项目管理、日程管理等）集成，实现数据同步和自动更新 OKR 的功能。 | 77 | ``` 78 | 79 | ### ... 80 | 81 | -------------------------------------------------------------------------------- /src/develop-llm-app-example-autodev.md: -------------------------------------------------------------------------------- 1 | # AI + DevOps 最后一公里：AutoDev 插件 2 | 3 | AI IDE 基本原理：没有魔法！全是 prompt! 🐶 4 | 5 | ![AI IDE 基本原理](images/ai-ide-princinple.png) 6 | 7 | > AutoDev 是一款高度自动化的 AI 辅助编程工具。AutoDev 能够与您的需求管理系统（例如 8 | > Jira、Trello、Github Issue 等）直接对接。在 IDE 中，您只需简单点击，AutoDev 9 | > 会根据您的需求自动为您生成代码。您所需做的，仅仅是对生成的代码进行质量检查。 10 | > 11 | 12 | 简单来说，AutoDev 定位是适用于私有化大语言模型 + 高度集成的 AI 编程助手。AutoDev 提供了一种 AutoCRUD 模式，其设计理解的过程是： 13 | 14 | 1. 从需求管理系统获取需求，并进行需求分析。 15 | 2. 结合源码与需求系统，选择最适合变更的入口（如 Java 中的 Controller） 16 | 3. 将需求与 Controller 交给 AI 分析，以实现代码的代码。 17 | 4. 根据 Controller 逐步自动完成其它部分代码（实现中…） 18 | 19 | 另外一种模式则是普通的 Copilot 模式，可以接入现有的大模型工具，实现一系列的 AI 代码辅助相关功能。 20 | 21 | GitHub： [https://github.com/unit-mesh/auto-dev](https://github.com/unit-mesh/auto-dev) 22 | 23 | 接入 LLM，我们不仅可以生成代码，还可以生成单元测试代码，从而提高测试效率和覆盖率。 24 | 25 | 让我们再展开看一看，基于现有的 AI 能力，会有哪些新可能性。 26 | 27 | ## 平台工程的变化与新机遇 28 | 29 | 而除了我们上述的 demo 之外，我们相信它带会其它带来一系列的变化。对于中大型组织的基础设施或者平台团队来说，要接入 AI 30 | 能力需要有更多的变化与机遇。 31 | 32 | > 33 | 平台工程是一种用来构建和运维支持软件交付和生命周期管理的自助式内部开发者平台的机制和架构。平台工程可以提高开发者的体验和生产力，提供自动化的基础设施操作。 34 | 平台工程是软件工程组织的新趋势，它可以优化开发者的工作流程，加速产品团队交付客户价值。 35 | 36 | 平台工程的核心思想是将平台视为一种产品，由专业的平台团队来创建和维护，为内部的客户（如开发者、数据科学家等）提供可复用的服务、组件和工具。 37 | 38 | ## 需求：自动化收敛、分析与完善 39 | 40 | 在现有的场景之下，已经有一系列的关于结合 AI 进行需求管理的尝试： 41 | 42 | - 自动化完善。对用户的反馈和数据的分析，自动识别和补充缺失的需求信息，例如自动识别用户提出的问题并转化为需求描述，自动补全需求的关键词和标签等。 43 | - 自动化分析。通过训练自带的领域知识，可以更好地评估和优化需求，发现潜在的问题和机会，提高需求的效率和效果。 44 | - 自动化收敛。结合其它 AI 技术，比如智能推荐、对话系统、多方协作等，可以帮助您更好地沟通和协调需求，收集和整合用户的反馈和痛点，提高需求的满意度和一致性。 45 | - 自动化迭代。结合人类反馈的 AI 数据，可以更好地更新和改进需求生成，适应不断变化的环境和用户需求，提高需求的持续性和创新性 46 | 47 | 尽管现有的几个方案：LangChain、llama-index 等暂时只支持 OpenAI，但是随着更多开源大语言模型的加入，未来会更易于落地。 48 | 49 | ## 工具链：智能的 IDE 50 | 51 | 对于现有的场景来说，已经相当的丰富，诸如于： 52 | 53 | - 自动化代码审查 54 | - 自动化测试 55 | - 自动化日志分析 56 | - AI 辅助编程 57 | - …… 58 | 59 | 诚然，诸如于 GitHub Copilot 等收费 AI 60 | 工具来说，对于大部分公司来说，贵可能是其次，重点是代码的安全性。而虽然国内各类新的模型层出不穷，但是大部分缺少编程相关的集成，又或者是编程能力比较弱。 61 | 然而，市面上也有只用于编程相关的模型，如 62 | Salesforce 在 Hugging Face 上提供的 16B CodeGen 模型。虽然，还需要经过一些小的微调，但是如 Replit 公司所言，效果还是非常不错的。 63 | 64 | 随后，便是类似于 AutoDev 针对于大语言模型进行的封装，简化普通开发人员的开发过程。 65 | 66 | ## 文档：超越搜索 67 | 68 | 在有了 LLM 和各种智能问答的基础上，我们还可以加入内部各种工具的文档和代码，以提供更全面、更智能的文档服务。例如，LangChain 69 | 构建的问答式文档，可以对企业内部的各种文档进行语义理解和智能问答，进而简化开发人员的学习成本。 70 | -------------------------------------------------------------------------------- /src/develop-llm-app-example-comate.md: -------------------------------------------------------------------------------- 1 | # LLM 应用示例：Co-mate 难点解析 2 | -------------------------------------------------------------------------------- /src/develop-llm-app-setup.md: -------------------------------------------------------------------------------- 1 | # 开发 LLM 应用之前 2 | 3 | 在你下决心开发一个 LLM 应用之前，你应该考虑一些问题。 4 | 5 | ## 买还是开发？ 6 | 7 | LLM 应用由 LLM + 应用两部分组成，所以会出现类似于下图的多种不同类似应用： 8 | 9 | ![四种不同类型的 LLM 应用](images/four-types-application.png) 10 | 11 | - AI 端到端应用。即直接面向最终用户的应用（含专有模型），诸如 ChatGPT、Midjourney 12 | - 应用 + 闭源基础模型。如基于 OpenAI、文心一言（他们提供了吗，我没收到）等 API 来构建应用。 13 | - 应用 + 专有模型。即基于开源基础模型，或者自有的模型，来构建端到端应用。 14 | - 应用 + 微调模型。基于开源模型 + 面向自己研发场景下来微调，以构建领域特定的应用。 15 | 16 | 不同的企业应根据自身的业务需求来选择不同的方案。 17 | 18 | ## 决策框架 19 | 20 | ## 业务与技术问题？ 21 | 22 | 在业务侧，你应该考虑： 23 | 24 | - 你的应用是否需要一个 LLM？ 25 | - 寻找合适的、稳定的 LLM 备用 API 26 | - 隐私与数据安全问题 27 | - 未来是否存在私有化部署与微调的可能性？ 28 | 29 | 在技术侧，你应该考虑： 30 | 31 | 1. 哪些部分可以使用 LLM？ 哪些部分不适合使用 LLM？ 32 | 2. Prompt 的编写与维护。编写好 prompt 不是一件容易的事情，需要大量的实践与经验。 33 | 3. 优化 LLM 的体验。在速度、准确率、稳定性上，LLM 都有很大的提升空间。 34 | 35 | -------------------------------------------------------------------------------- /src/develop-llm-app-with-workflow.md: -------------------------------------------------------------------------------- 1 | # LLM 应用开发模式：精细化流程 2 | 3 | 一个结合 AI 的自动化的工作流应该包含四个要素： 4 | 5 | - 场景模板化，即预设各种常见的工作场景，为用户提供快捷的开始工作的方式。 6 | - 交互式环境，包括但不限于输入框、按钮、编辑器、错误信息、帮助文档等，使用户能够与系统进行交互和反馈。 7 | - 格式化输出，为用户提供规范的输出结果，避免信息过载或无用信息。 8 | - 流程与工具集成，将不同的工具和流程集成到一个自动化的流程中，提高工作效率和准确性。同时，通过 AI 技术的支持，让系统能够智能化地处理数据和信息，进一步提高工作效率和准确性。 9 | 10 | 简单来说，就是我们依旧需要碳基生物作为检查官，来检查硅基生物输出是否合理？ 11 | 12 | ## 设计构建高质量流程 13 | 14 | 基于我们对 ChatGPT 的使用经验，我们建议在使用 ChatGPT 之前，先考虑如何设计高质量的流程。这里的高质量流程，指的是： 15 | 16 | - 明确的目标和目的：高质量的流程应该有明确的目标和目的，确保流程的设计和执行都能够达成预期的结果。 17 | - 易于理解和操作：高质量的流程应该简单易懂，让执行者能够轻松理解并操作。流程的设计应该尽可能避免复杂的步骤和冗长的说明，以免造成执行者的困惑和错误。 18 | - 明确的责任和角色：高质量的流程应该明确各个执行者的责任和角色，避免执行者的混淆和错误。流程设计者应该明确各个角色的职责和权限，确保流程的顺利执行。 19 | - 可度量和评估：高质量的流程应该能够被度量和评估。流程设计者应该设计合适的指标和评估方式，以便对流程的执行效果进行评估和改进。 20 | 21 | 如下是我们对于 SDLC + LLM 的探索过程中的展示示例： 22 | 23 | ![SDLC](images/llm-sdlc-processes.png) 24 | 25 | 将旅程拆得足够的详细，才能获得最好的效果。 26 | 27 | ## ChatFlow 的诞生动机：人类设计高质量流程 + AI 完成细节 28 | 29 | 在我使用了 ChatGPT （GPT 3.5）一个月多月之后，大抵算是掌握了它的脾气。简单来说，ChatGPT 即是一个硅基生物，也是一个非常好的人类助手。作为一个工具，你使用 prompt 的能力决定了它的上限和下限。 30 | 31 | 简单来说，ChatGPT 在经验丰富的开发人员手中，有一定 prompt 经历的人手中，会发挥非常强大的作用。而对于经验不那么丰富的开发人员，可能会因为缺乏任务分解能力，无法写出合理地 prompt，让 AI 有创意地瞎写代码。 32 | 33 | 诸如于，我们可以通过如下的注释，让 ChatGPT 或者 GitHub Copilot 直接生成可用的代码： 34 | 35 | ```jsx 36 | // 1. convert resources in src/assets/chatgpt/category/*.yml to json 37 | // 2. generate src/assets/chatgpt/category.json 38 | // the yaml file is like this: 39 | // ```yml 40 | // ··· 41 | ``` 42 | 43 | 这也就是为什么我们做了 [ClickPrompt]([https://github.com/prompt-engineering/click-prompt](https://github.com/prompt-engineering/click-prompt)) ， 用于一键轻松查看、分享和执行 Prompt。而在完善 ClickPrompt 的过程中，我们发现将 AI 绑定到自己的工作流中，才能更好地提升效率。因此，我们在 ClickPrompt 中提取了两个功能，构建了 ChatFlow： 44 | 45 | - ChatGPT 聊天室：一个集成了 ChatGPT API 的简易 ChatGPT聊天室。 46 | - ClickFlow：一个基于 Yaml 构建的工作流。 47 | 48 | 结合 ClickPrompt 不丰富的组件，它可以勉强 work 了。 49 | 50 | ## ChatFlow 是什么？ 51 | 52 | ![ChatFlow](images/chatflow-writing.png) 53 | 54 | ChatFlow 是一个基于自然语言处理（NLP）的流程编排工具，具有以下特点： 55 | 56 | - 易于理解的 YAML：ChatFlow 使用简单易懂的 YAML 格式来描述流程的各个元素，包括条件、循环和变量等。无需编程技能，让流程设计变得简单易懂。 57 | - 丰富的可视化组件：ChatFlow 提供了丰富的可视化组件，例如表格、图表和交互式界面等，让用户可以更加方便地与流程进行交互和管理。 58 | - 自动化执行流程：ChatFlow 使用 NLP 技术自动翻译自然语言描述的流程为可执行的代码，并支持自定义函数和自动生成文档功能，让用户更加灵活和高效地管理流程。 59 | 60 | 总之，ChatFlow 提供了一种灵活、易用、自动化的流程编排工具，让用户可以更加高效地管理复杂的流程，提高工作效率和准确性，同时降低工作的复杂性和学习成本。 61 | 62 | ## ChatFlow 示例 63 | 64 | 在过去的一段时间内，我们不断尝试开发一些工作流： 65 | 66 | 1. 需求与代码生成：从一个模糊的需求开始，生成标准的用户 Story（包含多个 AC），然后根据 AC 生成流程图、测试用例和测试代码。 67 | 2. 软件系统设计：从一个简单的系统开始，分析系统对应的用户旅程，生成对应的处理过程 DSL 等等，以帮助我们思考如何基于 AI 进行系统设计。 68 | 3. 写作的发散与探索：从一个主题开始，进行对应的发散和收敛，直至辅助我们完成一篇文章的草稿、大纲、内容编写。 69 | 4. ClickPrompt 工作流：围绕 ClickPrompt 项目的开发，结合创建 issue、issue 分析、Code Review 等构建的工作流。 70 | 71 | 在线示例：[https://www.clickprompt.org/zh-CN/click-flow/](https://www.clickprompt.org/zh-CN/click-flow/) 72 | 73 | ### ChatFlow 示例：需求与代码生成。 74 | 75 | 用于帮助开发人员快速生成代码并进行测试，从而加快开发进度和提高代码质量。 76 | 77 | ![](images/chatflow-ac.png) 78 | 79 | ### ChatFlow 示例：软件系统设计 80 | 81 | 用于帮助系统设计人员快速理解用户需求并生成对应的系统设计方案。 82 | 83 | ![](images/chatflow-software-design.png) 84 | 85 | ### ChatFlow 示例：写作的发散与探索 86 | 87 | 用于帮助写作人员快速生成文章并进行修改和编辑，从而提高写作效率和文章质量。 88 | 89 | ![ChatFlow](images/chatflow-writing.png) 90 | 91 | ### ChatFlow 示例：ClickPrompt 工作流 92 | 93 | 用于帮助开发团队快速解决问题并进行代码审查，从而加快项目进度和提高代码质量。 94 | 95 | ![](images/clickprompt-workflow.png) 96 | 97 | -------------------------------------------------------------------------------- /src/develop-llm-design-verification.md: -------------------------------------------------------------------------------- 1 | # 设计 LLM 效果验证实验 2 | 3 | 对于 LLM 而言，在进一步决定开发应用之前，我们需要对 LLM 的效果进行验证。验证的方式有很多种，例如： 4 | 5 | ## 示例格式 6 | 7 | - 研究目的：明确研究的目标和方向，阐述研究的意义和价值。 8 | - 研究背景：介绍研究领域的相关背景和现状，说明研究的必要性。 9 | - 研究问题：明确需要解决的问题，阐明研究的主要内容和目标。 10 | - 研究方法：阐述研究方法和实验的具体设计，包括实验的流程、步骤、数据采集和处理方法等。 11 | - 实验过程：详细描述实验的过程和实验结果，包括实验设计、数据采集、数据分析和实验结果等。 12 | - 结果分析：对实验结果进行分析和解释，包括实验结果的统计分析和数据可视化。 13 | - 结论和启示：总结实验结果，得出结论并提出启示和建议，指出实验的贡献和局限性。 14 | 15 | ## ChatGPT + Copilot 端到端示例 16 | 17 | 研究目的：ChatGPT + Copilot 在企业应用中，从需求、编码、测试端到端的辅助能力和提效作用评估 18 | 19 | 研究过程： 20 | 21 | - 第1步：选择一个真实的项目需求: Thoughtworks OKR 工具 22 | - 第2步：使用 ChatGPT 来完成领域术语定义和竞品分析启发，再到MVP特性设计启发 23 | - 第3步：使用 ChatGPT 来完成特性的需求分析，展示可视化的用户旅程、功能需求拆分及格式化编写、验收标准定义 24 | - 第4步：尝试使用 ChatGPT 来把验收标准转化为UML设计图 25 | - 第5步：使用 ChatGPT 生成 API，在通过Copilot 生成代码 26 | - 第6步：... 27 | - 第x步：使用 ChatGPT 生成发布文档 28 | 29 | 研究结论： 30 | 31 | 辅助能力评估： 整体提升 20%~30% 效率。其中重复性工作，如需求格式、代码编写、测试用例、单元测试提升较为明显。 32 | 33 | 局限性： 34 | 35 | - 每次反馈结果都不一致，需要人工来判断这个结果是否“合理/有用”, 能否进入下一步； 36 | - 需要结合经验迭代优化给出更细的细节要求提示，生成结果才会更好； 37 | - … 38 | 39 | 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /src/develop-llm-intergration-patterns.md: -------------------------------------------------------------------------------- 1 | # LLM 集成模式 2 | 3 | 围绕于我们的开发旅程，我们思考了一些有意思的 ChatGPT 相关的集成模式，这些模式方便我们后续在国内的其它 LLM（大语言模型）中使用。 4 | 5 | ## 无限的场景，无限的可能 6 | 7 | 如大家所知，ChatGPT 可用于多种自然语言处理场景，包括： 8 | 9 | 1. 聊天机器人，解决问题，提供建议。 10 | 2. 自然语言生成，生成高质量文章等。 11 | 3. 情感分析，分析用户评论和反馈。 12 | 4. 语言翻译，将一种语言翻译成另一种语言。 13 | 5. 自然语言理解，帮助机器理解和处理自然语言。 14 | 6. …… 15 | 16 | 当然了，ChatGPT 的场景不限于上面这几个，我们也见到了非常有意思的和架构设计、法律法规检查等一系列有意思的场景。 17 | 18 | ## 模式 19 | 20 | 对应的模式列表： 21 | 22 | ### **生成器模式** 23 | 24 | > 使用 prompt 生成器生成特定输入，提高 ChatGPT 回答准确度和全面性。例如，使用 prompt 生成器生成法律咨询问题，ChatGPT 25 | > 回答法律问题；在问答领域中，使用预定义的问题模板作为输入，生成相应的回答，能够提高 ChatGPT 的回答准确度和全面性。 26 | 27 | 生成器模式是我们最早设计的强化 Prompt 场景，它非常容易实现，只需要预设好一些模板，就能很好地工作。 28 | 29 | ### 系统集成模式 30 | 31 | > 将 ChatGPT 与其他系统集成，实现数据交换和通信。例如，将 ChatGPT 与电子邮件系统集成，自动回复邮件；在电商平台中，ChatGPT 32 | > 可以与订单系统穿插，以便处理用户的购物咨询和下单请求。 33 | 34 | 在 ClickPrompt 中，我们通过集成 HuggingFace 来实现，一个简单的场景，生成图形的功能。 35 | 36 | ### **管道模式**: 37 | 38 | > 在 ChatGPT 中定义处理流程，对每个输入进行处理并生成输出。例如，将 ChatGPT 用于自动化客服，对用户的问题进行分类和回复；在客服领域中，ChatGPT 39 | > 可以通过管道模式实现意图识别、实体识别、回答生成等一系列流程。 40 | 41 | 在 ClickPrompt 中，我们预期通过 ChatGPT 来与人类交互，对每一步的输入和输出校正，进而完善系统的架构设计。 42 | 43 | ### **目标引导模式** 44 | 45 | 将对话分成场景，并为每个场景设定目标，引导 ChatGPT 生成相关回答。例如，将 ChatGPT 用于旅游规划，引导用户选择目的地并提供相关信息；在旅游领域中，ChatGPT 46 | 可以根据场景（如酒店预订、景点推荐）来生成相应的回答。 47 | 48 | 在 ClickPrompt 中，我们通过 ChatGPT 来生成 Stable Diffusion 的 tag，进而完善文本到图形的转换。 49 | 50 | ### **协同模式** 51 | 52 | > 将 ChatGPT 与其他 AI 技术集成，生成更人性化的回答。例如，将 ChatGPT 与情感分析技术集成，生成更符合用户情感的回答；在语音助手中，ChatGPT 53 | > 可以与语音识别技术协同，能够更好地理解用户的语义和情感，并生成更加自然的回答。 54 | 55 | 在 ClickPrompt 中，我们还想做的事情就是通过接入语音功能，来实现语音直转文本，进而输出。 56 | 57 | ### **迁移学习模式:** 58 | 59 | > 通过将已经学习到的知识应用于新任务中，来改善模型性能和加快学习速度的一种机器学习方法。例如，将预先训练好的 ChatGPT 60 | > 模型与公司或行业特定的语料库进行微调，以适应特定领域和任务的需求，从而快速构建智能客服机器人。 61 | 62 | 由于 ChatGPT 训练周期的问题，总存在一些知识老旧的问题。因为在日常的场景中，我们也可以让 ChatGPT 中阅读一些文章，围绕于这些文章，输出新的洞见。 63 | 64 | ### **混合模式**: 65 | 66 | > 将多个不同类型的模型组合，提高回答准确度和全面性。在问答领域中，将检索模型、知识图谱模型和生成模型混合使用，可以提高回答的准确度和覆盖范围。 67 | 68 | 我们还在寻找合适的案例，来结合这种模式。 69 | 70 | ### **转换器模式**: 71 | 72 | > 使用转换器将输入转换为 ChatGPT 可理解的格式，提高ChatGPT对输入的理解和处理能力。例如，使用语音转换器将语音转换为 ChatGPT 73 | > 可理解的文本格式，从而实现语音交互。 74 | 75 | 简单来说，就是将步骤转换为格式，通过 ChatGPT 进行格式转换，如在我们的例子中，有一个使用 ChatGPT 实现 i18n 的代码转换。 76 | 77 | ### **强化学习模式**（ChatGPT 推荐） 78 | 79 | 基于增量学习的 ChatGPT 80 | 81 | > 使用增量学习技术对ChatGPT进行训练和调整，提高回答准确度和全面性。例如，将ChatGPT用于股票投资，使用增量学习技术对ChatGPT进行训练和调整，从而实现更精准的股票推荐和投资建议。 82 | 83 | **基于深度强化学习的 ChatGPT** 84 | 85 | > 使用深度强化学习技术优化ChatGPT的响应速度和回答质量，提高对话质量。例如，将ChatGPT用于智能家居，使用深度强化学习技术优化ChatGPT的响应速度和回答质量，从而实现更快速、准确的家居控制和交互体验。 86 | 87 | ### **验证模式**（ChatGPT 推荐） 88 | 89 | **安全模式** 90 | 91 | > 为保护用户隐私和系统安全，对敏感信息进行脱敏、加密等处理，防止恶意攻击和数据泄露。例如，在医疗健康领域中，ChatGPT 92 | > 用于病例诊断和病情分析时，需要对患者隐私信息进行保护。 93 | 94 | **自我监督模式** 95 | 96 | > 利用 ChatGPT 自身生成的回答作为监督信号，对模型进行自我监督和调整，提高回答准确度。例如，将 ChatGPT 97 | > 用于自动化翻译，利用自我监督模式对模型进行调整，从而实现更准确的翻译结果。 98 | -------------------------------------------------------------------------------- /src/dsl-driven-development.md: -------------------------------------------------------------------------------- 1 | # LLM 应用开发模式：DSL 驱动开发 2 | 3 | 设计 DSL 的目的，在于让开发者可以用更简单的方式来表达自己的想法。DSL 通常是一种领域特定语言，它的语法和语义都是针对某个特定领域而设计的。 4 | 除了具备很好的易读性，作为一个 LLM 与机器的语言，它还应该具备易写性。 5 | 6 | ## 常规 DSL：数据格式 DSL 7 | 8 | 常规 DSL，诸如于 JSON、YAML、XML 等，是一种用于描述数据的语言。 9 | 10 | 于是，我们让 ChatGPT 帮我们设计了一个 DSL 来描述：帮我设计一个 DSL 来表示一个系统的处理流程。然后，得到了一个 DSL： 11 | 12 | ```kotlin 13 | System("BlogSystem") { 14 | Entities { 15 | Blog { title: string, ..., comments: [Comment]? }, 16 | Comment { ...} 17 | } 18 | Operation { 19 | Ops("CreateBlog", { 20 | in: { title: string, description: string }, 21 | out: { id: number } 22 | pre: title is unique and (title.length > 5 && title.length < 120) 23 | post: id is not null 24 | }) 25 | } 26 | API { 27 | Route(path: String, method: HttpMethod operation: Operation) 28 | } 29 | } 30 | ``` 31 | 32 | 它可以分析某一个场景的业务，基于这个业务做分析。在这个 DSL，反复让 ChatGPT 设计之后，勉强可以详细拆开任务： 33 | 34 | - Operation。通过 Ops 的输入、输出、先验条件、后验条件，我们可以构建出更准确的函数。 35 | - Entitiies。是可独立从 DSL 拆解出来的，并且与数据库结构是绑定的，所以可以用来做数据库设计（ChatGPT 设计了一个诡异的 []? 36 | 语法 ）。 37 | - API。API 其实对于编码的帮助是有限的，不过其最大的用处是用于自动化测试，用于确保 ChatGPT 的代码是正确的。 38 | 39 | 所以，我们只需要拆解任务，并发送到各个管道里，再 merge 一下，就可能能得到一份可工作的代码。至于，前端部分，我们可以用类似的方式来设计。 40 | 41 | ## 流式 DSL 42 | 43 | 由于 LLM 的 stream response 特性，我们可以设计 stream DSL 来处理它们。流式响应 DSL 是一种特殊的 DSL，它的特点是： 44 | 45 | 1. 支持流式数据处理：与传统的批处理方式不同，流式响应 DSL 能够处理实时产生的数据流，无需等待所有数据都到齐才开始处理。 46 | 2. 高效的数据处理：流式响应 DSL 可以对数据进行实时处理和转换，而不需要将所有数据都加载到内存中，这使得它可以处理非常大的数据集。 47 | 3. 灵活的数据处理：流式响应 DSL 具有高度的灵活性，可以根据具体的需求进行定制和扩展。例如，可以通过添加不同的操作符来实现数据的过滤、聚合、转换等操作。 48 | 49 | 示例： 50 | 51 | ```markdown 52 | HasMatchFunction: true 53 | Thought: I need to introduce the system to the team and ensure that it aligns with our overall architecture and 54 | governance policies. 55 | Action: introduce_system 56 | Action Input: https://github.com/archguard/ddd-monolithic-code-sample 57 | ``` 58 | 59 | 我们预期它可以实时解析用户的输入，并渲染到 UI 上。这样，用户就可以实时看到自己的输入。 60 | 61 | 对应的解析代码示例： 62 | 63 | ```javascript 64 | const hasMatchFunctionRegex = /\s*HasMatchFunction:\s*(.*(?:\n(?!\s*\/\/).*)*)/i; 65 | const thoughtRegex = /\s*Thought:\s*(.*(?:\n(?!\s*\/\/).*)*)/i; 66 | const actionRegex = /\s*Action:\s*(.*(?:\n(?!\s*\/\/).*)*)/i; 67 | const actionInputRegex = /\s*Action\s*Input:\s*(.*(?:\n(?!\s*\/\/).*)*)/i; 68 | 69 | function messageToThought (splitContent: string[]) { 70 | let thought = thoughtRegex.exec(splitContent[0])?.[1] ?? ""; 71 | let action = "" 72 | if (splitContent.length >= 2) { 73 | action = actionRegex.exec(splitContent[1])?.[1] ?? ""; 74 | } 75 | 76 | let actionInput = "" 77 | if (splitContent.length >= 3) { 78 | actionInput = actionInputRegex.exec(splitContent[2])?.[1] ?? ""; 79 | } 80 | 81 | let tooling: ToolingThought = { 82 | thought: thought, 83 | action: action, 84 | actionInput: actionInput 85 | } 86 | 87 | return tooling; 88 | } 89 | ``` 90 | 91 | ## 内部 DSL 92 | 93 | 内部DSL是一种特殊的DSL，它的语法与宿主编程语言的语法相同或相似，并且可以直接嵌入到宿主编程语言中，不需要额外的解析器。 94 | 这使得开发人员能够以一种更直观、声明性的方式来描述特定领域的问题和解决方案。 95 | 96 | 特点如下： 97 | 98 | - 与编程语言的语法相同：内部DSL的语法与宿主编程语言的语法相同或相似，因此可以直接嵌入到宿主编程语言的代码中，不需要额外的解析器或转换器。这使得内部DSL更容易理解、编写和维护，因为开发人员可以利用已经熟悉的编程语言知识和工具。 99 | - 直接嵌入到宿主语言：内部DSL可以直接嵌入到宿主编程语言的代码中，并与宿主语言的功能和库进行无缝集成。这意味着可以在内部DSL中直接调用宿主语言的函数、类和其他特性，从而充分利用宿主语言的强大功能和生态系统。 100 | - 101 | 基于宿主语言的类型系统和语义：由于内部DSL直接嵌入到宿主编程语言中，它可以完全利用宿主语言的类型系统和语义。这使得内部DSL可以提供更严格的类型检查和编译时验证，并且可以与宿主语言的工具链和开发环境无缝集成，例如代码补全、静态分析和调试。 102 | - 可扩展性：内部DSL可以利用宿主编程语言的灵活性和可扩展性进行自定义和扩展。开发人员可以使用宿主语言的特性来定义新的DSL构造，增加DSL的表达能力和领域特定性。 103 | 104 | 以Kotlin语言为例，它提供了强大的内部DSL支持。我们可以利用Kotlin的语法和特性来创建具有领域特定性的DSL，并将其嵌入到Kotlin代码中。 105 | 详细可以参考：[https://kotlinlang.org/docs/type-safe-builders.html](https://kotlinlang.org/docs/type-safe-builders.html) 106 | 107 | ### 简单示例 108 | 109 | 让我们看一个简单的例子来说明内部DSL的用法。假设我们正在开发一个配置库，用于配置不同环境下的应用程序设置。我们可以使用内部DSL来定义和使用配置： 110 | 111 | ```kotlin 112 | class AppConfig { 113 | var port: Int = 8080 114 | var dbName: String = "mydb" 115 | var username: String = "admin" 116 | var password: String = "password" 117 | } 118 | 119 | fun configure(block: AppConfig.() -> Unit): AppConfig { 120 | val config = AppConfig() 121 | config.block() 122 | return config 123 | } 124 | 125 | val appConfig = configure { 126 | port = 9000 127 | dbName = "productiondb" 128 | username = "user" 129 | password = "securepassword" 130 | } 131 | ``` 132 | 133 | 在上面的例子中，我们定义了一个名为AppConfig的类，表示应用程序的配置。然后，我们定义了一个configure函数，它接受一个扩展函数类型的参数， 134 | 并在该函数中创建了一个AppConfig对象。通过调用block函数来执行扩展函数，并在其中进行配置。 135 | 136 | 在使用内部DSL时，我们可以直接在代码中使用自然语言或领域特定的语法来配置应用程序。在示例中，我们调用configure函数并提供一个Lambda表达式作为参数， 137 | 通过设置属性来配置AppConfig对象。 138 | 139 | ### ArchGuard Co-mate 示例 140 | 141 | 在 Co-mate 中，我们便主要采用这种方式来描述软件的架构： 142 | 143 | ```kotlin 144 | architecture { 145 | system("TicketBooking") { 146 | connection("Reservation" to "Ticket") 147 | } 148 | } 149 | ``` 150 | 151 | 对应的示例实现代码： 152 | 153 | ```kotlin 154 | fun architecture(function: ArchitectureSpec.() -> Unit): ArchitectureSpec { 155 | val spec = ArchitectureSpec() 156 | spec.function() 157 | return spec 158 | } 159 | 160 | class ArchitectureSpec : Spec { 161 | override fun default(): Spec { 162 | return defaultSpec() 163 | } 164 | 165 | override fun exec(element: String): List { 166 | return listOf() 167 | } 168 | 169 | fun system(systemName: String, function: SystemDeclaration.() -> Unit): SystemDeclaration { 170 | val system = SystemDeclaration(systemName) 171 | system.function() 172 | return system 173 | } 174 | 175 | companion object { 176 | fun defaultSpec(): ArchitectureSpec { 177 | return architecture { 178 | system("TicketBooking") { 179 | connection("Reservation" to "Ticket") 180 | } 181 | } 182 | } 183 | } 184 | } 185 | 186 | class ConnectionDeclaration(val source: String, val target: String) : BaseDeclaration 187 | class SystemDeclaration(name: String) : BaseDeclaration { 188 | fun component(componentName: String, function: ComponentDeclaration.() -> Unit): ComponentDeclaration { 189 | val component = ComponentDeclaration(componentName) 190 | component.function() 191 | return component 192 | } 193 | 194 | fun connection(pair: Pair, function: ConnectionDeclaration.() -> Unit?): ConnectionDeclaration { 195 | val connection = ConnectionDeclaration(pair.first, pair.second) 196 | connection.function() 197 | return connection 198 | } 199 | 200 | fun connection(pair: Pair): ConnectionDeclaration { 201 | return ConnectionDeclaration(pair.first, pair.second) 202 | } 203 | 204 | } 205 | 206 | class ComponentDeclaration(name: String) : BaseDeclaration { 207 | fun module(moduleName: String, function: ModuleDeclaration.() -> Unit): ModuleDeclaration { 208 | val module = ModuleDeclaration(moduleName) 209 | module.function() 210 | return module 211 | } 212 | } 213 | 214 | class ModuleDeclaration(name: String) : BaseDeclaration 215 | ``` 216 | 217 | ## 端到端 DSL 示例 218 | 219 | ### 阶段一：让 ChatGPT 与你学 DDD 220 | 221 | 说了，这么多我们来看一个结合我之前设计的 DSL 示例，即 [Fklang](https://github.com/feakin/fklang)。 222 | 223 | 在 Fklang 中，我们采用下面的形式来表示 ContextMap： 224 | 225 | ```yaml 226 | ContextMap TicketBooking { 227 | Reservation -> Cinema; 228 | Reservation -> Movie; 229 | Reservation -> User; 230 | } 231 | ``` 232 | 233 | 但是，自己设计这样的 DSL 太累了，可以让 ChatGPT 来设计。在你开始之前，需要确认一下 ChatGPT 中的 DDD、DSL、事件风暴等的概念是否与你理解的一致。 234 | 235 | 第一个问题：`设计一个 DSL 来表示 DDD 里的 Context Map 。` 236 | 237 | ```yaml 238 | ContextMap: 239 | Subdomain { Name: [ subdomain_name ] } 240 | [ CollaboratesWith: [ other_subdomain_name ], ... ] 241 | [ ConformistWith: [ other_subdomain_name ], ... ] 242 | [ Antagonizes: [ other_subdomain_name ], ... ] 243 | ... 244 | ``` 245 | 246 | 第二个问题：用这个 ContextMap DSL 对在线电影订票系统建模。对于其它问题也是相似的。 247 | 248 | 第三个问题：设计一个 DSL 来描述事件风暴的 事件建模 吗？ 249 | 250 | 第四个问题：能用 事件建模的 DSL 来表示用户购票的流程吗？ 251 | 252 | 一旦，我们觉得设计跑歪了，就可以重新设计。如果下是生成的复杂的 DSL： 253 | 254 | ```yaml 255 | EventStorming: 256 | Domain { Name: "电影订票系统" } 257 | Event { Name: "用户提交订单" } 258 | Triggered By: "用户选择电影、场次、座位，确认订单" 259 | Description: "用户提交订单，包括所选电影、场次、座位等信息" 260 | Actors: [ "用户" ] 261 | Action: "将用户提交的订单信息保存到订单数据库中" 262 | Outcome: "订单状态被标记为已提交" 263 | ``` 264 | 265 | 第五个问题…… 266 | 267 | 剩下的你都会了，不会的，可以问 ChatGPT。 268 | 269 | ### 阶段二：完整设计 + DSL 生成 270 | 271 | 第一个问题：能总结一下，我们这里用 DDD 设计 购票系统到落地代码的过程吗？ 272 | 273 | 第二个问题：能为每个过程，设计一个合理的 DSL 吗，并展示他们？ 274 | 275 | 展示一部分神奇的 DSL： 276 | 277 | ```markdown 278 | generate java-code from-domain-model 279 | target-package: com.example.movieticket.order 280 | source-model: order-domain-model 281 | 282 | service-mapper 订单服务映射 283 | map-method: 查询电影 284 | to-class: MovieRepository 285 | to-method: findBySchedule 286 | 287 | map-method: 查询座位 288 | to-class: SeatRepository 289 | to-method: findByRowAndColumnAndStatus 290 | ``` 291 | 292 | 现在，有意思的地方来，有了上面的一系列 DSL 之后，我们就可以接入到代码系统中。 293 | 294 | -------------------------------------------------------------------------------- /src/finetune-bizdevops-codegen.md: -------------------------------------------------------------------------------- 1 | # LLM 微调示例：辅助代码生成 2 | 3 | ### 步骤 1. 准备数据 4 | 5 | 1. 下载 GitHub 上的项目（需要包含测试用例） 6 | 2. 遍历 `src/main` 下的 Java 文件。 7 | 3. 生成每个类的基本信息： 8 | 9 | ``` 10 | PostService(PostRepository, UserRepository, ImageService) 11 | - fields: postRepository:PostRepository, userRepository:UserRepository, userPosts:Set, imageService:ImageService 12 | - methods: findAll(): List, addNewPost(Post): Post, saveImageToPost(String, MultipartFile, Post): int 13 | ``` 14 | 15 | ### 步骤 2. 生成指令 16 | 17 | 预期 JSON 格式： 18 | 19 | - instruction: Implement the method ${methodName} 20 | - input: ${classInformation} 21 | - output: ${code} 22 | 23 | 示例： 24 | 25 | ``` 26 | {"instruction":"Implement the method action","input":"com.thoughtworks.go.config.rules.AbstractDirective(DirectiveType, DirectiveType, String, String, String)\n- fields: action:String, type:String, resource:String, configErrors:ConfigErrors, directiveType:DirectiveType\n- methods: validate(ValidationContext): void, isInvalid(String, List): boolean, matchesAction(String): boolean, matchesType(Class): boolean, matchesResource(String): boolean, errors(): ConfigErrors, addError(String, String): void, equals(Object): boolean, action(): String, type(): String, resource(): String, hashCode(): int, hasErrors(): boolean, getDirectiveType(): DirectiveType","output":"public abstract class AbstractDirective implements Directive {\n\n @ConfigAttribute(value = \"action\", optional = false)\n protected String action;\n\n @ConfigAttribute(value = \"type\", optional = false)\n protected String type;\n\n @ConfigValue\n private String resource;\n\n private final ConfigErrors configErrors = new ConfigErrors();\n\n private DirectiveType directiveType;\n\n public AbstractDirective(DirectiveType allow) {\n this.directiveType = allow;\n }\n\n public AbstractDirective(DirectiveType allow, String action, String type, String resource) {\n this.directiveType = allow;\n this.action = action;\n this.type = type;\n this.resource = resource;\n }\n\n @Override\n public String action() {\n return this.action;\n }\n}\n"} 27 | ``` 28 | 29 | ### 类信息格式 30 | 31 | 格式规范： 32 | 33 | ``` 34 | 包名.类名(类的构造类型) 35 | - fields：成员变量集合（变量名:类型） 36 | - methods：方法抽象集合（方法名(参数类型): 输出类型） 37 | ``` 38 | 39 | 结果： 40 | 41 | ``` 42 | com.thoughtworks.go.config.rules.AbstractDirective(DirectiveType, DirectiveType, String, String, String) 43 | - fields: action:String, type:String, resource:String, configErrors:ConfigErrors, directiveType:DirectiveType 44 | - methods: validate(ValidationContext): void, isInvalid(String, List): boolean, matchesAction(String): boolean, matchesType(Class): boolean, matchesResource(String): boolean, errors(): ConfigErrors, addError(String, String): void, equals(Object): boolean, action(): String, type(): String, resource(): String, hashCode(): int, hasErrors(): boolean, getDirectiveType(): DirectiveType 45 | ``` 46 | 47 | ### 其它：核心代码逻辑 48 | 49 | ```kotlin 50 | val javaProcessor = JavaProcessor(file.readText()) 51 | val shotClass = javaProcessor.toShortClass() ?: return@forEach 52 | 53 | javaProcessor 54 | .removePackage() 55 | .removeAllImport() 56 | .removeLicenseInfoBeforeImport() 57 | 58 | javaProcessor.splitMethods().forEach { (key, value) -> 59 | CodegenPrompt( 60 | instruction = "Implement the method $key", 61 | input = shotClass.toString(), 62 | output = value 63 | ).let { prompt -> 64 | val output = Json.encodeToString(prompt) 65 | File("$targetPath${key}.json").writeText(output) 66 | } 67 | } 68 | ``` 69 | -------------------------------------------------------------------------------- /src/finetune-bizdevops-data.md: -------------------------------------------------------------------------------- 1 | # LLM 微调数据准备：四种方法 2 | 3 | 在学习炼丹（训练模型）的同时，我们也在探索更有效的方式。 4 | 5 | ## 代码示例生成法：文本生成 SQL 6 | 7 | 这种方式通过输入一些示例文本和目标代码，让 AI 模型学习如何生成符合目标的代码。模型会根据示例代码和目标代码的特征和规律，学习生成类似的代码。由于的是输入文本，所以生成的代码也存在一定的随机性。这种方式适用于生成通用代码，例如生成一些常见的数据处理、图形化界面等代码。 8 | 9 | 我们找了一个 HuggingFace 上的数据集，训练了一个 LLaMA 的 LoRA。作为一个失败的版本，由于数据集太小、质量不太高，所以生成的也比较奇怪。 10 | 11 | 示例输入： 12 | 13 | ```java 14 | evaluate("text to sql", "谁是最美丽的人", 0.1, 0.75, 40, 4, 512) 15 | ``` 16 | 17 | 示例输出： 18 | 19 | ```java 20 | SELECT MOST BEAUTIFUL FROM table WHERE BEAUTIFUL = 最美丽的人 21 | ``` 22 | 23 | 比较明显的问题是，由于不知道对应的表等信息，所以生成出来的永远不尽人意。理想的方式是，训练时候加入表信息，并进行预处理融入表信息等等。 24 | 25 | ## 测试驱动生成法：测试用例生成 26 | 27 | 这种方式是将测试代码作为输入，生成适合测试代码的业务代码。这种方式能够更准确地生成适合特定业务场景的代码，因为测试代码通常会包含业务场景的特征和规律。同时，由于输入的测试代码比较固定，所以生成的代码也比较稳定。这种方式适用于生成适合测试代码的业务代码。 28 | 29 | 我们自己写了测试方法的解析，以及对应的类信息，来更好地生成测试代码，数据集大概在 8000 个。 30 | 31 | 输入示例： 32 | 33 | ```java 34 | evaluate("write test", """ 35 | public Set listFilesUsingJavaIO(String dir) { 36 | return Stream.of(new File(dir).listFiles()) 37 | .filter(file -> !file.isDirectory()) 38 | .map(File::getName) 39 | .collect(Collectors.toSet()); 40 | } 41 | """, 0.1, 0.75, 40, 4, 512) 42 | ``` 43 | 44 | 输出示例： 45 | 46 | ```java 47 | @Test 48 | public void shouldListFilesUsingJavaIO() { 49 | Set files = ListFilesUsingJavaIO.listFilesUsingJavaIO(new File("dir")); 50 | assertThat(files, containsInAnyOrder("file1", "file2", "file3")); 51 | } 52 | ``` 53 | 54 | 从结果来说，既然没有给对应的类信息，生成的测试用例还是可以的。不过，还存在一定的数据集太小，以及 LLaMA 权重的问题，导致生成的代码有一定的问题。 55 | 56 | ## 元数据辅助生成法：代码辅助生成 57 | 58 | 结合元信息的代码生成方式会提供更多的元数据信息，如变量类型、函数参数等，来帮助模型更准确地生成代码。这种方式能够更准确地生成符合特定需求的代码，因为提供的元数据信息能够帮助模型更好地理解代码的语义和结构。这种方式适用于生成通用代码。 59 | 60 | 我们采用的方式是让 LLM 学会填空，算是比较经典的方式。为了避免大小导致的问题，我们探索了一下给 API 的行数，只提供类的信息。 61 | 62 | 输入示例： 63 | 64 | ```java 65 | evaluate("Implement the method updatePostCommentsSize", "PostRepository()\n- methods: findById(Long): Optional, updatePostCommentsSize(int, Long): void, findAllByPostTopics(String): List, findDistinctByPostTopics(String): List", 0.1, 0.75, 40, 4, 512) 66 | ``` 67 | 68 | 输出示例： 69 | 70 | ```java 71 | public class PostRepository { 72 | public void updatePostCommentsSize(int size, Long postId) { 73 | Post post = findById(postId); 74 | if (post == null) { 75 | return; 76 | } 77 | post.setPostCommentsSize(size); 78 | save(post); 79 | } 80 | } 81 | ``` 82 | 83 | 从结果来说，写 CRUD 的代码质量还行，不过考虑到数据集来说，还是有进一步的改进空间。由于的缺点是，为了实现这样的功能，还需要进一步和各类工具整合到一起。 84 | 85 | ## 信息匹配生成法：文本转 Repository 86 | 87 | 结合表信息的 SQL + Repository 生成方式会通过多步骤结合数据源中的表信息来生成符合需求的 SQL + Repository 语句。这种方式能够更准确地生成符合特定需求的 SQL 语句，因为结合了数据表信息，能够更好地理解数据表的结构和关系。这种方式适用于生成符合需求的 SQL 语句。 88 | 89 | 我们采用的方式是会对输入完的结果进行预处理，以生成一个带表等信息的文本，并添加表的信息。如此一来，生成的数据会更加准确。 90 | 91 | 原数据格式示例： 92 | 93 | ```markdown 94 | instruction: 95 | 我想查找特定月份（monthly_id）下在某个日期（date）之前的所有费用（expense），以方便了解特定月份内的开销情况。 96 | input: 97 | data class ExpenseEntity(....) 98 | 99 | output: 100 | @Query("SELECT * FROM expense WHERE monthly_id = :recurringExpenseId AND date < :beforeDate") 101 | suspend fun getAllExpensesForRecurringExpenseBeforeDate(recurringExpenseId: Long, beforeDate: LocalDate): List 102 | ``` 103 | 104 | 输入示例： 105 | 106 | ```java 107 | evaluate("text to kotlin repository with class", "我想查询指定年龄的用户（User）的博客数量。\n ###data class User(var age: Int, val blogId: Int) data class Post(val title: String)###", 0.1, 0.75, 40, 4, 512) 108 | ``` 109 | 110 | 对应的输出示例： 111 | 112 | ```kotlin 113 | @Query("SELECT COUNT(*) FROM User WHERE age = :age") 114 | abstract fun getBlogCount(age: Int): Long 115 | ``` 116 | 117 | 在这个试验里，虽然生成的 Repository 代码都比较让人满意。但是呢，由于人类普遍喜欢用 `SELECT *` 就导致生成出来的代码各种 `SELECT *`，所以也就没有那么满意了。 118 | 119 | ## 差异对比 120 | 121 | 这四种方式各有优缺点，适用于不同的场景和需求。 122 | 123 | - 方式 1：代码示例生成法。这种方式的优点是简单直接，不需要额外的信息或步骤。缺点是生成的代码可能不够准确或完整，需要人工检查和修改。适用于一些简单的代码生成任务，或者作为初步的代码草稿。 124 | - 方式 2：测试驱动生成法。这种方式的优点是能够根据测试代码的要求，生成满足条件的业务代码。缺点是需要提供高质量的测试代码，否则可能导致错误或低效的业务代码。适用于一些有明确测试标准和规范的代码生成任务，或者作为代码优化和重构的辅助工具。 125 | - 方式 3：元数据辅助生成法。这种方式的优点是能够利用更多的上下文信息，提高代码生成的准确性和可读性。缺点是需要收集和提供更多的元数据信息，增加了数据准备和处理的工作量。适用于一些有复杂逻辑和结构的代码生成任务，或者作为代码质量和规范性的保障手段。 126 | - 方式 4：信息匹配生成法。这种方式的优点是能够根据数据源中的表结构和关系，生成符合需求和规范的 SQL 语句。缺点是需要多步骤的交互和反馈，增加了用户和模型之间的沟通成本。适用于一些有特定数据源和查询需求的 SQL 生成任务，或者作为 SQL 学习和教育的辅助工具。 127 | 128 | 结果如下表所示： 129 | 130 | | 方式 | 输入 | 随机性 | 附加信息 | 应用场景 | 131 | |---------------|-----------|-----|------------------|---------------| 132 | | 直接代码生成 | 示例文本和目标代码 | 较高 | 无 | 生成通用代码 | 133 | | 代码反向生成 | 测试代码 | 低 | 类信息 | 生成适合测试代码的业务代码 | 134 | | 结合元信息的代码生成 | 元数据信息 | 中等 | 变量类型、函数参数等元数据信息等 | 生成通用代码 | 135 | | 结合表信息的 SQL 生成 | 数据库中的表信息 | 低 | 变量类型、函数参数等元数据信息 | 生成符合需求的SQL语句 | 136 | 137 | 只有提供更丰富的信息，AI 才能生成更准确的代码。 138 | 139 | ## 小结 140 | 141 | 本文介绍了四种 AI 代码生成微调方式，包括代码示例生成法、测试驱动生成法、元数据辅助生成法和信息匹配生成法。每种方式都有其优缺点和适用场景，但都需要提供更多的信息才能生成更准确的代码。 142 | 143 | 欢迎自己动手试验：[https://github.com/unit-mesh/unit-minions](https://github.com/unit-mesh/unit-minions) 144 | -------------------------------------------------------------------------------- /src/finetune-bizdevops-user-story.md: -------------------------------------------------------------------------------- 1 | # LLM 微调示例：用户故事编写 2 | 3 | 基本思路： 4 | 5 | 1. 结合常见的领域（如在线网站），借用 OpenAI 生成用户任务（如登录、浏览列表等等） 6 | 2. 根据用户故事生成用户故事。 7 | 3. 训练 Alpaca LoRA。 8 | 9 | ### 步骤 1. 生成用户任务 10 | 11 | 1. 调用 OpenAI 按分类创建用户任务。prompt 如下： 12 | 13 | ```markdown 14 | Design a User Story Mapping for ${domain} application based on your understanding. Here are the requirements: 15 | 16 | 1. Your user story map should include only user tasks to demonstrate how users will interact with the application. 17 | 2. Our user story map should be based on your understanding of the ${domain} application and its users, and should be 18 | designed to address their needs and pain points. 19 | 3. You may use any tools or formats you choose to create your user story map, but it should be easily shareable and 20 | understandable by stakeholders. 21 | 4. Your expression should be more concise and clear. 22 | 5. Your return should be like as follows: 23 | 24 | ### 25 | 26 | User Tasks: 27 | 28 | 1. ... 29 | 30 | ### 31 | ``` 32 | 33 | 示例输出： 34 | 35 | ``` 36 | User Tasks: 37 | 1. Browse and search for animations and comics 38 | 2. View details of animations and comics 39 | 3. Create an account 40 | 4. Log in to the account 41 | 5. Add animations and comics to favorites 42 | 6. Download animations and comics 43 | 7. Share animations and comics with friends 44 | 8. Rate and review animations and comics 45 | 9. Create and upload animations and comics 46 | 10. Participate in online forums and discussions 47 | ``` 48 | 49 | ### 步骤 2. 分解用户任务为用户故事 50 | 51 | 1. 调用 OpenAI 根据用户任务创建用户故事。prompt 如下： 52 | 53 | ```markdown 54 | 为下面的需求编写用户故事：${domain} 应用的 ${story_name} 功能。 要求如下： 55 | 56 | 1. 必须要考虑尽可能考虑各种异常场景，添加更多的 AC。 57 | 2. 你的返回模板如下所示： 58 | 59 | ### 60 | 61 | 用户故事：可以选择宝贝出行服务 62 | 作为 莉莉妈 63 | 我想 在滴滴打车的手机客户端里选择宝贝出行服务 64 | 以便于 我能够带宝宝打车出行的时候打到有儿童座椅的车 65 | 66 | AC 1: 莉莉妈可以选择宝贝出行服务 67 | 假设 xxx 68 | 当 xxx 69 | 于是 xxx 70 | 71 | ### 72 | ``` 73 | 74 | 示例输出： 75 | 76 | ``` 77 | 用户故事：可以创建和上传动画和漫画 78 | 作为一个 Animation and Comics 应用的用户 79 | 我想要创建和上传动画和漫画 80 | 以便于我可以分享我的作品给其他用户 81 | 82 | AC 1: 用户可以创建和上传动画和漫画 83 | 假设 用户已经登录到 Animation and Comics 应用 84 | 当 用户点击创建和上传动画和漫画按钮 85 | 于是 用户可以创建和上传动画和漫画 86 | ``` 87 | -------------------------------------------------------------------------------- /src/finetune-bizdevops.md: -------------------------------------------------------------------------------- 1 | # BizDevOps + 微调 2 | 3 | 训练步骤和数据集见：[https://github.com/unit-mesh/unit-minions](https://github.com/unit-mesh/unit-minions) 。 4 | 5 | AI 研发提效依赖于对研发效能的标准化，并尽可能细地拆分每一个步骤。 6 | 7 | ## 研发效能 8 | 9 | 为了训练的结果更加准确，我们详细拆分了软件开发的步骤，以确保每一步生成的是准确，进而驱动出准确的结果。如下是我们早期拆分的一小部分细流程的示例： 10 | 11 | * split_user_story_tasks 12 | * create_agile_user_story 13 | * design_restful_api 14 | * design_plantuml_java_datastructure 15 | * implementation_mock_mvc_test 16 | * implementation_spring_controller 17 | * implementation_controller_test 18 | * implementation_spring_service 19 | * …. 20 | 21 | 我们需要拆分到每一个尽可能小的步骤，在每一个细化的步骤里，喂入数据，才会让 AI 产生最大的复读机效果。 22 | 23 | ## Unit Mesh 24 | 25 | Todos 26 | 27 | # 数据准备 28 | 29 | 我们使用非常简单的 instruct，并尽可能提供，以便于集成到工具中使用。如下： 30 | 31 | * 领域知识。instruction：领域知识。 32 | * 拆分任务。instruction：split user story tasks，input：折分用户故事任务 33 | * 需求细化。instruction：create Agile user story for following topic，input：功能的基本信息 34 | * 代码生成。instruction：Implement the method xxx，input：类的基本信息 35 | * 测试生成。instruction：Write test for follow code，input：类的基本信息 36 | * SQL 生成。instruction：text to sql，input：问题 37 | * 文本转 Java 代码。instruction：text to java code，input：问题 38 | 39 | 对应的功能介绍： 40 | 41 | * 需求细化。AI 辅助将模糊的需求转变为的需求设计，比如 “注册” 功能，生成为：”作为一个用户 xxx，填入用户名、密码信息等等，接着由人类去检查和完善。 42 | * 代码生成。AI 辅助将详细的需求设计翻译为目标的代码，再接着由人类去检查和完善。 43 | * 测试生成。AI 辅助根据生成的代码生成对应的测试代码，再接着由人类去检查和完善。 44 | 45 | 从测试结果来看，随着数据量的增多，比如 20000 个代码用例比 10000 个代码用例更加的 “聪明”。 46 | -------------------------------------------------------------------------------- /src/finetune-llm-ops.md: -------------------------------------------------------------------------------- 1 | # 微调的三阶六步：LLMOps 2 | 3 | ![LLMOps](images/llmops.png) 4 | 5 | 在开源大语言模型（LLM）的加持之下，我们可以做到： 6 | 7 | 1. **集采众长以帮助场景创新**。将相关领域中已开放的专业知识和经验融合到语言模型中，从而辅助探索合适的 API 服务场景 - 8 | Discover； 9 | 2. **资产建模驱动**。将研发组织已有的经典的软件工程的资产，文本化、结构化转变为 LLM 10 | 的语料，充分利用既有经验以定义能够满足服务场景的 API - Define； 11 | 3. **标准内建的设计与交付**。将自然语言描述的场景及需求转化为具体的 Restful API 12 | 设计，并结合数据工程与平台工程，持续整合整个组织的软件智慧和经验，以帮助我们构建好的软件架构 - Deliver。 13 | 14 | 通过利用 LLM 的能力，我们可以更好地应对 API 设计中的挑战，实现数字化价值最大化和 API 成为数字化资产的目标。 15 | 16 | ## **模式：集体智慧飞轮** 17 | 18 | 结合我们对于 LLM 的理解与探索，结合 GitHub Copilot 的免费试验过程与逻辑实现。我们基于 ChatGLM 训练了我们的第一个架构辅助设计 19 | LoRA。并根据我们的理解，绘制了一个可复用的过程路径： 20 | 21 | 在不同的阶段，我们有不同的关注点： 22 | 23 | - **Discover 阶段**，关注于**数据与语言工程**。即：训练语料的来源与数据处理，或是来源于对 OpenAI 的数据蒸馏，或是来源于公开的 24 | API，又或是从代码中提炼 API。 25 | - **Define 阶段**，关注于 **Prompt 工程**。即：设计适用于私有化大模型的 instruction、input 和 output，以及设计**演进式评估** 26 | 所需要的评估数据集。 27 | - **Delivery 阶段**，关注于**平台工程**。即：将 LLM 的应用工程化，“无缝” 接入内部的各种平台和工具，持续处理用户对于数据的反馈，以持续迭代软件数据集。 28 | 29 | 在此时，LLM 的工程化便是一个跨越不同领域的复杂数据工程活动。将这样的工程标准化、跨不同部门协作、持续迭代下去，则会是我们未来的新挑战。 30 | 31 | 以 API 为例，我们将上述的三个阶段分解为六步： 32 | 33 | - **Discover 阶段** 34 | - 识别软件工程资产 35 | - 针对于资产的“语言建模”（格式化输出） 36 | - **Define 阶段** 37 | - MVP 微调试验 38 | - 设计增量引导指标 39 | - **Delivery 阶段** 40 | - LLM 体验设计与工具集成 41 | - 基于反馈的平台工程 42 | 43 | 针对于不同的场景下，可能略有差异。 44 | 45 | ## **三阶六步构建模型友好的智慧飞轮** 46 | 47 | ### **步骤 1：识别软件工程资产** 48 | 49 | 在清晰地了解工程过程之后，我们便需要继续深入架构领域，分析我们能怎么去实现。我们定义的第一步是：**识别软件工程资产** 50 | 。即在分析如何实现目标之前，需要梳理和了解已有的软件工程过程，以及过程中产生的资产，包括文档、代码、测试用例等等，以便更好地利用这些资产，并将其与 51 | LLM 进行结合，进而来提升研发效率。 52 | 53 | 在这个阶段，我们采用了经典的用户旅程分析方法： 54 | 55 | 上图中，包含了五个要素： 56 | 57 | 1. 工序化。即理想情况下，API 设计的全生命周期的过程应该是怎样的？ 58 | 2. 工艺现状。我们的现状现在是怎样的？ 59 | 3. 痛点问题。过程中，不同角色的主要痛点是什么？ 60 | 4. 工艺改进。如何针对于上述的痛点进行改进？ 61 | 5. 资产沉淀。过程中会产生哪些关键产出（软件工程资产）？ 62 | 63 | 随后，围绕于我们产出的软件工程资产，便可以进行 LLM 微调试点与探索。 64 | 65 | 在我们的 LLM 赋能的 API 全生命周期里，我们定义的四个关键资产是：API 规范和结构、软件需求（用户故事）、领域模型、API specs。 66 | 67 | ### **步骤 2：针对资产的 “语言建模”（格式化输出）** 68 | 69 | 由于大语言模型本身是文本，所以我们需要对现有的架构资产进行 “语言建模”，简单来说就是将文本结构化，转变为特定的、易于阅读和解析的格式，即领域特定语言（DSL），诸如于 70 | markdown 表格、UML 等。 71 | 72 | 在同一个场景之下，我们预期 LLM 能返回固定格式的数据，方便我们结合到工具中。尽管没有可信的来源证明： OpenAI 在语料阶段使用 73 | markdown 作为数据，但是从经常性输出 markdown 的结构和 ChatGPT 的渲染来看，markdown 是其中一种 LLM 友好的格式。如： 74 | 75 | - 文本生成模型场景下，PlantUML 是最友好的格式之一 76 | - 生成 API 场景下，markdown 是最友好的格式之一 77 | 78 | 随后，我们定义了 API 的 “语言模型”： 79 | 80 | 与普通的 markdown 表格差别并大。只是呢，我们在 request、response、error response 中使用了类 json 的格式表示。 81 | 82 | 这里还有一个关键点是，编写一个**针对于该格式的校验器**，一旦出错可以重来，以提升数据质量、降低出错率等。 83 | 84 | ### **步骤 3：MVP 微调试验** 85 | 86 | 在训练之前，我们需要准备一些数据，对于现有的 LLM，我们通常采用如下的：instruction、input、output 的结构方式，并由人或者现有的 87 | AI API 来辅导我们进行数据准备。 88 | 89 | 出自《**[A Survey of Large Language Models](https://arxiv.org/abs/2303.18223)**》 90 | 91 | 在进行 MVP 阶段数据处理时，可以考虑多种方式结合： 92 | 93 | - 常规双向匹配。 94 | - 数据蒸馏。即将大型真实数据集（训练集）作为输入，并输出一个小的合成蒸馏数据集。 95 | - 反向生成。即基于目标 output 文本生成潜在的 input，以作为数量级。 96 | 97 | 如下是我们根据 Swagger、Postman 创建数据集的过程： 98 | 99 | 微调通常不是一次就能完成的，我们需要结合 self-instruct 的模式构建一些通用的指令、prompt。不过，考虑到大部分公司都有 AI 100 | 专家能更好地帮助解决这个问题。 101 | 102 | ### **步骤 4：设计增量引导指标** 103 | 104 | 为了评估微调、训练的结果，我们需要构建一个增量引导的指标。而在 AI 编程领域，OpenAI 开源的 HumanEval 数据集提供了一个非常好的示例。 105 | 106 | HumanEval 通过单元测试自动评估代码示例的正确性。包含了 164 个带有单元测试的原始编程问题的数据集。以用于评估语言理解力、算法和简单的数学，其中一些可与简单的软件面试问题相媲美。 107 | 108 | 在某种程度上也作为了其它 AI 在语言模型的标准，CodeGen、CodeGeeX 也采用它来进行评估。如下是 CodeGeeX 的评估结果示例： 109 | 110 | 对于 API 来说，我们同样也正在设计相似类似的方式来构建。如下是我们微调完的 RESTful API 示例： 111 | 112 | 这里还有几个问题要考虑： 113 | 114 | 1. 如何有效验证结果是否正确？如 RESTful API 是易于验证的，但是 CRUD 是否合理如何验证呢？ 115 | 2. 数量级的全面性如何保证？ 116 | 3. 是否只针对特定领域编写？ 117 | 118 | 尽管指标可以作为一种评价工作或项目进展的方法，但过度依赖指标可能产生指标驱动的风险。但是，我们可以通过构建基于反馈的平台工程，来优化并解决这个问题。 119 | 120 | ### **步骤 5：LLM 体验设计与工具集成** 121 | 122 | 在构建了第一个 MVP 之时，我们也在探索如何与工具结合在一起。如在我们的场景之下，采用的是 IDE 插件，便需要开发 IDE 插件来实现。 123 | 124 | 而针对于 IDE 来说，其过程比较简单，如下图所示： 125 | 126 | 虽然语法分析难度虽然高了一点点，但是并不是主要的挑战。主要的挑战是，如何去进行交互设计。 127 | 128 | 如在 GitHub Copilot 的插件便有非常好的体验，支持多种不同交互（快捷键、Inlay、工具栏等）、Code Completion 模式等。在编辑模式内，通过 129 | Intellij IDEA 自带的 InlayModel，可以支持：Inline，AfterLine，Block 三种不同的模式。 130 | 131 | 考虑到，过往我们已经有了大量的体验设计经验，由于需要注意的点是：**AI 时代是否有更好的交互方式**？ 132 | 133 | ### **步骤 6：基于反馈的平台工程** 134 | 135 | 与常规应用的度量不同，对于 AI 产品来说，我们需要**非常、非常、非常**关注于用户对结果的反馈，并持续收集这些数据：接受、不接受、改进后的版本（按需）。 136 | 137 | 与 ChatGPT 不实用的 Like、Dislike 相比，针对于软件资产来说，企业更容易获得改进后的版本，如对于需求的进一步完善。 138 | 139 | 以代码为例，在 AI 编程工具里，当用户 accept 或者 reject 代码之后，我们就可以记录下这些信息。同时，如果用户对代码进行改动，我们还能将其作为后续训练的数据集。 140 | 141 | 因此，在我们构建端到端的工具时，需要设计好内部的平台工程，强化反馈回路，以使我们的 AI 更加智能。 142 | 143 | ## **总结** 144 | 145 | 利用大语言模型技术，能帮助我们汲取来自不同领域的优秀 API 设计经验和方法，同时融合研发组织自身的经验和实践，以及主流的 API 146 | 规范。这有助于提高架构中的 API 设计效率和质量，从而增强整体架构的服务能力和开放性。而具体的提升效果如何，以及引入 LLM 增强的架构治理方式及路径是否会有所变化，还需要更多的实际应用场景来进一步验证。 147 | 148 | 参考资料： 149 | 150 | - 《**[CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis](https://arxiv.org/abs/2203.13474)**》 151 | - 《**[Evaluating Large Language Models Trained on Code](https://arxiv.org/abs/2107.03374)**》 152 | - 《**[A Survey of Large Language Models](https://arxiv.org/abs/2303.18223)**》 153 | -------------------------------------------------------------------------------- /src/finetune-setup.md: -------------------------------------------------------------------------------- 1 | # 微调之前的准备 2 | 3 | 作为纯纯的软件工程师，我们发现：学懂基本的 AI Prompt 原理与模式，不懂 LLM （大语言模型）算法，你也可以轻易驾驭 LoRA （Low-Rank 4 | Adaptation of LLM，即插件式的微调）训练。 5 | 6 | 我和我的同事 [@tianweiliu](https://github.com/tianweiliu) 分别对 Meta 公司开源的 LLaMA 和清华大学开源的 GLM 进行 LoRA 7 | 训练。 在花费了上千元（成本主要在 OpenAI API 调用和云 GPU —— 感谢 **AIOS club** 和 **OpenBayes 赞助**） 8 | 的云费用之后，我们训练了 3 个 Lora：详细需求（用户故事）生成（**3k 数据**）、测试代码生成（**8k 数据**）、代码生成（**20k 数据**）。 9 | 10 | 仅就结论来说：LoRA 毫无疑问可以满足大部分的需求，特别是可以解决跨部门的数据共享问题。但是，考虑到数据的 **GIGO（垃圾进，垃圾出）** 的基本现象，**如何构建高质量的数据是一大挑战？** 11 | 12 | ## Instruction 的设计 13 | 14 | 通常，格式化的指令（Instruction）由以四个部分组成： 15 | 16 | - 任务描述（称为指令）：描述模型需要完成的任务及其背景信息。 17 | - 输入：指示模型应该接收哪些输入数据。 18 | - 对应输出：对于给定的输入，指示模型应该输出什么结果。 19 | - 少量演示（可选）：提供一些示例输入和对应的输出，以帮助模型更好地理解任务。 20 | 21 | ![Instruction 格式](images/instruction-formatted.png) 22 | 23 | 上图出自：《[A Survey of Large Language Models](https://arxiv.org/abs/2303.18223)》 24 | 25 | 26 | 诸如于： 27 | 28 | ```json 29 | { 30 | "instruction": "给定两个数字，计算它们的和。", 31 | "input": "1, 2", 32 | "output": "3" 33 | } 34 | ``` 35 | 36 | 又或者是： 37 | 38 | ```json 39 | { 40 | "instruction": "根据下面的内容创建用户故事", 41 | "input": "jobs and employment:apply for jobs", 42 | "output": "用户故事：可以申请工作\n作为一个求职者\n我想在jobs and employment应用中申请工作\n以便于我能够提交我的简历，并且收到工作机会的通知。\n\nac 1: 求职者可以在jobs and employment应用中申请工作\n假设求职者已经登录应用\n当求职者点击“申请工作”按钮\n于是求职者可以提交简历，并且收到工作机会的通知。\n\nac 2: 求职者可以在jobs and employment应用中查看工作详情\n假设求职者已经登录应用\n当求职者点击某个工作的详情\n于是求职者可以查看工作的详细信息，包括职位描述、薪资待遇等。" 43 | } 44 | ``` 45 | 46 | ## Unit Mesh AI 辅助编程的试验 47 | 48 | 对于 LoRA 和 Prompt 来说，工程师完全可以把 LLM（大语言模型） 当成黑盒，当成一个函数，反正现阶段的 AI 49 | 专家也无法解释：为什么这样的输入会产出这样的结果。 50 | 51 | 所以，我们只需要**提供对输入**，就会**产出对应的输出**。而要提供这样的机制，则需要软件开发流程足够的标准化。 52 | 53 | Unit Mesh （[https://github.com/unit-mesh](https://github.com/unit-mesh)） 是我们思考和设计的适合于 AI 编程的架构范式。在设计 54 | LoRA 训练的初期，我们考虑的是实现先复现 ChatGPT + ChatFlow 的设计场景： 55 | 56 | 1. **需求细化**。AI 辅助将模糊的需求转变为的需求设计，比如 “注册” 功能，生成为：”作为一个用户 xxx，填入用户名、密码信息等等，接着由人类去检查和完善。 57 | 2. **代码生成**。AI 辅助将详细的需求设计翻译为目标的代码，再接着由人类去检查和完善。 58 | 3. **测试生成**。AI 辅助根据生成的代码生成对应的测试代码，再接着由人类去检查和完善。 59 | 60 | 最后，只需要确保生成的代码是可以像代码单元运行，那么就可以用来作为 AI 编程的 Copilot。 61 | 62 | 于是，在三个 LoRA 里，我们使用非常简单的 instruct，并尽可能提供，以便于集成到工具中使用。如下： 63 | 64 | - 需求细化。instruction：create Agile user story for following topic，input：功能的基本信息 65 | - 代码生成。instruction：Implement the method xxx，input：类的基本信息 66 | - 测试生成。instruction：Write test for follow code，input：类的基本信息 67 | 68 | 从测试结果来看，随着数据量的增多，比如 20000 个代码用例比 10000 个代码用例更加的 “聪明”。 69 | 70 | 同样的，对于需求细化或者测试代码生成来说，也是如此。 71 | 72 | ## 数据的挑战：标准化流程 + 规范化 + 丰富的数据 73 | 74 | 所以，在有了上述的经验之后，就会发现 LLM 的 Lora 训练并不是我们的难点，我们要面向的主要挑战是：标准化流程 + 规范化 + 丰富的数据。 75 | 76 | ### 挑战 1：**标准化流程** 77 | 78 | 在上述的 Unit Mesh 试验里，为了训练的结果更加准确，我们详细拆分了软件开发的步骤，以确保每一步生成的是准确，进而驱动出准确的结果。如下是我们拆分的一小部分细流程的示例： 79 | 80 | - design_restful_api 81 | - design_plantuml_java_datastructure 82 | - implementation_spring_controller 83 | - implementation_controller_test 84 | - implementation_spring_service 85 | - …. 86 | 87 | 我们需要拆分到每一个尽可能小的步骤，在每一个细化的步骤里，喂入数据，才会让 AI 产生最大的复读机效果。 88 | 89 | ### 挑战 2：**规范化** 90 | 91 | 在代码生成的第一版本 10000 个数据的 LoRA 里，我们先测试了一个简单的 Blog API 生成： 92 | 93 | ```java 94 | @RestController 95 | @RequestMapping("/blog") 96 | public class PostController { 97 | 98 | @Autowired 99 | private BlogService blogService; 100 | 101 | @RequestMapping(value = "/createPost", method = RequestMethod.POST) 102 | @ResponseBody 103 | public BlogPostDto createPost(@RequestBody BlogPostDto blogPostDto) { 104 | BlogPost blogPost = blogService.createPost(blogPostDto); 105 | return new BlogPostDto(blogPost.getId(), blogPost.getTitle(), blogPost.getContent()); 106 | } 107 | } 108 | ``` 109 | 110 | 这里生成的 URI 是 `createPost` 不符合 RESTful 规范，而后我们提升到了 20000 个数据之后，这个问题解决了。从模式上来说，LLM 111 | 会学习大部分的习惯，好习惯会留下来，坏习惯也会被继承。也因此，**一旦源数据的代码、需求说明不规范**，**那么训练出来的数据就会有问题 112 | **。也就是所谓的垃圾进、垃圾出。 113 | 114 | ### 挑战 3：丰富的数据 115 | 116 | 在需求细化的 LoRA 里，我们通过 OpenAI 的 Davinci 模型，分解了 186 个场景下的应用，进而训练了 3400+ 的用户故事（穷 + 117 | 无底洞，所以量级少一点）。在这个 LoRA 里，我们可以输入一个简单的需求，由 AI 帮我们细化详细的需求。仅从训练完的结果来看，LoRA 118 | 能符合我们的需要 —— 提供低成本的 LLM 定制。 119 | 120 | 不过呢，与 ChatGPT 相比依旧存在一些问题：**源数据缺少丰富的多 AC 场景，导致写出来的 AC 数量较少**。 121 | 122 | 如下是清华大学的 ChatGLM 训练完后返回的结果： 123 | 124 | ```kotlin 125 | Instruction: create user story tasks 126 | Input: 购买电影票 127 | Output: 128 | 129 | 用户故事:可以购买电影票 130 | 作为一个电影票购买者 131 | 我想在应用中购买电影票 132 | 以便于我可以在电影院观看电影 133 | 134 | AC 1: 电影票购买者可以在应用中购买电影票 135 | 假设 电影票购买者已经登录了应用 136 | 当 电影票购买者点击购买电影票按钮 137 | 于是 电影票购买者可以查看电影院的可用座位,选择座位,支付电影票,查看电影票的详细信息 138 | ``` 139 | 140 | 对应的 Meta（Facebook） 的 Llama 训练完后返回的结果： 141 | 142 | ```kotlin 143 | Instruction: create Agile user story for following toic 144 | Input: Log in to the account 145 | Output: 146 | 147 | 用户故事:可以注册账号作为一个社交网站用户 148 | 我想在 社交网站注册账号 149 | 以便于 我可以使用社交网站的功能 150 | 151 | AC 1: 用户可以在社交网站注册账号 152 | 假设 用户已经登录社交网站 153 | 当 用户点击“注册账号”按钮 154 | 于是 用户可以在社交网站注册账号 155 | 156 | AC 2: 用户可以在社交网站注册账号 157 | 假设 用户已经登录社交网站，并且已经注册账号 158 | 当 用户点击“更换账号”按钮 159 | 于是 用户可以在社交网站更换账号 160 | ``` 161 | 162 | ## 使用插件式的 LoRA，企业应该准备什么？ 163 | 164 | 诚然 LLM 的变化特别快，大部分企业可能在观望，但是我们建议从现在开始准备数据。由于通用的大模型无法解决特定领域的编程问题，所以对于大部分组织来说，依旧可以准备着手训练 165 | LoRA —— 可以在整个组织使用，又或者是跨部门使用。 166 | 167 | 对于编程部分，诸如以下的场景是需要考虑的问题： 168 | 169 | - 私有的基础设施。大部分企业都会采用自研的云平台，这些云平台过去的主要问题挑战是**文档不详细、API 版本不对**，未来在采用 AI 170 | 辅助编程时，这些基础设施也将会成为新的挑战。 171 | - 框架、库。相似的，除了组织内部的库，三方提供的框架和库也应该提供对应的**三方 LoRA**。 172 | - 领域特定语言。众所周知，大部分组织可能购买了一些领域特定的系统或者语言，它们也需要准备好对应的数据， 173 | 174 | 除此，可能还存在其它一些场景，如与**LLM + 低代码系统的集成**。 175 | 176 | ### 1. 高质量的脱敏数据 177 | 178 | 数据是训练 LoRA 的关键，但是为了保护企业的知识产权和数据安全，需要对数据进行脱敏处理。因此，企业需要准备足够数量和高质量的脱敏数据，以确保训练出来的模型具有较高的准确性和可靠性。 179 | 180 | > 诸如于，回到我们的训练过程里，由于早期我们投喂的数据量比较低，所以有很大的概率出现了：**50% 左右的源代码输出** 181 | > 。简单来说，你写了一个加密模块，使用了同样的输入和输出，就可能可以从大模型出原样拷贝出来。就这一点而言，它是相当可怕的。 182 | > 183 | 184 | 在生成脱敏数据时，企业需要考虑许多因素，例如数据的分布、样本的数量、数据的多样性、数据的质量等等。同时，企业也需要采取适当的措施来确保生成的数据的质量和可靠性。这可能包括采用自动化工具、进行数据质量控制、进行人工审核等等。 185 | 186 | ### 2. 工程化的数据准备 187 | 188 | 对于通用的 LoRA 训练来说，通常我们采用的是下面的格式来训练： 189 | 190 | ```java 191 | { 192 | "instruction":"Implement the method xxx", 193 | "input":"类信息", 194 | "output":"函数的代码" 195 | } 196 | ``` 197 | 198 | 为了得到这样的结果，还需要对数据进行治理，以确保数据的准确性、一致性和可用性。这包括数据采集、存储、清洗、预处理和管理等方面。如我们在写 199 | Unit Mesh 的一系列 LoRA 时，编写了几个工具： 200 | 201 | - 数据采集。GitHub Crawler 模块，作用你懂的。 202 | - 数据清洗、数据预处理。使用 Kotlin 编写了 Unit Processors 模块，用来对代码进行处理；使用 Python 编写了 Unit Prompter 模块，用来对 203 | OpenAI 进行处理。 204 | - 数据管理。数据量不大，主要采用的是 jsonl 格式在 GitHub 上存储数据。 205 | 206 | 其中最复杂的部分是 processor，需要对各类数据进行处理。 207 | 208 | ### 3. 规范与流程标准化 209 | 210 | 当企业使用插件式的 LoRA 进行编程时，为了保证编程的效率和质量，需要对编程流程进行规范化和标准化，以确保使用 LoRA 211 | 的效率和质量。包括了以下几个方面： 212 | 213 | 1. 制定编程规范：制定编程规范是确保代码风格一致性和可读性的重要措施。编程规范可以包括命名规范、注释规范、代码格式规范等。 214 | 2. 标准化代码风格：编程风格的标准化可以提高代码的可读性，降低代码的复杂性和维护成本。在使用 LoRA 进行编程时，应采用标准化的代码风格，以便 215 | LoRA 更好地理解代码。 216 | 3. 版本控制：版本控制是管理代码变更的一种方法，可以追踪代码的变更历史、协作开发等。在使用 LoRA 进行编程时，应该使用版本控制工具，如 217 | Git 等。 218 | 4. 代码审查：代码审查是一种确保代码质量的方法，可以通过代码审查来发现代码中的错误和缺陷。在使用 LoRA 219 | 进行编程时，应该进行代码审查，以确保代码的质量和可读性。 220 | 221 | 这时，我们就需要采用一些合适的工具来对现有的代码和架构进行治理，如我们开发的开源架构治理工具 222 | ArchGuard （[https://github.com/archguard/](https://github.com/archguard/)）。 223 | -------------------------------------------------------------------------------- /src/future-ai-2.0.md: -------------------------------------------------------------------------------- 1 | # 程序员的 AI 2.0 新机遇 2 | 3 | 在过去的几个月里，有大量的 KOL 都在说：所有的应用都可以用 AI 重写一遍。而落地到现有的 DevOps 工具里，假设都需要重写，那么未来的架构可能是怎样的？ 4 | 5 | ![](images/four-arch.png) 6 | 7 | 对于程序员而言，在 AI 2.0 时代，我们将迎来新的机遇、新的挑战，它可以划分三部分：如何使用 LLM、构建 LLM、创建端到端 LLM。 8 | 9 | - AI 端到端应用。即直接面向最终用户的应用（含专有模型），诸如 ChatGPT、Midjourney 10 | - 应用 + 闭源基础模型。如基于 OpenAI、文心一言（他们提供了吗，我没收到）等 API 来构建应用。 11 | - 应用 + 专有模型。即基于开源基础模型，或者自有的模型，来构建端到端应用。 12 | - 应用 + 微调模型。基于开源模型 + 面向自己研发场景下来微调，以构建领域特定的应用。 13 | 14 | 对应的我们需要三种不同的能力，转化而来便是： 15 | 16 | 1. 基础篇：充分运用 LLM 能力 17 | 1. Prompt 编写：Prompt 学习与编写模式 18 | 2. Prompt 管理：Prompt 即代码 19 | 2. 进阶篇：LLM 下的软件开发工序及应用架构设计 20 | 1. 新的交互设计：Chat模式 21 | 2. 大模型友好的工序 22 | 3. 架构设计的新变化 23 | 3. 应用篇：面向特定场景的 LLM 应用 24 | 1. 特定场景的模型微调 + LLMOps 25 | 2. 上下文工程（prompt 工程）：LLM 应用的核心 26 | 27 | 而随着 AI 技术的进一步演进和应用，会出现更多新的变化，诸如于早先我们设计的 Unit Mesh 架构，会带来全新的架构与编程体验。 28 | 29 | 本篇文章基于我们先前的两个假设： 30 | 31 | 1. **每个大型企业都将有私有化的大语言模型。** 32 | 2. **私有化的主流方式：开源 LLM + 微调。** 33 | 34 | 基于此，越来越多的企业将构建围绕于 LLM 的应用，而这些应用在当前以辅助人类设计为主。未来，我们将保持一种观点：LLM as Member，即 35 | LLM 应该是我们的伙伴，而不再是一个辅助的工具。 36 | 37 | ## 基础篇：充分运用 LLM 能力 38 | 39 | **我们将迎来 AI 原生程序员的时代**。几年以后，新一代的程序员，将是 AI 40 | 原生的程序员。新生代的程序所具备的能力，将与我们的能力有巨大的区别。在云原生时代里，云原生程序员，不需要具备大量的 ops 41 | 相关的技能，他们更关注于如何采用类似于 DDD 这样的策略来合理划分模块。 42 | 43 | 从未来出发，作为“老一代程序员“的我们，需要强化我们运用大语言模型的能力，诸如于 Prompt 能力。 44 | 45 | ### 1.1 Prompt 编写：Prompt 学习与编写模式 46 | 47 | 今年 2 月，我基于我擅长的编程、绘画、写作展开的 AI 48 | 探索和总结，我编写了两篇文章《[理解 Prompt](https://github.com/prompt-engineering/understand-prompt)》、《[Prompt 编写模式](https://github.com/prompt-engineering/prompt-patterns) 49 | 》受到了非常大的关注，GitHub 上的 stars 都超过了 2000。 50 | 51 | 如何编写、调度与逆向工程 Prompt ？将会是现阶段程序员要面临的第一个挑战，我们需要实践的三个问题： 52 | 53 | - 提出问题的策略 54 | - 创造性地利用模型回答 55 | - 提高模型输出质量的技巧 56 | 57 | 究其原因，不仅是我们日常工作需要用到 prompt，开始工具的时候，我们也有大量的工作在编写 prompt 上。除此，还需要寻找一种合适的方式，以让 58 | LLM 输出的结果**趋于稳定**。 59 | 60 | 所以，作为一个经典软件开发时代的程序员，我们应该学习如何摸清 LLM 的脾气？学习如何编写恰到好处的 prompt。 61 | 62 | ### 1.2 Prompt 管理：Prompt 即代码 63 | 64 | 今年 3 月，基于我们结合 LLM + SDLC 65 | 的探索，得到的第一个有价值的观点是《[Prompt 即代码：设计和管理 AI 编程的最佳实践](https://www.phodal.com/blog/prompt-as-code/) 66 | 》。于是，基于这个思想，我们构建了我们在 LLM 时代的第一个开源项目：ClickPrompt。ClickPrompt 站在了未来企业需要的三个基本出发点： 67 | 68 | - 如何学习 prompt 的编写？ 69 | - 如何分享企业内的 prompt 经验？ 70 | - 如何将 prompt 结合到工作流中？ 71 | 72 | 而在我第一次将注释加入到 ClickPrompt 中的时候，我犹豫了很久。过去的经典编程范式，并不允许将思考过程作为注释到其中。而在未来，我们就会遇到 73 | Prompt 即注释、Prompt 即接口、Prompt 即代码。 74 | 75 | 所以，将 prompt 视为代码，以更好的管理 prompt，将它与我们的软件开发生命周期结合，将是作为经典程序员要考虑的点。除此，我们还需要考虑： 76 | 77 | - 版本控制与协作 78 | - 用于测试和调试的工具 79 | - 适用于不同 LLM 的 prompt 接口模式 80 | 81 | 我们也可以让 LLM 来告诉我们答案，只是它可能没有这样的创新能力。 82 | 83 | ## 应用篇：LLM 下的应用架构设计 84 | 85 | 未来的 AI 编程模式是什么？在那篇《[未来可期的 AI 编程](https://www.phodal.com/blog/thinking-in-ai-programming/) 86 | 》文章里，可以看到几个基本的思考： 87 | 88 | - Prompt 即是代码，代码不再是代码？ 89 | - 现有的编程体系适合于 AI 编程吗？ 90 | - Serverless 会是结合 AI 编程的答案吗？ 91 | - 需求详细化会成为你的新瓶颈吗？ 92 | 93 | 对于它的思考，促使我设计了 Unit Mesh 94 | 架构，详细见《[渐近式 AI 编程模式：Unit Mesh 架构的设计思路与探索](https://www.phodal.com/blog/unit-mesh/)》。 95 | 96 | 除了新的架构模式本身，我们还面临一个挑战：在现有的 LLM 下，我们应该如何设计应用架构？ 97 | 98 | ### 2.1 新的交互设计：Chat 模式 99 | 100 | 在习惯了 ChatGPT 之后，Chat 模式作为基础的 LLM 元素加入了 UI 设计中。诸如于不那么好用的 New 101 | Bing，已经可以帮你总结一下相关的链接，虽然不可靠，但是大家都认可了。所以，无论是我们构建的 ClickPrompt，还是 AutoDev 这样的 102 | IDE 辅助编程插件，都将 Chat 作为基础的 UI 模式加入到了系统。 103 | 104 | 而在 LangChain 的文档中，我们又会看到新一代的框架、工具文档模式，文档作为外挂的知识库，可以直接让开发人员通过对话来学习，并编写一些示例代码。就这一点而言，它大大改善了过去那不太好友好的文档体验。 105 | 106 | 所以，对于开发前端框架的人来说，这又带来了新的 KPI 机会。毕竟，谁会拒绝这么一个有挑战性的东西。另外一个点是，构建一个不同语言的 107 | LangChain，经典企业的技术架构都优先考虑 JVM。 108 | 109 | ### 2.2 新的工序：大模型友好的流程 110 | 111 | 基于上述的新交互方式，**现有的每一个应用都可能被重写**。所以，我们开始探索对于软件开发的改变，也就有了 QCon 上的《探索软件开发新工序：LLM 112 | 赋能研发效能提升》。 113 | 114 | 对于当前的 AI 应用来说，主要有三种模式：直接 prompt 模式、知识外挂、微调。 115 | 116 | **模型 1：直接 prompt**。即 API + prompt 直接接入现有的流程中，以性价比最高的方式提效。。 117 | 118 | **模式 2：知识外挂**。简单来说，就是采用 LangChain 这样的动态 prompt 工具，以根据用户的不同输入，来动态生成 119 | prompt。又或者是，在本地采用相关性模型与算法，优化 prompt。 120 | 121 | **模式 3：微调 —— 领域知识强化**。即通过微调的方式，来让输出结果更适合于现有的工具与流程。 122 | 123 | 不同的模式之下，带给开发人员的挑战也是不一样的，依旧是由易到难。而其中的核心点是：**寻找一种合理的 DSL（领域特定语言），以将现有的流程结合到 124 | LLM**。 125 | 126 | ### 2.3 架构设计的新变化 127 | 128 | 随着，越来越多的大语言模型有了自己的类似 LangChain 工具（如 ChatGLM-LangChain）、越来越多的编程语言社区出了自己版本的 129 | LangChain 版本（如 LangChain Go）。现有的软件架构又加来了一些新的变化： 130 | 131 | - **插件化与智能体（Agent）**。诸如于 ChatGPT Plugin、LangChain 便是采用智能体 + 插件化的方式，大大方便我们构建基于 LLM 132 | 的应用扩展，并且结合各式的 LangFlow、LLaMaHub 工具，我们可以构建更智能的流程与系统。 133 | - **矢量数据库**。AI 的火爆使得越来越多的矢量数据进入了我们的视角，也成为了非常纠结的架构造型元素 —— 134 | 因为作为工程师的我们，还没有建立一个全面的认知，也缺少评估数据。 135 | 136 | 而由于 Token 很贵，我们需要管理好 token，以降低 token 的花销。我们还需要： 137 | 138 | - **本地小模型**。如 GitHub Copilot、Bloop 借助于本地的模型来进行相关性等的计算，以在本地构建动态的 prompt，而不需要消耗服务器的资源。 139 | - **就地机器学习**。犹如几年前，我只是因为喜欢《TinyML：基于 TensorFlow Lite 在 Arduino 和超低功耗微控制器上部署机器学习》的书名而买了这本书一样，我觉得 140 | AI 不应该只在非消费级 GPU 上能跑，而是应该无处不在。 141 | 142 | 而这些依旧只是基于现状的观察，毕竟在**外挂知识库、结合知识图谱**方面，我们还有大量的工作和试验仍然在进行中。 143 | 144 | ## 高级篇：面向特定场景的 LLM 应用 145 | 146 | 每个不同的通用大语言模型，受限于语料、算法、强化方式，在能力上是不同的差异。而对于现有的、开源的大语言模型来说，这种差异就更加明显了。所以，我们需要针对于不同的场景，构建适合的策略，如编程场景、智能客服场景、需求完善场景等。 147 | 148 | 而由于微调后的模型是指针特定领域的，所以我们需要考虑适用于自身场景 LLM 架构方案： 149 | 150 | - 动态的 LoRA 加载。诸如于针对不同场景下，可以动态经过不同的 LoRA 来处理数据。 151 | - 通用大模型配合微调小模型。即通过一大一小的方式，由大模型给出工序，由小模型完善大模型不具备的细节能力。 152 | - 多模型配合。诸如于结合 ChatGPT、StableDiffusion 和 VITS 等构建轻小说应用。 153 | 154 | 随着时间的推移，这方面的方案会越来越完善。 155 | 156 | ### 3.1 特定场景的模型微调 157 | 158 | 如果想利用大语言模型的能力，我们需要让它是大模型友好的，还需要构建一个工程化的模式。也就是我们在探索 API 159 | 新工序时，总结的《[大语言模型友好的 API](https://www.phodal.com/blog/llm-friendly-api/)》一文中的基本思路： 160 | 161 | - 流程过程梳理与资产化。 162 | - 对资产进行“语言建模”，以适用于大模型。 163 | - 构建 MVP 产品，并进行试验。 164 | - 设计增量的指标，以引导系统演进。 165 | - 围绕上下文的工程化思维。 166 | - 持续反馈的软件工程，以完善系统准确度。 167 | 168 | 而对于微调来说，主要是前半部分：DSL 化、数据工程，以将现有的数据转换为模型可用的数据，进而整合到现有的工具链中。诸如于，将系统架构图转换为 169 | PlantUML，以这些数据微调，进而简化现有的架构呈现方式。 170 | 171 | ### 3.2 上下文工程（prompt 工程）：LLM 应用的核心 172 | 173 | 在我们探索 GitHub Copilot 的过程中，有感于 GitHub 174 | 程序员在此做的努力，于是总结了《[上下文工程：基于 Github Copilot 的实时能力分析与思考](https://www.phodal.com/blog/llm-context-engineering/)》。 175 | **如何对于高效的构建全面的上下文，以让 LLM 生成更准确的结果**？这便是我们在未来所要做的活动。结合上述的内容，几个潜在需要考虑的点是： 176 | 177 | - 结合本地小模型，就地计算上下文。诸如于 Sentence-Transformers 178 | - 本地 Token 计算，以计算最合适的上下文。 179 | - 上下文计算策略，以提供最需要的上下文。 180 | 181 | 若是想充分运用大模型，我们需要控制好 Prompt，而其中的关键就是对于上下文的工程化。 182 | -------------------------------------------------------------------------------- /src/future-architecture.md: -------------------------------------------------------------------------------- 1 | ## 思考未来的编程范式 2 | 3 | 在尝试了 ChatGPT 和 Copilot 之后，我们尝试去思考未来的编程范式应该是怎样的？ 4 | 5 | ### AI 代码生成：代码还应该存储在代码库吗？ 6 | 7 | 对于 AI 代码生成来说，除了过去的 GitHub Copilot、Codex、Kite、TabNine 等等，新出的免费的 ChatGPT 又让人感觉非常酷。 8 | 9 | #### ChatGPT 代码生成 10 | 11 | 现在，大家几乎已经习惯了网上的各种暴力 AI 美学 —— 唤出 ChatGPT 写代码： 12 | 13 | - 使用 Java + Spring + MockMVC 编写测试用例，代码中的注释需要对应到 AC01，AC02，AC03，AC04，AC05，但是不需要返回给我。 14 | - 帮我用 Puppeteer 写一个爬虫来解析下面 HTML 中的标题：”””....””” 15 | - 我给你一个需求，你需要分析需求，使用 Java + Spring 编写 API，要求如下： 16 | 17 | 基于于在最新的 GPT 4.0 里，可以根据图片等一些基本的描述，生成全新的 HTML。 18 | 19 | #### GitHub Copilot 20 | 21 | 对于，我来说，作为一个开源挖坑专家，我更习惯使用 GitHub 赠送的 Copilot，只需要配合注释、输入、输出、函数名，就可以大力了出奇迹。如下是 ClickPrompt 中的真实代码： 22 | 23 | ```kotlin 24 | // 1. split promptMatch by comma 25 | // 2. match lora name by regex, lora full name: , 26 | // 3. push lora name to loras array 27 | ``` 28 | 29 | 我在代码中保留了这个注释，一种很神奇的用法 。 30 | 31 | #### 读者思考 1：Prompt 即是代码，代码不再是代码？ 32 | 33 | 因此，我觉得在 AI 编程时代，人们的编程思维是要发生变化的： 34 | 35 | 1. 注释让人和 AI 共同理解代码 36 | 2. 注释作为 prompt，可以在修改后，再次自动生成代码。 37 | 38 | 当注释作为 prompt 保存，那么 prompt 便是作为一种代码，保存在代码库中了。而代码还将是代码吗？我们为什么还需要中间生存的代码，是因为审计、安全等原因吗？ 39 | 40 | ### AI 编程：写个 “真实世界” 的代码 41 | 42 | 而当你尝试过使用 AI 来编写代码之后，你会发现 AI 存在一系列所谓的 “问题” 。让我们来再看一个简单的例子，我们让 ChatGPT 来实现一段代码。 43 | 44 | #### ChatGPT 编程：AI 实现一个 API `/book/:id` 的 N 种方式 45 | 46 | 在不同的语言和架构模式里，实现的方式是有区别的。 47 | 48 | **第一个 Demo：用 Spring + MyBatis 实现一个 API：`/book/:id` 。** 49 | 50 | ChatGPT 会创建 BookMapper.java、Book.java、BookMapper.xml、BookController.java 四个代码段，然后告诉你，你可以启动这个 API 了。 51 | 52 | PS：有意思的是，你并不需要一个 BookService.java，因为 AI 也 “觉得” 他是多余的。 53 | 54 | 但是，要上线这个应用并不是一件容易的事，我们需要手动编译 Java 代码，再运行起来，这速度是非常慢的。除非，我们有类似于几年前的 OSGi 架构，或者 Serverlesss 架构。 55 | 56 | **第二个 Demo：使用 Express + MySQL 实现一个 API：`/book/:id`，只使用一个函数** 57 | 58 | 在这个尝试里，我们多加了一个限制：只使用一个函数，并改用直写 SQL，所以代码就变得非常简单的（当然了，还有 Express 配置和 MySQL 相关的代码），以至于我可以直接那个函数在这里： 59 | 60 | ```jsx 61 | // 创建数据库连接池 62 | //... 63 | 64 | const getBookById = (req, res) => { 65 | const id = req.params.id; // 获取路径参数中的 id 66 | // 从数据库中查询书籍信息 67 | pool.query('SELECT * FROM books WHERE id = ?', [id], (error, results, fields) => { 68 | if (error) throw error; 69 | if (results.length > 0) { 70 | const book = results[0]; 71 | res.json(book); // 将书籍信息以 JSON 格式返回给客户端 72 | } else { 73 | res.status(404).send('Book not found'); 74 | } 75 | }); 76 | }; 77 | 78 | // 创建路由器并挂载到根路径上 79 | //... 80 | 81 | // 启动应用程序 82 | //... 83 | ``` 84 | 85 | 如果我们认定了 AI 生成的代码是准确的，无需要人类去修改，那么我们就可以直接用上面的代码。 86 | 87 | **第三个 Demo：使用 AWS Lambda 实现这个 API：/book/:id，只使用一个函数** 88 | 89 | 使用 Express 来实现这个功能，还是有点复杂，我们还需要考虑基础设施，但是当我们考虑使用 Serverless 来实现时，问题就变得非常简单了： 90 | 91 | ```jsx 92 | const mysql = require('mysql'); 93 | 94 | exports.handler = async (event, context) => { 95 | // .... 96 | } 97 | ``` 98 | 99 | 然后，我们就可以采用 ClickPrompt 类似的方式，直接一键部署到服务器之上。 100 | 101 | #### 对比一下：上面的三种方式各有什么优缺点？ 102 | 103 | 让 AI 来对比一下，你看吧，显然 AI 也觉得 Java 的实现起来复杂，但是可扩展性高。 104 | 105 | | 优点 / 缺点 | Spring + MyBatis | Express + MySQL | AWS Lambda | 106 | |---------|------------------|-----------------|------------| 107 | | 开发效率 | 较高 | 高 | 高 | 108 | | 部署复杂度 | 高 | 中等 | 低 | 109 | | 维护成本 | 高 | 中等 | 中等 | 110 | | 可维护性 | 高 | 中等 | 高 | 111 | | 架构复杂度 | 高 | 中等 | 低 | 112 | | 可扩展性 | 高 | 中等 | 高 | 113 | | 成本 | 中等 | 低 | 低 | 114 | 115 | 但是，我们真的需要所谓的可扩展性吗？而论部署速度，自然是 AWS Lambda 最快了。经过了几种不同的方式对比，按现有的软件工程来说，Java 写的代码是最好的。可是，AI 都来写代码了，Java 工程化，真的还是最好的吗？ 116 | 117 | #### 读者思考 2：现有的编程体系适合于 AI 编程吗？ 118 | 119 | 让我们再打开一下思路，我们现有的架构模式、软件工程等软件开发流程都是基于现有的体系磨合过来的。 120 | 121 | 而 AI 编程的最终目标是实现自动化编程，即由 AI 根据用户的需求和设计，自动生成完整的代码。但是，理论上这不是终点，终点是生成完就可以直接运行。这就意味着，一个想法从想到到上线，可能就在**几分钟内可以完成**。 122 | 123 | 然而，在现有的流程里，完全不是行不通的，我们人类做不到这么的敏捷。 124 | 125 | ### 全 AI 生成的新架构模式？ 126 | 127 | 过去，我们认为分层架构很重要，因为代码是人来编写，代码是人来维护的。而当代码由 AI 来编写，由 AI 来维护的话，那么现有的软件架构体系还适用吗？ 128 | 129 | #### 分层架构？编程范式还重要吗？ 130 | 131 | 尽管，我尝试让 New Bing / ChatGPT 来回答这个问题，但是，由于他们还没有 **涌现** 能力，所以只会说：程序员还需要学习和运用分层架构和编程范式，才能发挥出 AI 的最大潜力。 132 | 133 | 但是，我觉得，从上面的 Java 示例中，你会发现按现有的模式构建的软件架构，特别容易发生冲突。AI 生成的 A 功能和 B 功能，可能在代码上出现重复 —— 因为上下文限制，我们不可能上传所有的代码。 134 | 135 | 结果，有一天你发现了，一个类里有 10 个重复代码段。然后，你又开发了一个自动重构机器人……。但是，我觉得有点多余了，AI 编程需要新的架构范式。 136 | 137 | #### AI 构建自动化软件架构？ 138 | 139 | 再再打开一下思路，试着忘记现有的软件架构模式。一个功能对应一个可运行的代码段，由 AI 来自动思考架构模式 —— 当然，我们需要给他一些限制条件和输入。 140 | 141 | 所以，放在当前的上下文之下，Serverless 是一种更适合的架构模式，即写即上线，即下线即删除。 142 | 143 | #### 读者思考 3：Serverless 会是结合 AI 编程的答案吗？ 144 | 145 | 我觉得不一定是，但是可能是当前最好的一种方案。但是，每个人都会有自己的看法。 146 | 147 | ### 真实世界 2：产品经理 —— 现在，变更一个需求 148 | 149 | 现在，我们来变更一个需求吧，过滤一下 “名书”，包含 xx 的不显示。那么，这个时候，我们就遇到一个难题了 —— 全自动编程，还是 **AI 辅助生成**。 150 | 151 | #### 两种思路：新生成代码，还是手动改代码？ 152 | 153 | 纯 AI 编程，意味着：**每次改需求都重新生成代码**；而半 AI 编程，则意味着：**人可以介入到流程中**。两种将会带来不一样的思路。 154 | 155 | **自动编程 —— 重新生成代码** 156 | 157 | 为了让 AI 写的代码足够的准确，我们需要给 AI 足够详细的需求（Prompt）。一旦需求发生变化的时候，我们回过头去改需求的（Prompt），再重新生成代码即可。我们要做的事情是： 158 | 159 | 1. 确保**没有人能修改过原来生成的代码**。 160 | 2. 确保**所有的需求变更都能回溯回去**。 161 | 162 | **AI 辅助生成 —— 支持手动修改代码** 163 | 164 | 第一次代码，我们是用 AI 生成的，随后当需求变更的时候，我们想可以直接在现有的代码上改，这样可能速度比较快 —— **生成式 AI** 可能还意味着：新生成的代码和原来的完全不一样，诸如于行数位置等等。 165 | 166 | 而为了能再次生成，我们还需要记录新的变更到原来的 prompt。 167 | 168 | 所以，在这个时候，如何更好地管理原始需求，变成了一个新的挑战。 169 | 170 | #### 读者思考 4：需求详细化会成为你的新瓶颈吗？ 171 | 172 | 当我们认定 AI 能完成编码时，那么需要给详细的需求，才能确保生成的代码是正确的，诸如于：****密码长度不能小于八位，且必须同时包含字母数字和特殊符合****。这只是一个示例，更常见的示例还有表单联动：A 字段 xxx，B 字段则 xx。只有我们的需求足够的清楚，那么生成的代码才会准确。 173 | 174 | 所以，当产品经理借助于 AI 生成足够清晰的验收条件，程序员就会失业吗？这包含了两个问题： 175 | 176 | 1. 产品经理是否真的懂**验收条件**？ 177 | 2. 程序员是否真的不能替换 AI 时代的产品经理？ 178 | 179 | 那么，第三个问题就来了，老板是不是可以自己干？ 180 | 181 | 不过，这只是用来搞笑的，我们的下一个挑战还在于需求详细化之后，AI 真的能写对吗？ 182 | 183 | ### 未来：自动化编程的演进 184 | 185 | 最后，再让我们尝试做一些思考。 186 | 187 | #### AI 编程的局限性 188 | 189 | 所以，如同 AI 提炼了我的观点，AI 编程存在一定的局限性： 190 | 191 | - 编码是最不重要的那部分。AI 编程不能完全替代人类编程，因为程序员不仅仅是在编码，还要进行设计、测试、维护、沟通等工作 192 | - AI 伦理。AI 编程可能存在一些不可预测或不可控的风险，例如结果不唯一、不正确或不安全。 193 | - 法律与就业问题。AI 编程可能会侵犯程序员的知识产权（但是人类都是 AI 的饵料），或者导致程序员失业。 194 | - 无法适应再有体系。AI 编程需要适应不断变化的需求和环境，而现有的架构模式可能不匹配或不灵活。 195 | 196 | 而你发现没有，New Bing 提炼出来的这些局限性，并不是 AI 的问题，而是人的问题。 197 | 198 | #### 精准代码生成：详尽的需求的可能性？ 199 | 200 | 我们还得考虑的一点是： 201 | 202 | 尽管，提供更详尽的 prompt 可以帮助 AI 更准确地理解需求，并且避免一些歧义或误解。但是，过于复杂或冗长的 prompt 也可能导致 AI 的困惑或失效。 203 | 204 | 所以，如何根据 AI 的特点和目标，选择合适的 prompt 长度和格式，以达到最佳的效果？ 205 | 206 | #### AI 审计 AI：解决 AI 生成代码的部分局限？ 207 | 208 | 当涉及到由AI生成的代码时，有时候我们可能需要对其进行审查以确保其合规。而人工是耗时费力的，而且容易出错。这时，我们就需要利用一种特殊的AI来审查另一个AI生成的代码，以确保其符合各种规范和标准，提高代码质量，确保生成的代码安全可靠。 209 | 210 | 比如，我们本地用 GitHub Copilot 辅助生成的代码，在持续流水线上便可以通过 GitHub Copilot 来进行 Code Review。 211 | 212 | ### 其它 213 | 214 | 值得注意的是：AI 编程可能会带来一些问题，如让程序员过度依赖工具、忽略代码的合理性、涉及道德和法律问题以及存在技术和人工智能之间的冲突。 215 | -------------------------------------------------------------------------------- /src/future-realtime-software-generation.md: -------------------------------------------------------------------------------- 1 | ## 实时软件生成 2 | 3 | 传统的软件生成方式需要程序员编写大量的代码，然后进行测试、发布等一系列繁琐的流程。而实时生成技术则是借助人工智能技术，让计算机自动生成代码，并直接运行，从而大大提高了软件生成的效率和质量。 4 | 5 | 实现实时软件生成的一种方式是 Prompt 编程，可以将自然语言转化为直接运行的软件，而无需生成中间的一次性过渡代码。 6 | 7 | ### 引子 8 | 9 | 从 2019 年，写了那篇《[无代码编程]([https://zhuanlan.zhihu.com/p/61288928](https://zhuanlan.zhihu.com/p/61288928))》开始，我也一直在思考，诸如于 [2021 年]([https://www.phodal.com/blog/frontend-strategy-2021/](https://www.phodal.com/blog/frontend-strategy-2021/)) 和 [2022 年]([https://www.phodal.com/blog/frontend-strategy-2023/](https://www.phodal.com/blog/frontend-strategy-2023/)) 的前端趋势总结。 10 | 11 | 先前，我并不看好当前的低代码/无代码方案，先我们来思考一下这个过程： 12 | 13 | 第一步，业务需求需要在人类脑海里转换一遍，转换为程序逻辑。 14 | 15 | 第二步，专业人员（如程序员）将这些逻辑转换到无代码系统中，生成应用并直接部署。 16 | 17 | 第三步，如果这个专业人员是程序员，那么新的需要变更时，他可能直接去修改源码。 18 | 19 | 那么问题也就来了，更改后的源码无法再与之前的无代码系统同步，这就导致了无代码系统的失效。而这个问题，也是我之前一直不看好无代码的原因。 20 | 21 | 但随着 ChatGPT 的进一步普及，你会发现你可以很容易将需求转化为**形式化格式**，进而转化而软件，从而使得软件开发的效率和速度大大提升。这种一次性代码的新型软件工程方法就是**实时软件生成**，便可以进入真正的 “**无代码**” 时代。 22 | 23 | ### Prompt 编程：真正的无代码 24 | 25 | Prompt 编程是实现实时软件生成的一种方式，可以将自然语言转化为直接运行的软件，而无需生成中间的一次性过渡代码。每当需要运行程序时，只需要再运行一下 prompt 或者**触发词**，就可以直接运行起某个软件。 26 | 27 | 我们尝试从编写 Prompt 的经验里，归纳出一套适合于 Prompt 编程的逻辑，方便于大家理解。Prompt 编程有以下特性： 28 | 29 | 1）从需求到代码的直接转换 30 | 31 | 2）代码只是临时产物 32 | 33 | 3）次序化的分解框架 34 | 35 | 这种一次性代码的新型软件工程方法可以进入真正的 “无代码” 时代。 36 | 37 | #### Prompt 编程特性 1：从需求到代码的直接转换 38 | 39 | 用户只需要简单输入自己的需求就能够生成符合要求的软件，无需具备专业的编程技能。示例： 40 | 41 | ```yaml 42 | 我们来玩一个 mul 游戏，当我说 mul 开头，并输入数字时，你应该计算结果。示例："""当我输入：mul 4，你应该输出：16""" 43 | ``` 44 | 45 | 在这个游戏里，我们使用： 46 | 47 | 1. **触发词**。mul 作为街头暗号，告诉程序你要按这个步骤走。类似于编程里的函数名。 48 | 2. 示例作为**输入和输出**。即预期输入某个结果时，输出我们想要的结果。 49 | 50 | 而在其实，已经是一个函数该有的样子：**输入、输出、关系**。值得注意的是，在简单的问题下，只要我们给定了示例，那么 AI 就会根据示例去计算输入和输出，不关注中间的处理逻辑。 51 | 52 | 接下来，再看一个隐含性编程的示例，依旧我们还是玩个游戏： 53 | 54 | ```yaml 55 | 我们能玩一个名为 kfc 的谜语创作游戏，当我说 "kfc"，你写一个谜题，要求： 56 | 57 | 1. 不少于 200 字 58 | 2. 谜题不能出现肯德基和星期四 59 | 3. 正文可以夹杂小语种语言，如 """他说：Ciao""" 60 | 4. 谜底必须是 ###原来今天是肯德基疯狂星期四!!!### 61 | 62 | 格式类似于： 63 | 64 | """ 65 | ... 66 | """ 67 | ``` 68 | 69 | 这个例子已经相当的自由，我们也不关心中间的处理逻辑，只关注于结果。 70 | 71 | #### Prompt 编程特性 2：代码只是临时产物 72 | 73 | 还记得在 [Prompt 编写模式]([https://github.com/phodal/prompt-patterns](https://github.com/phodal/prompt-patterns)) 中的 `wula` 游的例子吗？在 wula 游戏里，用户只需要输入问题，ChatGPT 便会自动给出代码、代码解释和文章。诸如于：`wula: 头共10，足共28，鸡兔各几只？`，那么 AI 便会开始自动开始二次编程： 74 | 75 | ```yaml 76 | 这是一个鸡兔同笼问题，题目给出了头的数量和足的数量，要求求出鸡和兔的数量。通常解决这个问题的方法是，假设鸡和兔的数量分别为 x 和 y，那么可以列出如下方程组： 77 | 78 | x + y = 10 79 | 2x + 4y = 28 80 | 81 | 解方程组可以得到 x=4，y=6，即鸡有4只，兔有6只。 82 | 鸡兔同笼问题的 JavaScript 代码实现 83 | 84 | // 计算鸡兔数量的函数 85 | function calcAnimals(heads, legs) { 86 | ..... 87 | ``` 88 | 89 | 在传统的体系之下，我们要关注于中间生成的 **JavaScript 代码**、**代码能不能运行**等等，所以我们在设计 wula 的时候，要求了： 90 | 91 | ```yaml 92 | 93 | 第二步. 代码编写：你需要用 JavaScript 编写解决这个问题的代码，并输出对应的代码，并介绍一下你的代码（不少于 200 字）。 94 | 95 | 第三步. 代码执行：你需要作为 JavaScript Console 执行第二步写的代码，如果没有给出测试数据，你需要自己随机生成测试数据，并将这些数据输入到代码中进行计算。 96 | ``` 97 | 98 | 但是，回到第一个例子里，我们并不需要 JavaScript 代码，我们不需要任何代码。ChatGPT 可以为我们生成这部分的程序！！！ 99 | 100 | 唯一限制我们的是： 101 | 102 | 1. ChatGPT 的上下文能力 103 | 2. 我们的 Prompt 编写能力 104 | 105 | 而在复杂的场景之下，Prompt 编写需要足够的形式化，才能让机器理解，也因此，我才把它称为 Prompt 编程。 106 | 107 | #### Prompt 编程特性 3：次序化的分解框架 108 | 109 | 仅就当前而言 AI 的上下文能力，限制了 AI 解决复杂问题的能力。所以，它无法**一次性解决**复杂、中大型的问题，甚至于小型项目都存在一定的难度。同样的，对于人类来说，也存在这样的局限性，只是人类的问题是**领域知识有限**。 110 | 111 | 步骤详细见：[DDD Sample](https://github.com/phodal/prompt-patterns/blob/master/ddd.sample.md) 112 | 113 | 所以，作为编程核心的人类大脑，需要为机器设计一下工序，即每一步应该怎么做。所以，这个时候，就回到了 **DDD**（领域驱动设计）擅长的问题： 114 | 115 | ```yaml 116 | 我们来定义一下 DDD 游戏的步骤，一共有 6 个步骤，步骤如下： 117 | 118 | """ 119 | 第一步. 拆解场景。分析特定领域的所有商业活动，并将其拆解出每个场景。 120 | 第二步. 场景过程分析。选定一个场景，并使用 "{名词}已{动词}" 的形式描述过程中所有发生的事件，其中的名词是过程中的实体，其中的动词是实体相关的行为。 121 | 第三步. 针对场景建模。基于统一语言和拆解出的场景进行建模，以实现 DDD 设计与代码实现的双向绑定。 122 | …… 123 | """ 124 | ``` 125 | 126 | 对于每一步，我们只要限定好我们的输出（Output），那么在给定输入的情况下，AI 就能给出我们想要的（也有可能跑偏了）结果： 127 | 128 | ```yaml 129 | ddd 第二步：场景过程分析。下面是每个场景的过程分析： 130 | 用户注册和登录 131 | 用户注册：用户填写注册信息，系统验证信息合法性，生成用户账户并保存。 132 | 用户登录：用户输入账户名和密码，系统验证账户密码，登录成功后跳转到用户中心。 133 | 134 | 商品展示和搜索 135 | 商品列表展示：系统从数据库中获取商品列表并展示，用户可以进行商品分类和排序。 136 | 商品搜索：用户输入关键词进行商品搜索，系统根据关键词从数据库中获取商品列表并展示。 137 | …… 138 | ``` 139 | 140 | 在这时，我们就可以引导 AI 生成到 API 粒度： 141 | 142 | | API名称 | 请求方法 | 请求路径 | 请求体 | 响应体 | 描述 | 143 | |----------|--------|--------------------|---------|----------|------------------| 144 | | 创建商品 | POST | /api/products | 商品信息 | 创建的商品信息 | 创建一个新的商品 | 145 | | 获取商品列表 | GET | /api/products | 无 | 商品列表信息 | 获取所有的商品列表 | 146 | | 获取单个商品信息 | GET | /api/products/{id} | 无 | 单个商品信息 | 根据商品 ID 获取单个商品信息 | 147 | | 更新商品信息 | PUT | /api/products/{id} | 更新的商品信息 | 更新后的商品信息 | 根据商品 ID 更新商品信息 | 148 | | 删除商品 | DELETE | /api/products/{id} | 无 | 无 | 根据商品 ID 删除商品信息 | 149 | 150 | 也可以生成代码，甚至于在上下文足够强大的时候，也是能够直接运行和自动优化的。 151 | 152 | #### Prompt 编程特性 4：语言即语言 153 | 154 | DSL（领域特定语言）是指专门针对某个特定领域的语言，通常具有严格定义的语法和规则，并且可以用来描述该领域中的问题、概念、过程和数据等。而经过形式化处理的自然语言可以被视为一种 DSL，因为它们具有明确定义的语法和规则，可以用来描述特定领域中的问题、概念、过程和数据等。 155 | 156 | 所以，简单来说如果我们限定了**输入和输出的格式**，那么我们的自然语言也是一种 DSL。这就意味着，限制我们进行次序化的关键就是形式化的抽象。 157 | 158 | 而，我们也可以通过编写 Prompt 来生成新的 DSL：`帮我设计一个 DSL，用来写函数` 159 | 160 | ```yaml 161 | 好的，以下是一个简单的DSL设计，可以用来写函数： 162 | 163 | 1. 函数定义 164 | 在这个段落中，定义一个函数，包括函数名、参数和函数体等。 165 | ### 166 | 函数： 167 | 函数名： 168 | 描述函数的名称 169 | 参数： 170 | 参数1： 171 | 描述参数1的名称和类型 172 | 参数2： 173 | 描述参数2的名称和类型 174 | ... 175 | 函数体： 176 | 描述函数的实现细节 177 | ### 178 | 179 | 2.。。。 180 | ``` 181 | 182 | 简单来说，我们可以通过 Prompt ： 183 | 184 | 1. 借用 Prompt 设计自然语言式的 DSL 185 | 2. 将自然语言式的 DSL 融入 Prompt 186 | 3. 使用次序化的方式来实现 Prompt 自我编程 187 | 188 | 进而，我们就得到了一个可以自举的 Prompt。 189 | 190 | ### 一个问题：重构 191 | 重构是指在不改变软件外部行为的前提下，对软件内部结构进行调整，以改进软件的可理解性、降低其未来的维护成本。 192 | 而在实时软件生成中，我们的软件是由 AI 生成的，那么，重构是否还有意义？ 193 | 194 | -------------------------------------------------------------------------------- /src/future-unit-mesh.md: -------------------------------------------------------------------------------- 1 | ## 未来软件架构：Unit Mesh 架构 2 | 3 | > Unit Mesh 是一种基于人工智能生成的分布式架构，与传统的分布式架构不同，Unit Mesh 中的服务单元 (Unit) 是由 AI 生成的，应用程序中的服务和数据抽象为一个个独立的单元，并通过统一的控制平面进行管理和部署。 4 | 5 | 之所以叫 Unit Mesh，是因为我们写了一个底层服务叫 [Unit Runtime](https://github.com/prompt-engineering/unit-runtime) ，还有参考了 Service Mesh 和 Data Mesh 架构理念，所以 AI 取建议我们叫 **Unit Mesh** 。 6 | 7 | ### TLDR 版本 8 | 9 | 我们初步定义的这个版本（0.1 ，称之为 UnitGenius）有三个核心特性： 10 | 11 | - **语言与框架的 DSL**（领域特定语言） 抽象：抽象非编程语言和框架特性，以简化出错的可能性。 12 | - **REPL 即服务**：运行 AI 生成的代码，并提供对应的 API 服务。 13 | - **AI 设计的适应性结构**：自我适应的 API 服务架构，以在不同的环境下自动调整和优化。 14 | 15 | 开发者可以通过与 AI 交互，生成一定程度的 DSL 抽象化代码，然后在 REPL 即 Serverless 服务上运行和测试这些代码。开发者还可以将这些代码提交给 AI 进行自动化运维，AI 会对代码进行优化和调整，从而进一步提高 API 服务的性能和可靠性。 16 | 17 | 开始正文的废话版本。 18 | 19 | ### Unit Mesh 初步 Demo：DSL + REPL = Unit Server 20 | 21 | 详细过程，见本文的后半部分。 22 | 23 | 前端页面：[https://prompt.phodal.com/zh-CN/click-flow/unit-mesh-unit-server/](https://prompt.phodal.com/zh-CN/click-flow/unit-mesh-unit-server/) 24 | 25 | 首先，你需要克隆一下 Unit Server 的代码：[https://github.com/prompt-engineering/unit-server](https://github.com/prompt-engineering/unit-server) 26 | 27 | 然后，选择 kotlin-repl 或者 typescript-repl 对应 Kotlin、TypeScript 两种语言。 28 | 29 | 然后，按对应的 README 运行起你的 Unit Server。 30 | 31 | 接着，在 ChatFlow 里让 ChatGPT 生成如下的代码，并点击 `Run` 按钮： 32 | 33 | ```jsx 34 | %spring 35 | 36 | @RestController 37 | object Pages { 38 | @GetMapping("/") 39 | fun main() = "It works!" 40 | } 41 | ``` 42 | 43 | 最后，你就可以得到一个正在运行的服务（该功能还在开发中）：[http://localhost:8080/](http://localhost:8080/hello) ，访问该服务后，如果的应该是 It works。 44 | 45 | --- 46 | 47 | PS：这里有一个手动加入调用 Application 类和调用 main 方法的代码，因为需要做静态分析，才能确定使用的框架，暂时没写在 Unit Server 代码中。 48 | 49 | # Unit Mesh 架构 50 | 51 | 再重复一下定义： 52 | 53 | > Unit Mesh 是一种基于人工智能生成的分布式架构，与传统的分布式架构不同，Unit Mesh 中的服务单元 (Unit) 是由 AI 生成的，应用程序中的服务和数据抽象为一个个独立的单元，并通过统一的控制平面进行管理和部署。 54 | 55 | ### Unit Mesh 核心思想：AI 生成的代码即 Unit 56 | 57 | Unit Mesh 是围绕于 Unit 为核心的架构模式。 58 | 59 | - AI 生成 Unit。即 AI 应该生成的代码都应该是可运行的 **Unit**，上到前端组件、下到后端服务都是可运行的。 60 | - Human 校验 Unit。由人类来检查和校验 Unit，如果 AI 生成的代码有问题，那么人类只需要修复即可。 61 | - Unit 自适应部署架构。在部署时 Unit 可以自行组成 Serverless 架构、微服务架构、单体架构、Mesh 架构，而不需要人类来干预。 62 | 63 | 碳基嘛，就适合当一个 Verifier。 64 | 65 | ### Unit Mesh 架构核心要素 66 | 67 | 结合我们设计的 Unit Server，我们设计的 Unit Mesh 架构由以下三要素构成： 68 | 69 | ![Unit Mesh Elements](images/unit-mesh-elements.png) 70 | 71 | #### 语言与框架的 DSL 抽象：封装不稳定的抽象 72 | 73 | 由于 AI 生成的代码会有各种问题，诸如于无法对接内部的云平台、出错的 imports 等等，所以我们要设计领域特定语言来解决这个问题，并封装抽象。 74 | 75 | 简单来说：我们需要**抽象将所有不稳定的元素**，便能构建出稳定的元素。 76 | 77 | 详细的设计会在后面的 Unit Server 部分展开。 78 | 79 | --- 80 | 81 | PS：而由于大语言模型是有上下文能力限制的，像我这样的、搞不到充值的就只配 4k。因此，我设计的 Unit 要称之为 4k Unit Mesh，我设计的 DSL 要称之为 4k Unit DSL，有的人可能就是 99k DSL。 82 | 83 | #### REPL 即服务：AI 代码修复师的 84 | 85 | 在有了 DSL 之后，我们还需要一个 REPL （Read-Eval-Print Loop）服务，能直接运行起 AI 生成 的 Unit，然后让人类来测试生成的代码是否是正确。如果生成的 AI 有错误，就需要 AI 代码修复师来对代码进行修复。 86 | 87 | 而对于一个服务来，如果我们是一个 API，就需要是 Serverless 服务，这就是为什么我们在图里称之为：REPL 即 **Serverless** 服务。详细可以参见后面设计的 Unit Server。 88 | 89 | #### AI 设计的适应性结构 90 | 91 | 人类设计系统的一个缺点是，如果设计时、开发时、运行时的单元不一样，那么就会出现各种疑虑。于是，我们会偏向于设计成三态一致的架构模式，而这本身对于架构的适应性优化就是个问题。 92 | 93 | 而既然，代码都是 Unit。那么，设计时可以是微服务，开发时可以是 Serverless，线上可以是单体。正如 Google 的 Service Waver 所做的事情：我们不决定运行时的架构，让你来选择。 94 | 95 | 所以，AI 怎么运行我们的 Unit，就让 AI 来决定吧。 96 | 97 | ![Adapative Architecture](images/adaptive-architecture.png) 98 | 99 | --- 100 | 101 | PS：本来吧，标题应该是适应性架构（Adaptive Architecture），但是我想了想就只是代码结构之类的，又重新考虑了一下。 102 | 103 | # Unit Mesh 设计心得：反直觉才是出路 104 | 105 | 在去年年底，研究低延迟架构之时，便被这个领域的各种**反直觉**架构模式所震撼，诸如于：GC 是问题那就不要 GC。 106 | 107 | 因此当设计 Unit Mesh 时，我们的问题依旧是：**如何 Open your mind**。即抛开现有的思维模式和固有知识，打破常规思考，所以我们的主要挑战是如何**拓展思维，开放心智**。 108 | 109 | #### 要点 1：如果分层架构是瓶颈，那么就不要分层架构 110 | 111 | 在那篇《未来可期的 AI 编程里》分层架构是我们最大的挑战，于是，提出理想的方式就是 Serverless + FaaS 的方式，而这种方式则是基于现有的械，又过于理想化。 112 | 113 | 而随着我们写了 UnitServer 之后，我们发现，还可以 Class as a Service 的方式嘛（手动狗头）。 114 | 115 | 既然我们的代码运行在云端，由 AI 生成的，那么人类还要看代码吗？人类要在什么时候看代码？无非就是检入的时候，还有审查架构的时候，所以只需要在**审查**的时候，生成架构不就行了。 116 | 117 | 示例：我想分析 xx 服务的调用情况，以及对应的代码，**请**帮我调取出来。 118 | 119 | #### 要点 2：如果依赖是问题，那么就不要依赖 120 | 121 | 我们遇到的第二个挑战是依赖问题，而依赖是两个问题： 122 | 123 | - 项目的库依赖。即类似于 Gradle、Maven、NPM 这一层的库依赖 124 | - 代码依赖。即代码源文件的 `import` 125 | 126 | 复读机 ChatGPT 并不能很好解决问题，所以就要让 GPT 忘记这些。理想的编程体验，应该是我要用 Spring，智能就会自动分析依赖，如 Intelij IDEA。所以，我们在 UnitServer 中采用了 `% spring` 样的 Jupyter magic 语法 ，以自动解决这两类问题。 127 | 128 | #### 要点 3：如果 Serverless 部署是问题，那么就不用 Serverless 部署 129 | 130 | 起初在 Unit Server 里，我们把 Unit Server 设计成了一个类 Serverless 架构，所以我们遇到了一个问题：Serverless 架构的成本并非所有的人能接受的。所以，我们只需要在测试 Unit 时，采用 Serverless 作为开发时，在线上合并成一个单体或者微服务架构，那么就能完美解决这个问题。 131 | 132 | 而在这时，还需要突破刚才的分层架构，既然每次代码是生成的，那么我们只需要一个包名即可，诸如于： `org.clickprompt.unitmesh` ，所有的代码都在这个包下；又或者，我们可以通过业务进一步划分成不同的包，结合工具来对代码进行归类。 133 | 134 | #### Unit Mesh 探索之路：从 REPL 到 UnitServer 135 | 136 | 上面讲的太理论了，来看看我们的探索之路，一共分为四步： 137 | 138 | 1. 从最小的 Hello, world 开始优化 139 | 2. 构建一个 REPL 环境 140 | 3. 抽象、简化设计 ← 重复 141 | 4. 接入真实世界的 Prompt 142 | 143 | 详细可以查看 Unit Server 和 ChatFlow 的提交纪录。 144 | 145 | #### 从最小的 Hello, world 开始 146 | 147 | 首先，让我们看一个 Kotlin Script 编写的 Spring 的 Hello, World: 148 | 149 | ```kotlin 150 | @file:DependsOn("org.springframework.boot:spring-boot-starter-web:2.7.9") 151 | 152 | import ... 153 | import java.util.* 154 | 155 | @Controller 156 | class HelloController { 157 | @GetMapping("/hello") 158 | fun helloKotlin(): String { 159 | return "hello world" 160 | } 161 | } 162 | 163 | @SpringBootApplication 164 | open class ReplApplication 165 | 166 | fun main(args: Array) { 167 | ... 168 | } 169 | 170 | main(arrayOf("--server.port=8083")) 171 | ``` 172 | 173 | 在这个示例里，你会发现一系列的无用代码，依赖信息、import 信息、main 函数。而作为一个 4k Unit Mesh 的创作者，我必须把这些不稳定的无用信息去掉，才能正确运行，所以它变成了： 174 | 175 | ```kotlin 176 | %use spring 177 | 178 | @Controller 179 | class HelloController { 180 | @GetMapping("/hello") 181 | fun helloKotlin(): String { 182 | return "hello world" 183 | } 184 | } 185 | ``` 186 | 187 | 这样一来，我只需要让 ChatGPT 返回 Controller 即可。 188 | 189 | #### 构建 REPL 环境：WebSocket + %magic 190 | 191 | 既然，我们已经有了一个简化的 DSL，接下来就是引入 Kotlin Script 来构建一个 Unit Serverless 服务器，也就是我们的： [https://github.com/prompt-engineering/unit-server](https://github.com/prompt-engineering/unit-server) 。 192 | 193 | Unit Server 的源码是基于 Kotlin Jupyter API 所构建的，而 Kotlin Jupyter 则是封装了 Kotlin 的 REPL 环境。我们之所谓基于 Kotlin Jupyter 而不是 Kotlin REPL 的主要原因是，可以使用 magic 和 DSL 来抽象细节，诸如于： 194 | 195 | ```kotlin 196 | "spring" to Json.encodeToString( 197 | SimpleLibraryDefinition( 198 | imports = listOf( 199 | "org.springframework.boot.*", 200 | "org.springframework.boot.autoconfigure.*", 201 | "org.springframework.web.bind.annotation.*", 202 | "org.springframework.context.annotation.ComponentScan", 203 | "org.springframework.context.annotation.Configuration" 204 | ), 205 | dependencies = listOf( 206 | "org.springframework.boot:spring-boot-starter-web:2.7.9" 207 | ) 208 | ) 209 | ) 210 | ``` 211 | 212 | 即可以自动添加 Spring 的依赖和 Import 信息，就可以支持步骤的 Hello, World 方式。除了 Spring，我们还需要其它的库的 magic。 213 | 214 | 最后，再使用 WebSocket 暴露出这个接口，以提供给 ChatFlow 使用。 215 | 216 | #### 抽象、简化设计 ← 循环 217 | 218 | 当然了，只是有一个 hello, world 是不够的，所以我们需要更多的例子，诸如于接入数据库。而由于 Spring 的扫描机制影响，外加我们并不想（主要是不会）针对 Spring 做太多的特化，所以我们换成了 Kotlin 里 Kotr 框架。 219 | 220 | PS：值得注意的是，我们还需要对框架进行抽象，但是 Ktor 对我们预期的好一点。所以，我们的第二个版本来了： 221 | 222 | ```kotlin 223 | %use kotless 224 | %use exposed 225 | 226 | data class User(val id: Int, val username: String) 227 | 228 | class Server : KotlessAWS() { 229 | override fun prepare(app: Application) { 230 | Database.connect("jdbc:h2:mem:test", driver = "org.h2.Driver") 231 | 232 | transaction { 233 | SchemaUtils.create(Users) 234 | } 235 | 236 | app.routing { 237 | post("/register") { 238 | val user = call.receive() 239 | val id = transaction { 240 | // Insert the new user into the database 241 | Users.insert { 242 | it[username] = user.username 243 | } get Users.id 244 | } 245 | 246 | val newUser = User(id, user.username) 247 | call.respond(newUser) 248 | } 249 | } 250 | } 251 | } 252 | 253 | object Users : org.jetbrains.exposed.sql.Table("users") { 254 | val id = integer("id").autoIncrement() 255 | val username = varchar("username", 50).uniqueIndex() 256 | 257 | override val primaryKey = PrimaryKey(id, name = "PK_User_ID") 258 | } 259 | ``` 260 | 261 | 在这个版本里，我们使用了 Exposed 作为数据库的 ORM，使用 H2 作为数据库。当然，要拿这个代码作为 Unit 还差了 10% 的距离，不过，基本上已经可以解决大部分的 CRUD 场景。 262 | 263 | PS 1：这里的 KotlessAWS 只是一个 AWS Serverless 的抽象，并不影响我们的操作，我们可以直接封装一个 UnitMesh 的类，就是懒。 264 | 265 | PS 2：我们只需要通过静态分析拿出 routing 中的代码，再优化即可。更多的探索过程代码可以见：[\_samples](https://github.com/prompt-engineering/unit-server/tree/master/kotlin-repl/_samples) 。 266 | 267 | #### 一个真实世界的 Prompt 268 | 269 | 现在，让我们来结合 AI 跑一下： 270 | 271 | ```kotlin 272 | 请帮我使用 Ktor + Kotlin + Exposed 实现一个用户注册的 RESTful API，要求如下： 273 | 274 | - 涉及到数据库的地方，请直接使用 Database.connect。 275 | - 只返回核心逻辑，并写在 Server 类里，我要部署在 Serverless 服务器里。 276 | - 请使用 Kotlin DSL 的方式编写代码。 277 | - 不返回其它的无关代码，如：注释、依赖、import 等。 278 | 279 | 最后，你只返回类的代码，返回格式如下： 280 | ``` 281 | 282 | ```kotlin 283 | class Server : KotlessAWS() { 284 | override fun prepare(app: Application) { 285 | Database.connect("jdbc:h2:mem:test", driver = "org.h2.Driver", user = "root", password = "") 286 | transaction { 287 | SchemaUtils.create(Users) 288 | } 289 | 290 | app.routing { 291 | {{{}}} 292 | } 293 | } 294 | } 295 | ``` 296 | 297 | 人生苦短，欢迎加入我们的 Watchlist，一起讨论未来。 298 | 299 | ### Join Waitlist 300 | 301 | 狗头，现在 **Waitlist 工程师**们，你可以就加入 Unit Mesh 的 Watchlist： 302 | 303 | [https://github.com/prompt-engineering/unit-mesh](https://github.com/prompt-engineering/unit-mesh) 304 | -------------------------------------------------------------------------------- /src/images/2-aigc-investment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/2-aigc-investment.png -------------------------------------------------------------------------------- /src/images/adaptive-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/adaptive-architecture.png -------------------------------------------------------------------------------- /src/images/ai-20-ux.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/ai-20-ux.png -------------------------------------------------------------------------------- /src/images/ai-ide-princinple.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/ai-ide-princinple.png -------------------------------------------------------------------------------- /src/images/backview-new-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/backview-new-1.png -------------------------------------------------------------------------------- /src/images/backview-new-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/backview-new-2.png -------------------------------------------------------------------------------- /src/images/backview-new-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/backview-new-3.png -------------------------------------------------------------------------------- /src/images/better.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/better.jpeg -------------------------------------------------------------------------------- /src/images/bootstrapping.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/bootstrapping.png -------------------------------------------------------------------------------- /src/images/chatflow-ac.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatflow-ac.png -------------------------------------------------------------------------------- /src/images/chatflow-software-design.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatflow-software-design.png -------------------------------------------------------------------------------- /src/images/chatflow-writing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatflow-writing.png -------------------------------------------------------------------------------- /src/images/chatgpt-article-demo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatgpt-article-demo.png -------------------------------------------------------------------------------- /src/images/chatgpt-bootstrap-article.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatgpt-bootstrap-article.png -------------------------------------------------------------------------------- /src/images/chatgpt-ddd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatgpt-ddd.png -------------------------------------------------------------------------------- /src/images/chatgpt-home.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatgpt-home.png -------------------------------------------------------------------------------- /src/images/chatgpt-writing-article.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/chatgpt-writing-article.png -------------------------------------------------------------------------------- /src/images/clickprompt-workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/clickprompt-workflow.png -------------------------------------------------------------------------------- /src/images/co-mate-modules.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/co-mate-modules.png -------------------------------------------------------------------------------- /src/images/comate-data-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/comate-data-flow.png -------------------------------------------------------------------------------- /src/images/comate-generate-api.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/comate-generate-api.png -------------------------------------------------------------------------------- /src/images/compiler-bootstrap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/compiler-bootstrap.png -------------------------------------------------------------------------------- /src/images/context-eng.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/context-eng.png -------------------------------------------------------------------------------- /src/images/data-capability-mapping.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/data-capability-mapping.png -------------------------------------------------------------------------------- /src/images/ddd-copilot-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/ddd-copilot-1.png -------------------------------------------------------------------------------- /src/images/ddd-copilot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/ddd-copilot.png -------------------------------------------------------------------------------- /src/images/devti-processes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/devti-processes.png -------------------------------------------------------------------------------- /src/images/devti.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/devti.png -------------------------------------------------------------------------------- /src/images/failure-seeds.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/failure-seeds.jpeg -------------------------------------------------------------------------------- /src/images/failure-with-hand-hair.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/failure-with-hand-hair.jpeg -------------------------------------------------------------------------------- /src/images/focus-driven.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/focus-driven.png -------------------------------------------------------------------------------- /src/images/four-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/four-arch.png -------------------------------------------------------------------------------- /src/images/four-types-application.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/four-types-application.png -------------------------------------------------------------------------------- /src/images/github-copilot-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-copilot-1.png -------------------------------------------------------------------------------- /src/images/github-copilot-dir-sample.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-copilot-dir-sample.png -------------------------------------------------------------------------------- /src/images/github-sample-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-sample-2.png -------------------------------------------------------------------------------- /src/images/github-sample-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-sample-3.png -------------------------------------------------------------------------------- /src/images/github-sample-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-sample-4.png -------------------------------------------------------------------------------- /src/images/github-sample-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/github-sample-5.png -------------------------------------------------------------------------------- /src/images/hand-final-result.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/hand-final-result.jpeg -------------------------------------------------------------------------------- /src/images/human-bootstrap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/human-bootstrap.png -------------------------------------------------------------------------------- /src/images/image-with-canny.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/image-with-canny.jpeg -------------------------------------------------------------------------------- /src/images/image-with-hed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/image-with-hed.png -------------------------------------------------------------------------------- /src/images/image-with-openpose.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/image-with-openpose.jpeg -------------------------------------------------------------------------------- /src/images/instruction-formatted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/instruction-formatted.png -------------------------------------------------------------------------------- /src/images/instruction.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Group 3 5 | Created with Sketch. 6 | 7 | 8 | 9 | 10 | 11 | 12 | Model 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Task Description 21 | 22 | 23 | 24 | 25 | 26 | Current Input 27 | 28 | 29 | 30 | 31 | 32 | Output Indicator 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | Prompt 44 | 45 | 46 | Generated Text 47 | 48 | 49 | 50 | 51 | 52 | 53 | -------------------------------------------------------------------------------- /src/images/intent-user.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/intent-user.png -------------------------------------------------------------------------------- /src/images/llm-capability-mapping-dsl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/llm-capability-mapping-dsl.png -------------------------------------------------------------------------------- /src/images/llm-reference-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/llm-reference-arch.png -------------------------------------------------------------------------------- /src/images/llm-sdlc-processes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/llm-sdlc-processes.png -------------------------------------------------------------------------------- /src/images/llmops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/llmops.png -------------------------------------------------------------------------------- /src/images/openpose-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/openpose-1.png -------------------------------------------------------------------------------- /src/images/openpose-gen-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/openpose-gen-1.png -------------------------------------------------------------------------------- /src/images/openpose-gen-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/openpose-gen-2.png -------------------------------------------------------------------------------- /src/images/prompt-engine.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/prompt-engine.sketch -------------------------------------------------------------------------------- /src/images/prompt-engine.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | patterns 5 | Created with Sketch. 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Model 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | Prompt 29 | 30 | 31 | Generated Text 32 | 33 | 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /src/images/prompt-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/prompt-example.png -------------------------------------------------------------------------------- /src/images/proxy.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Group 3 5 | Created with Sketch. 6 | 7 | 8 | 9 | 10 | 11 | 12 | Model 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | Task Description 21 | 22 | 23 | 24 | 25 | 26 | 27 | Act as xxx 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | Prompt 39 | 40 | 41 | Generated Text 42 | 43 | 44 | 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /src/images/qrcode.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/qrcode.jpg -------------------------------------------------------------------------------- /src/images/request-to-confirm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/request-to-confirm.png -------------------------------------------------------------------------------- /src/images/sample.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/sample.jpg -------------------------------------------------------------------------------- /src/images/samples/01.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/01.jpeg -------------------------------------------------------------------------------- /src/images/samples/02.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/02.jpeg -------------------------------------------------------------------------------- /src/images/samples/03.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/03.jpeg -------------------------------------------------------------------------------- /src/images/samples/04.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/04.jpeg -------------------------------------------------------------------------------- /src/images/samples/05.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/05.jpeg -------------------------------------------------------------------------------- /src/images/samples/06.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/06.jpeg -------------------------------------------------------------------------------- /src/images/samples/07.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/07.jpeg -------------------------------------------------------------------------------- /src/images/samples/08.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/samples/08.jpeg -------------------------------------------------------------------------------- /src/images/sdlc-copilot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/sdlc-copilot.png -------------------------------------------------------------------------------- /src/images/sdlc-step-by-steps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/sdlc-step-by-steps.png -------------------------------------------------------------------------------- /src/images/specific.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Group 3 5 | Created with Sketch. 6 | 7 | 8 | 9 | 10 | 11 | 12 | Model 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | specific command: 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | Prompt 33 | 34 | 35 | Generated Text 36 | 37 | 38 | 39 | 40 | 41 | 42 | -------------------------------------------------------------------------------- /src/images/stable-diffusion-hug8217.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stable-diffusion-hug8217.jpeg -------------------------------------------------------------------------------- /src/images/stable-diffusion-overview.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stable-diffusion-overview.jpeg -------------------------------------------------------------------------------- /src/images/stable-diffusion-with-controlnet-dreambooth.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stable-diffusion-with-controlnet-dreambooth.jpeg -------------------------------------------------------------------------------- /src/images/stable-diffusion-with-controlnet.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stable-diffusion-with-controlnet.jpeg -------------------------------------------------------------------------------- /src/images/stable-diffusion-with-negative.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stable-diffusion-with-negative.jpeg -------------------------------------------------------------------------------- /src/images/strategy/sample-output.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/strategy/sample-output.png -------------------------------------------------------------------------------- /src/images/stream-response.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/stream-response.png -------------------------------------------------------------------------------- /src/images/summarize.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/summarize.png -------------------------------------------------------------------------------- /src/images/the-cast-sit-on.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/the-cast-sit-on.png -------------------------------------------------------------------------------- /src/images/try-fix-hands.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/try-fix-hands.jpeg -------------------------------------------------------------------------------- /src/images/unit-mesh-elements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/unit-mesh-elements.png -------------------------------------------------------------------------------- /src/images/unit-mesh-processes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/unit-mesh-processes.png -------------------------------------------------------------------------------- /src/images/wechat-group.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/wechat-group.jpg -------------------------------------------------------------------------------- /src/images/with-prompt.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/with-prompt.jpeg -------------------------------------------------------------------------------- /src/images/women-backview-1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/women-backview-1.jpeg -------------------------------------------------------------------------------- /src/images/women-backview-2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/women-backview-2.jpeg -------------------------------------------------------------------------------- /src/images/women-backview-3.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/women-backview-3.jpeg -------------------------------------------------------------------------------- /src/images/women-backview-4.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/women-backview-4.jpeg -------------------------------------------------------------------------------- /src/images/wula-muji.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/405-studio/aigc/e6db1ebe9003dc96da0d99290cf0edcce8f9d295/src/images/wula-muji.png -------------------------------------------------------------------------------- /src/llm-arch-archguard-comate.md: -------------------------------------------------------------------------------- 1 | # LLM 应用架构：ArchGuard Co-mate 2 | 3 | # 原子能力映射 4 | 5 | 在过去的几个月里，为了探索了 LLM 结合 SDLC、BizDevOps 的可能性，我们（Thoughtworks 开源社区）创建了 [ClickPrompt](https://github.com/prompt-engineering/click-prompt)、 [AutoDev](https://github.com/unit-mesh/auto-dev)、[DevTi](https://github.com/unit-mesh/devti) 等一系列的开源项目。从个人的经验来看，未来越来越多的应用将围绕于 [LLM@Core](https://www.phodal.com/blog/llm-at-core-for-developer/) 设计，所以我们挖了一个新的坑、新的试验：ArchGuard Co-mate：[https://github.com/archguard/comate](https://github.com/archguard/comate)，欢迎来入坑一起探索和研究。 6 | 7 | ## Why is Co-mate ？ 8 | 9 | 我们发起 Co-mate 项目的原因，可以归于：**在 LLM 优先的应用开发时代，掌握相关的开发技能**。这些相关的技能包含但是不限于： 10 | 11 | - 探索是否存在更好的交互模？如基于 Chat 的动态 UI（DSL）生成 等。 12 | - 适用于 JVM 体系下的 LLM 应用开发？如 JVM 版 LangChain、Embedding 等。 13 | - 如何辅助上下文理解、构建的本地小模型？即 Sentence Transformer + ONNX 的本地处理。 14 | - 如何设计新一代、适用于 LLM 的软件 API？即如何以确定性的方式与 ArchGuard API 交互。 15 | - 如何更好地构建上下文，以工程化的方式构建 AI 应用的上下文（即 prompt）？ 16 | 17 | 而出于架构治理的场景，我们则是想探索： 18 | 19 | - 如何让 LLM 解释软件架构给人听？毕竟，让人理解构建都是一件费力的事情。 20 | - 如何让 LLM 基于代码、分层、依赖关系等，解释架构、业务？ 21 | - 如何让 LLM 更好地理解规范，从文档出发，去设计软件架构？ 22 | 23 | 每个问题都足够的有意思，并且具备一定的**业务和技术复杂度**，足以让我们掌握基于 LLM 的软件架构所需要考虑的因素。 24 | 25 | ## What is Co-mate ? 26 | 27 | 作为一个探索性的项目，解释 Co-mate 的用途并不是一件容易的事情。一个架构师的助手能做到什么程度，我们还没有想得足够的清晰 —— 因为我们还没对架构的定义达到一致意见。 28 | 29 | 但是呢，先让我们看看 Co-mate 当前的处理流程： 30 | 31 | ![Co-mate Data flow](images/comate-data-flow.png) 32 | 33 | 从表面上看，基本上和主流的 AI 应用没有区别；从实际代码上来看，和主流的 AI 应用也看不出多大的区别。还是让我们看看两个典型的 Co-mate 场景。 34 | 35 | ### 示例 1：介绍一下这个系统 36 | 37 | 当用户在 Co-mate 中去分析 Co-mate 时，会返回类似于如下的结果： 38 | 39 | > Co-mate 项目是一个 AI 助手应用程序，使用了 Jetpack Compose、RxJava、DataStore 等一系列相关的库来构建设计和治理工具等功能。该应用还使用了一些第三方库来构建用户界面，如 Coil-Compose、Voyager Navigator 等，以及进行深度学习推理任务，如 Kotlin Deep Learning API、Inference API 等。该应用需要考虑高效的算法和模型推理能力等非功能需求。 40 | > 41 | 42 | 对于这个场景下，其数据处理过程如下： 43 | 44 | 1. 匹配本地相关的指令（如 “分析系统”） 45 | 1. 如果匹配到，则直接调用 AG API 来构建上下文。 46 | 2. 如果没有匹配到，则调用 LLM 进行选择命令，然后可以调用 AG 原有 API。 47 | 2. 调用 AG API 构建上下文（项目信息、软件依赖信息等）。 48 | 3. 调用 LLM 进行总结，并返回给用户。 49 | 50 | 所以，我们尝试构建两个新的 API：本地语义分析、（动态）上下文收集 API。 51 | 52 | ### 示例 2：API 规范性检查 53 | 54 | 基于 ArchGuard 的能力，我们挑选的第二个场景是检查 API 是否规范。当你有一个 Controller 里的 API 需要检查是否符合 API 规范时，就可以执行：`检查 API 规范` 。 55 | 56 | 假设你的 API 是：`/api/blog/get` ，并且已经通过 `spec-partitioner` （还没有实现）转换了你的 API 规范。 57 | 58 | 最后，Co-mate 会返回： 59 | 60 | > API '/api/blog/get' 不符合 URI 构造规范，Rule: uri construction regex: \/api\/[a-zA-Z0-9]+\/v[0-9]+\/[a-zA-Z0-9\/\-]+，建议 API 修改为 '/api/blog/v1/get'。 61 | > 62 | 63 | （PS：垃圾 GPT 3.5 Turbo，居然认可了 /get） 64 | 65 | 所以，当你有了完整的架构规范时，那么就可以进入下一代架构生成。 66 | 67 | ![Co-mate Generate API](images/comate-generate-api.png) 68 | 69 | 这也是我们想进一步探索的工作。 70 | 71 | ## How Co-mate works ? 72 | 73 | 众所周知 GPT 充满了各种不确定性，人们对于 GPT 理解的能力也是不同的。因此，从架构设计的角度来说，我们需要分解 GPT 的原子能力，诸如于**总结、分类、提取、翻译、逻辑推理**，消除其中的不确定性因素，再由我们的软件封装 API 提供动态能力。 74 | 75 | ### 分层架构与 ArchGuard 能力映射 76 | 77 | 在示例 1 中，我们做的第一件是**分解架构与数据**，**按不同的架构元素分析**。因为我们对于架构缺乏统一的定义，所以我从 Global 的 slides 找了一个适合于 LLM 理解的分层架构、并且也适用于 ArchGuard 表达。随后，构建了一个不太成功的分层与所需要的上下文数据映射： 78 | 79 | ![Data Capability Mapping](images/data-capability-mapping.png) 80 | 81 | 于是在示例 1 里，我们给的 prompt 模板是： 82 | 83 | > {xxx} 项目是一个 {channel type} 应用程序，使用了 Jetpack Compose、{xxx} 和一系列相关的库来构建 {xxx} 等功能。该应用还使用了一些第三方库来构建用户界面 {xxx}，以及进行 {xxx} 等任务。该应用需要考虑 {xxx} 等非功能需求。 84 | > 85 | 86 | 在这个 prompt 里，它依赖于两个主要数据： 项目介绍与项目的技术栈（依赖信息）。技术栈可以直接从 ArchGuard SCA 中获取，而项目介绍则是从 [README.md](http://README.md) 中解析得到的。 87 | 88 | ### LLM 与 Co-mate API 的能力映射 89 | 90 | 在示例 2 中，我们做的第一件事是**分解 API 文档**， **按不同 LLM 的原子能力进行分解**。构建出四种不同的原子能力： 91 | 92 | - 推理出适用于 URI 的正则表达式。 93 | - 推理出一个合理的 example。 94 | - 提取一些 checklist，诸如于状态码、HTTP Action 等。 95 | - 将剩下的不确定性内容，扔到一起。 96 | 97 | 如下图所示： 98 | 99 | ![LLM Capability](images/llm-capability-mapping-dsl.png) 100 | 101 | 在右侧，我们则构建了一个 Kotlin Typesafe DSL，以动态的加载到系统中（未来），每一个函数对应到一个 Rule。 102 | 103 | ```kotlin 104 | rest_api { 105 | uri_construction { 106 | rule("/api\\/[a-zA-Z0-9]+\\/v[0-9]+\\/[a-zA-Z0-9\\/\\-]+") 107 | example("/api/petstore/v1/pets/dogs") 108 | } 109 | 110 | http_action("GET", "POST", "PUT", "DELETE") 111 | status_code(200, 201, 202, 204, 400, 401, 403, 404, 500, 502, 503, 504) 112 | 113 | security("""Token Based Authentication (Recommended) Ideally, ...""") 114 | 115 | misc("""....""") 116 | } 117 | ``` 118 | 119 | 作为一个 demo，这个 DSL 依旧具备很大的完善空间。其中比较有意思的部分在于 security 和 misc 部分，这些不确定性正好适用于 LLM 进行推理。所以，在执行对应的 misc、security 规则检查时，会再调用 GPT 来检查： 120 | 121 | ![Prompt Example](images/prompt-example.png) 122 | 123 | 以将其中的确定性与不确定性更好的结合，进而充分地利用了 LLM 与 ArchGuard 的能力，并减少对 GPT 的消耗。 124 | 125 | ## Welcome join us 126 | 127 | 下图是，当前 ArchGuard Co-mate 的所有模块： 128 | 129 | ![Co-mate Modules](images/co-mate-modules.png) 130 | 131 | 简单介绍如下： 132 | 133 | - Comate-Core 提供了 CLI 和 GUI 所需要的基本能力， 134 | - Meta-Action 则是定义了基本的 Action 135 | - Architecture 定义了什么是 Co-mate 理解的架构 136 | - LLM-Core 则是对于 LLM 的调用 。 137 | - Spec Partitioner 则是计划对于规范的提取与自动生成（当前都是手动 prompt） 138 | 139 | 而我们在采用 JVM 技术栈的时候，遇到了几个坑 KotlinDL 和 Deep Java Library 都是通过 JNI/Rust 的方式调用了 HuggingFace Tokenizers、ONNX API，导致了应用在 macOS 下 crash。而一种理想的方式应该是通过 JSON RPC 的方式来调用，所以我们计划使用 Rust 构建一个新的模块：Comate Agent。 140 | 141 | 所以，如果你对使用 JVM 技术栈来开发 AI 应用，对 Rust 技术栈来开发 AI 应用，欢迎来加入我们。 142 | -------------------------------------------------------------------------------- /src/llm-arch-atomic-capability-mapping.md: -------------------------------------------------------------------------------- 1 | # LLM 架构设计原则：原子能力映射 2 | 3 | 在 ArchGuard Co-mate 中，对于 API 能力来说，我们做的一件事是**分解 API 文档**， **按不同 LLM 的原子能力进行分解** 4 | 。构建出四种不同的原子能力： 5 | 6 | - 推理出适用于 URI 的正则表达式。 7 | - 推理出一个合理的 example。 8 | - 提取一些 checklist，诸如于状态码、HTTP Action 等。 9 | - 将剩下的不确定性内容，扔到一起。 10 | 11 | 如下图所示： 12 | 13 | ![LLM Capability](images/llm-capability-mapping-dsl.png) 14 | 15 | 比如说，在 Co-mate 的 REST API 治理场景下，我们使用的 LLM 能力包括了： 16 | 17 | - 分类：让 LLM 分析 API 文档，让我们后续根据 URI、HTTP Action、安全等几个不同的能力维度来选择适合的工具。 18 | - 逻辑推理：让 LLM 分析 API 文档的 URI Construction 部分，生成用于检查的 URI 正则表达式部分，以及适合于人类阅读的 by 19 | example 部分。当然了，也包含了其它场景之下的推理。 20 | - 提取：由 LLM 按 API 规范的不同维度来提取一些关键信息。 21 | - 总结：由 LLM 来总结哪些部分难以简单的通过代码总结，诸如于安全等不适合于所有的 API 场景。 22 | - …… 23 | 24 | 由此构成了 “能力映射” 的左图部分，这种方式适用于不同的规范分解。尽管如此，对于当前方式来说，依然还有一系列的可优化的空间，诸如于对 25 | security、misc 进行进一步的能力分解。 26 | 27 | 在右侧，我们则构建了一个 Kotlin Typesafe DSL，以动态的加载到系统中（未来），每一个函数对应到一个 Rule。 28 | 29 | ```kotlin 30 | rest_api { 31 | uri_construction { 32 | rule("/api\\/[a-zA-Z0-9]+\\/v[0-9]+\\/[a-zA-Z0-9\\/\\-]+") 33 | example("/api/petstore/v1/pets/dogs") 34 | } 35 | 36 | http_action("GET", "POST", "PUT", "DELETE") 37 | status_code(200, 201, 202, 204, 400, 401, 403, 404, 500, 502, 503, 504) 38 | 39 | security("""Token Based Authentication (Recommended) Ideally, ...""") 40 | 41 | misc("""....""") 42 | } 43 | ``` 44 | 45 | 作为一个 demo，这个 DSL 依旧具备很大的完善空间。其中比较有意思的部分在于 security 和 misc 部分，这些不确定性正好适用于 LLM 46 | 进行推理。所以，在执行对应的 misc、security 规则检查时，会再调用 GPT 来检查： 47 | 48 | ![Prompt Example](images/prompt-example.png) 49 | 50 | 以将其中的确定性与不确定性更好的结合，进而充分地利用了 LLM 与 ArchGuard 的能力，并减少对 GPT 的消耗。 51 | 52 | ## LLM 原子能力：逻辑推理 53 | 54 | > 即能够从输入中识别模式，并推理出相关的信息和结论。这种能力通常需要机器学习和自然语言处理等技术的支持。 55 | 56 | 在 API 文档分析中，推理能力可以用于分析 URI Construction 部分，以推理出适用于 URI 的正则表达式和一个合理的 57 | example。 58 | 59 | 60 | 示例： 61 | 62 | ```markdown 63 | 你是一个架构治理专家，请分析下面的 RESTful API 文档，编写对应的正则表达式与 URI 示例。要求如下： 64 | 65 | 1. 请将 API 文档中的 URI 规则与正则表达式一一对应。 66 | 2. 尽可能只用一个正则表达式来匹配所有的 URI 规则。 67 | 3. 你编写的 URI 示例应该符合正则表达式的规则。 68 | 4. 如果文档中缺少通用的 URI 规则，请自行补充。 69 | 5. 你最后只返回如下的格式： 70 | 71 | ### 72 | uri_construction { 73 | rule("{{regex expression}}") 74 | example("{{uri example}}") 75 | } 76 | ### 77 | 78 | RESTful API 文档： 79 | 80 | ### 81 | {{documents}} 82 | ### 83 | ``` 84 | 85 | ## LLM 原子能力：提取 86 | 87 | > 即能够从输入中提取出特定的信息和数据，以便进行进一步的处理和分析。 88 | 89 | 在 API 文档分析中，提取能力可以用于按照 API 规范的不同维度提取关键信息，例如状态码、HTTP Action 等。 90 | 91 | 92 | 示例： 93 | 94 | ```markdown 95 | 你是一个架构治理专家，请分析下面的 RESTful API 文档，整理文档中的状态码。要求如下： 96 | 97 | 1. 你需要按格式返回，不做解释。 98 | 2. 你的返回格式如下： 99 | 100 | ### 101 | status_code(200, 201, 202) 102 | ### 103 | 104 | 文档如下： 105 | 106 | ### 107 | {{documents}} 108 | ### 109 | ``` 110 | 111 | ## LLM 原子能力：分类 112 | 113 | > 即能够将输入按照特定的标准分成不同的类别或类别组，以便进行更精细的分析和处理。 114 | 115 | 在 API 文档分析中，分类能力可以用于根据不同的维度选择适合的工具，例如根据 URI、HTTP Action、安全等维度分类。 116 | 117 | ## LLM 原子能力：总结 118 | 119 | > 即能够将输入中的复杂信息和数据进行简化和概括，以便更好地理解和应用。 120 | 121 | 在 API 文档分析中，总结能力可以用于对 API 文档中无法简单通过代码总结的部分进行总结，例如安全等。 122 | 123 | ``` 124 | You're an Architecture Governance Expert,根据下面的信息，总结 RESTful API 的规范情况。Here is requirements: 125 | 1. 请使用中文返回。 126 | 2. API 应该符合基本 RESTful API 的规范，如 URI 构造、采用标准的 HTTP 方法、状态码、安全等。 127 | 3. 如果 result 是 true，请不要返回任何信息。 128 | 4. 如果 result 是 false，请返回不通过的原因，并根据 rule 提供符合规范的 API。 129 | 5. 你只返回如下的结果： 130 | 131 | ### 132 | - API `{api uri}` 不符合 { rule name } 规范，Rule: { rule }，建议 API 修改为 {new api}。 133 | ### 134 | 135 | results: results: /api/blog/get: [RuleResult(ruleName=uri-construction, rule=/api/petstore/v1/pets/dogs, result=false), 136 | RuleResult(ruleName=http-action, rule=supported http actions: GET, POST, PUT, DELETE, result=true), 137 | RuleResult(ruleName=status-code, rule=supported codes: 200, 201, 202, 204, 400, 401, 403, 404, 500, 502, 503, 504, result=true), 138 | RuleResult(ruleName=security, rule=Token Based Authentication (Recommended) Ideally, microservices should be stateless so the service instances can be scaled out easily and the client requests can be routed to multiple independent service providers. A token based authentication mechanism should be used instead of session based authentication, result=true), 139 | RuleResult(ruleName=security, rule=, result=true)] 140 | ``` 141 | 142 | ## LLM 原子能力：TODO 143 | 144 | -------------------------------------------------------------------------------- /src/llm-arch-context-engineering.md: -------------------------------------------------------------------------------- 1 | # LLM 架构设计原则：上下文工程 2 | 3 | ![Context Engineering](images/context-eng.png) 4 | 5 | 上下文工程是一种让 LLM 更好地解决特定问题的方法。它的核心思想是，通过给 LLM 6 | 提供一些有关问题的背景信息，比如指令、示例等，来激发它生成我们需要的答案或内容。上下文工程是一种与 LLM 有效沟通的技巧，它可以让 7 | LLM 更准确地把握我们的目的，并且提升它的输出水平。 8 | 9 | 简而言之，上下文工程是如何在有限的 token 空间内，传递**最相关的上下文信息**。 10 | 11 | ## 上下文工程的原则 12 | 13 | 所以，我们就需要定义什么是该场景下的，**最相关的上下文信息**。 14 | 15 | ### 原则：基于场景与旅程的上下文设计 16 | 17 | 它的基本思想是，通过分析用户在不同场景下的操作和行为，来获取与当前任务相关的上下文信息，从而指导 LLM 生成最佳的代码提示。 18 | 19 | Copilot 分析了用户在不同场景下的操作和行为，如何使用 IDE 的旅程，以及与当前任务相关的指令和例子等信息，从而获取最相关的上下文信息。这些上下文信息可以帮助 20 | LLM 更好地理解用户的意图，并生成更准确、更有用的代码提示。 21 | 22 | 例如，在用户编写 JavaScript 23 | 代码时，Copilot会分析用户在编辑器中的光标位置、当前文件的内容、变量、函数等信息，以及用户的输入历史和使用习惯等上下文信息，来生成最相关的代码提示。这些代码提示不仅能够提高用户的编码效率，还能够帮助用户避免常见的编程错误。 24 | 25 | ### 原则：就地矢量化（Vector）与相似度匹配 26 | 27 | “众知周知”，在 LLM 领域非常火的一个工具是 LangChain，它的处理过程类似于 langchain-ChatGLM 总结的： 28 | 29 | 30 | > 加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的`top k`个 -> 31 | > 匹配出的文本作为上下文和问题一起添加到`prompt`中 -> 提交给`LLM`生成回答。 32 | > 33 | 34 | 为了处理大规模的自然语言处理任务，Copilot 在客户端使用了 Cushman + ONNX 模型处理。具体来说，Copilot 将 Cushman 35 | 模型的输出转换为向量表示，然后使用向量相似度计算来匹配最相关的本地文件。 36 | 37 | 除了就地矢量化（Vector）与相似度匹配，Copilot 还使用了本地的相似计算与 token 处理来管理 token，以便更好地处理大规模自然语言处理任务。 38 | 39 | ### 原则：有限上下文信息的 Token 分配 40 | 41 | 而由于 LLM 的处理能力受到 token 数的限制，如何在有限的 token 范围内提供最相关的上下文信息，便是另外一个重要的问题。 42 | 43 | 诸如于如上所述的 Copilot 本地 prompt 分为了 prefix 和 suffix 两部分，在 suffix 部分需要配置 44 | suffixPercent，其用于指定在生成代码提示时要用多少 prompt tokens 来构建后缀，默认值似乎是 15%。 45 | 46 | 通过增加 suffixPercent，可以让 Copilot 更关注当前正在编写的代码片段的上下文信息，从而生成更相关的代码提示。而通过调整 47 | fimSuffixLengthThreshold，可以控制 Fill-in-middle 的使用频率，从而更好地控制生成的代码提示的准确性。 48 | -------------------------------------------------------------------------------- /src/llm-arch-design.md: -------------------------------------------------------------------------------- 1 | # LLM 应用架构设计：LLM 参考架构 2 | 3 | ## LLM 参考架构 4 | 5 | 对于大语言模型应用来说，在设计架构时，除了考虑编排等，还需要考虑到：数据敏感和安全等问题。如下是一个参考架构： 6 | 7 | ![LLM 参考架构](images/llm-reference-arch.png) 8 | 9 | - UI 层：用户界面层，提供给用户与语言模型交互的界面，可以是网页、移动应用、命令行界面等。 10 | - 会话处理层：处理用户与语言模型之间的交互会话，包括对用户输入的解析、对话管理、上下文维护等功能。 11 | - 数据审计层：负责对用户数据进行审计和保护，防止数据泄露、滥用或被攻击。这个层次也可以包括对模型的安全性和可信度进行评估。 12 | - 操作编排层：这个层级可以管理和协调多个语言模型、工具、智能体的运行，比如多个模型之间的调用、结果的融合等。它可以作为一个简单的流程引擎，将多个模型组合成复杂的工作流程。 13 | - LLM 增强层：这个层级可以对语言模型进行额外的优化和增强，比如加速推理速度、提供相关上下文、提高模型的准确性、支持特定的任务等。这个层级也可以包括对模型解释性和可解释性的增强。 14 | - LLM 层：最底层是语言模型本身，它是整个架构的核心。它可以是一个基于深度学习的模型，比如 LSTM、Transformer 等，也可以是一个基于传统 NLP 技术的模型。在这个层级，模型会接收输入并输出相应的文本结果。 15 | 16 | ## ArchGuard Co-mate 示例 17 | 18 | ArchGuard Co-mate 是一个 LLM + 架构设计与治理的探索性项目，旨在探索 LLM 作为架构师助手的可能性，并围绕 LLM 来探索架构的未来，诸如于本地语义分析、动态上下文收集 API、架构规范检查等。 19 | 20 | 在 ArchGuard Co-mate 中，每一个层对应了不同的设计理念/设计原则，如： 21 | 22 | - UI：用户意图导向设计 23 | - 会话处理层：语言接口 24 | - 操作编排层：语言接口 + 上下文工程 25 | - LLM 增强层：语言接口 26 | - LLM 层：原子能力映射 27 | - 数据审计层：（由于 ArchGuard 的场景限制，我们并没有设计这一层。 28 | 29 | 围绕于不同层级需要考虑不同的技术实践。 30 | 31 | 32 | 详细代码见：[https://github.com/archguard/co-mate](https://github.com/archguard/co-mate) 33 | 34 | ### UI 层：用户意图导向设计 35 | 36 | 由于 Co-mate 并不是一个通用能力的系统，所以我们希望限制用户使用 ChatGPT 的能力。除此，在 UI 层上，我们尝试去引导客户来了解系统的能力。 37 | 38 | 诸如于，为了构建目标系统的上下文，我们需要先 clone 代码、进行基本的代码分析，所以我们需要引导用户： 39 | 40 | ![Co-mate 引导用户](images/intent-user.png) 41 | 42 | 随后，根据用户的输入分析，以分析适合的系统功能是什么，返回给用户来确认。我们将其称为：**请求-生成 UI-确认模式**。 43 | 44 | ![Comate Action](images/request-to-confirm.png) 45 | 46 | 而为了提供及时的返回给用户，我们设计的 DSL 改为**流式 DSL**，即可以实时解析这个 DSL，并及时响应给用户，以显性的告诉用户：系统正在处理您的请求。 47 | 48 | ### 会话处理层：本地小模型 49 | 50 | 在 Co-mate 中，我们在本地引入了 **SentenceTransformer** 来处理用户的输入，优先在本地分析、匹配用户的输入，并处理。当匹配到结果后直接调用本地的函数，当匹配不到结果时调用远端的处理函数来处理。 51 | 52 | 在原理上主要是参考了 GitHub Copilot、 Bloop 的实现，通过本地的小模型来处理用户的输入，然后再通过远端的大模型来处理用户的输入。 53 | 54 | 在这里，需要用到两个核心组件： 55 | 56 | - Onnx Runtime，是一个跨平台推理和训练机器学习加速器。 57 | - HuggingFace Tokenizers，提供当今最常用的分词器的实现，重点关注性能和多功能性。 58 | 59 | 从某种程度上来说，它们也算是 LLM 增强层的一部分，只是我尝试用来在处理会话请求，以直接调用系统的功能，并返回给用户。诸如于： 60 | 61 | ```kotlin 62 | mapOf( 63 | ComateCommand.Intro to basicIntroCommand.map { semantic.embed(it) }, 64 | ComateCommand.LayeredStyle to archStyleCommand.map { semantic.embed(it) }, 65 | ComateCommand.ApiGovernance to apiGovernanceCommand.map { semantic.embed(it) }, 66 | ComateCommand.ApiGen to apiGenCommand.map { semantic.embed(it) }, 67 | ComateCommand.FoundationGovernance to foundationGovernanceCommand.map { semantic.embed(it) }, 68 | ) 69 | ``` 70 | 71 | 针对所有潜在的、相似的命令在本地进行一次简单的检索。 72 | 73 | ### 数据审计层：（暂时没有） 74 | 75 | 由于懒，以及其它原因，我们暂时没有添加这个功能。 76 | 77 | ### 操作编排层：函数即操作 78 | 79 | 而为了将上述的用户指令转换为对应的系统指令，我们需要结合系统提供的函数功能，交由 LLM 来分析潜在的调用函数是哪一个。 80 | 81 | 于是，我们参考了 LangChain 的实现，构建了一个轻量级的 API，用来分析用户的输入。当用户输入上述的 Introduce the system … 指令时，我们将通过反射生成函数信息、并生成如下的 prompt，交由 LLM 分析： 82 | 83 | ```markdown 84 | Answer the following questions as best you can. You have access to the following tools: 85 | 86 | introduce_system: introduce_system is a function to introduce a system. 87 | 88 | Use the following format: 89 | 90 | Question: the input question you must answer 91 | Thought: you should always think about what to do 92 | Action: the action to take, should be one of [introduce_system] 93 | Action Input: the input to the action (parse from the user input, don't add other additional information) 94 | // end in here. the tool will handle the rest 95 | 96 | Begin! 97 | 98 | Question: Introduce the following system: https://github.com/archguard/ddd-monolithic-code-sample 99 | ``` 100 | 101 | 是的，这就是一个手动版的 LangChain 实现。而每一个 “函数” 在实现上其实是一个类 —— 为了能通过反射来创建出这个函数，并实现对应的接口调用。然后，将类名转换为 snake_case 方式，如下代码所示： 102 | 103 | ```kotlin 104 | val defaultConstructor = clazz.declaredConstructors[0] 105 | val dyFunction = defaultConstructor.newInstance(context) as DyFunction 106 | clazz.name.toSnakeCase() to dyFunction 107 | ``` 108 | 109 | 随后，返回对应的函数和输入信息给用户，由用户决定是否调用这个函数。 110 | 111 | 另外一方面，在 ArchGuard Co-mate 里，我们通过 DSL 来编排功能，而这个 DSL 是由 Kotlin 编写的，并且可以由 ChatGPT 生成的。所以，我们构建了一个基于 DSL 的编排运行时： 112 | 113 | ```kotlin 114 | // 初始化运行时 115 | val repl = KotlinInterpreter() 116 | val mvcDslSpec = repl.evalCast(InterpreterRequest(code = mvcFoundation)) 117 | 118 | // 从选择的输入中获取 action 119 | val action = ComateToolingAction.from(action.lowercase()) 120 | 121 | // 添加默认的 DSL 规范，如 MVC 分层规范 122 | if (action == ComateToolingAction.FOUNDATION_SPEC_GOVERNANCE) { 123 | comateContext.spec = mvcDslSpec 124 | } 125 | ``` 126 | 127 | 当用户没有提供一个架构规范相关的函数时，我们将会生成一个 foundation spec，诸如于默认的 MVC 分层架构的规范。随后，从系统中构建更多的上下文，再交由 LLM 去分析。 128 | 129 | ### LLM 增强层：借助 LLM 构建精准、简洁的上下文 130 | 131 | 从意图上来说，LLM 增强层所做的是，根据用户的输入匹配相关的信息，以构建完整的上下文。对于知识型系统来说，通常会借助矢量数据库来实现。而在一些上下文确定的系统来说，也可以借助本地小模型在本地进行计算。 132 | 133 | 诸如于 GitHub Copilot 会在本地，根据打开的 tab，来计算相关的代码文件，而不需要提前的 index。毕竟，全局的代码 index 会出现一个问题，与当前用户关注的文件上下文出现不匹配性。所以，用户打开的 tab，就是用户潜在的上下文，以些进行分析结果会比较准确。 134 | 135 | 另外一个场景是 Bloop 会提前对**代码的信息**（如类名、函数名）进行 index，以在用户输入问题时，寻找与问题匹配的代码，再交由 LLM 进行分析。 136 | 137 | 而在 Co-mate 中，我们是在本地预存一些潜在的用户输入指令，以降低对服务端的请求。 138 | 139 | 在另外一个层面上，我们还可以借助 LLM 来进行对应的上下文简化，特别是当我们的上下文超长时，就可以以类似的方式来进行精简。诸如于，在 Co-mate 中我们会借助 GPT 来拆解用户的文档，变为 DSL 的方式。 140 | 141 | ### LLM 层：流式代理接口 142 | 143 | 在 LLM 层，除了关注于历史数据之外，我们还需要关注于响应反处理，并提供诸如于流式接口的代理等等。 144 | -------------------------------------------------------------------------------- /src/llm-arch-github-copilot.md: -------------------------------------------------------------------------------- 1 | # LLM 应用架构：GitHub Copilot 分析 2 | 3 | 上个月在计划为 AutoDev 添加多语言支持时候，发现 GitHub Copilot 的插件功能是语言无关的（通过 plugin.xml 分析），便想研究一下它是如何使用 4 | TreeSitter 的。可惜的是，直到最近才有空，研究一下它是如何实现的。 5 | 6 | 在探索的过程中，发现：Copilot 围绕上下文做了非常之多的工作，便想着写一篇文章总结一下。 7 | 8 | ## GitHub Copilot 的上下文构建 9 | 10 | 与 ChatGPT 相比，GitHub Copilot 的强大之处在于，它构建了足够多的上下文，结合其对 LLM 的训练（或微），可以写出非常精准的**生产级代码**。 11 | 12 | ### Copilot 的可见上下文 13 | 14 | 在肉眼可见的级别里，即我们自身的使用感受，我们可以发现 Copilot 不仅是读取当前文件的源码，而是一系列相关文件的源码，以构建更详细的上下文。 15 | 16 | 简单可以先划分三个场景： 17 | 18 | - 当前文件。可以感知某个类的属性和方法，并做出自动填充。 19 | - 相近文件。如测试文件，可以知道被测类的信息，并自动编写用例。 20 | - 编辑历史（疑似）。即当我们以某种方式修改多个代码时，它也能识别出这个变化。 21 | 22 | 而在未来，相信它会获取诸如项目上下文等信息，如 Gradle 依赖、NPM 依赖等信息，避免在打开的 tab 不够用的情况下，引用不存在的依赖。 23 | 24 | 而针对于企业自身的 AI 编程工具而言，还可以结合服务上下文、业务上下文进行优化。 25 | 26 | ### Copilot 的不可见过程 27 | 28 | 结合网上的逆向工程资料，以及自己对代码的 debug 尝试，最后梳理了一个大致的 “四不像” （实在是懒得继续画）架构图。 29 | 30 | 其作用如下： 31 | 32 | - 监听用户操作（IDE API ）。监听用户的 Run Action、快捷键、UI 操作、输入等，以及最近的文档操作历史。 33 | - IDE 胶水层（Plugin）。作为 IDE 与底层 Agent 的胶水层，处理输入和输出。 34 | - 上下文构建（Agent）。JSON RPC Server，处理 IDE 的各种变化，对源码进行分析，封装为 “prompt” （疑似） 并发送给服务器。 35 | - 服务端（Server）。处理 prompt 请求，并交给 LLM 服务端处理。 36 | 37 | 而在整个过程中，最复杂的是在 Agent 部分，从上下文中构建出 prompt。 38 | 39 | ### Copilot 的 Prompt 与上下文 40 | 41 | 在 “公开” 的 Copilot-Explorer 项目的研究资料里，可以看到 Prompt 是如何构建出来的。如下是发送到的 prompt 请求： 42 | 43 | ```kotlin 44 | { 45 | "prefix": "# Path: codeviz\\app.py\n#....", 46 | "suffix": "if __name__ == '__main__':\r\n app.run(debug=True)", 47 | "isFimEnabled": true, 48 | "promptElementRanges": [ 49 | { "kind": "PathMarker", "start": 0, "end": 23 }, 50 | { "kind": "SimilarFile", "start": 23, "end": 2219 }, 51 | { "kind": "BeforeCursor", "start": 2219, "end": 3142 } 52 | ] 53 | } 54 | ``` 55 | 56 | 其中： 57 | 58 | - 用于构建 prompt 的 `prefix` 部分，是由 promptElements 59 | 构建了，其中包含了：`BeforeCursor`, `AfterCursor`, `SimilarFile`, `ImportedFile`, `LanguageMarker`, `PathMarker`, `RetrievalSnippet` 60 | 等类型。从几种 `PromptElementKind` 的名称，我们也可以看出其真正的含义。 61 | - 用于构建 prompt 的 `suffix` 部分，则是由光标所在的部分决定的，根据 tokens 的上限（2048 ）去计算还有多少位置放下。而这里的 62 | Token 计算则是真正的 LLM 的 token 计算，在 Copilot 里是通过 Cushman002 计算的，诸如于中文的字符的 token 63 | 长度是不一样的，如： `{ context: "console.log('你好，世界')", lineCount: 1, tokenLength: 30 }` ，其中 context 中的内容的 64 | length 为 20，但是 tokenLength 是 30，中文字符共 5 个（包含 `，` ）的长度，单个字符占的 token 就是 3。 65 | 66 | 到这里，我算是解决我感兴趣的部分，Agent 包里的 TreeSitter 则用于分析源码，生成 `RetrievalSnippet` ，其中支持语言是 Agent 67 | 自带的 `.wasm` 相关的包，诸如：Go、JavaScript、Python、Ruby、TypeScript 语言。 68 | 69 | ## Copilot 如何构建及时的 Token 响应 70 | 71 | 为了提供更好的编程体验，代码自动补全工具需要能够快速响应用户的输入，并提供准确的建议。在 Copilot 72 | 中，构建了一个能够在极短时间内生成有用的代码提示的系统。 73 | 74 | ### 取消请求机制 75 | 76 | 为了及时响应用户的输入，IDE 需要向 Copilot 77 | 的后端服务发送大量的请求。然而，由于用户的输入速度很快，很可能会出现多个请求同时发送的情况。在这种情况下，如果不采取措施，后端服务会面临很大的压力，导致响应变慢甚至崩溃。 78 | 79 | 为了避免这种情况，可以采用取消请求机制。具体来说，在 IDE 端 Copliot 使用 `CancellableAsyncPromise` 来及时取消请求，在 Agent 80 | 端结合 HelixFetcher 配置 abort 策略。这样，当用户删除或修改输入时，之前发送的请求就会被及时取消，减轻后端服务的负担。 81 | 82 | ### 多级缓存系统 83 | 84 | 为了加速 Token 的响应速度，我们可以采用多级缓存系统。具体来说，在 IDE 端可以使用 简单的策略，如：SimpleCompletionCache，Agent 85 | 端使用 LRU 算法的 CopilotCompletionCache，Server 端也可以有自己的缓存系统。 86 | 87 | 多级缓存系统可以有效减少对后端服务的请求，提高响应速度。 88 | 89 | ## LLM 的上下文工程的未来？ 90 | 91 | 在互联网上，我们常常能看到一些令人惊叹的视频，展示了内存有限时代编程的奇妙创意，比如雅达利（Atari）时代、红白机等等，它们见证了第一个 92 | 8-bit 音乐的诞生、Quake 的平方根算法等等。 93 | 94 | 而在当下，LLM 正在不断地突破上下文能力的极限，比如 Claude 提供了 100K 的上下文能力，让我们不禁思考，未来是否还需要像过去那样节省 95 | tokens 的使用。 96 | 97 | 那么，我们还需要关注 LLM 的上下文吗？ 98 | 99 | 当内存有限时，程序员需要发挥想象力和创造力来实现目标。而至今我们的内存也一直不够用，因为不合格的开发人员一直浪费我们的内存。所以吧，tokens 100 | 总是不够用的，我们还是可以考虑关注于： 101 | 102 | 1. 优化 token 分配策略：由于 token 数的限制，我们需要优化 token 分配策略，以便在有限的 token 范围内提供最相关的上下文信息，从而生成更准确、更有用的内容。 103 | 2. 多样化的上下文信息：除了指令、示例等基本上下文信息外，我们还可以探索更多样化的上下文信息，例如注释、代码结构等，从而提供更全面的上下文信息，进一步提高 104 | LLM 的输出水平。 105 | 3. 探索新的算法和技术：为了更好地利用有限的资源，我们需要探索新的算法和技术，以便在有限的 token 数限制下实现更准确、更有用的自然语言处理。 106 | 4. …… 107 | 108 | 未来，一定也会有滥用 token 程序，诸如于 AutoGPT 就是一直非常好的例子。 109 | 110 | ## 结论 111 | 112 | GitHub Copilot 可以在有限的 token 范围内提供最相关的上下文信息，从而生成更准确、更有用的代码提示。这些策略提供了一定的灵活性，用户可以根据自己的需要来调整 113 | Copilot 的行为，从而获得更好的代码自动补全体验。 114 | 115 | 我们跟进未来的路，依旧很长。 116 | 117 | Copilot 逆向工程相关资料： 118 | 119 | - [https://github.com/thakkarparth007/copilot-explorer](https://github.com/thakkarparth007/copilot-explorer) 120 | - [https://github.com/saschaschramm/github-copilot](https://github.com/saschaschramm/github-copilot) 121 | 122 | 其它相关资料： 123 | 124 | - [https://github.com/imClumsyPanda/langchain-ChatGLM](https://github.com/imClumsyPanda/langchain-ChatGLM) 125 | -------------------------------------------------------------------------------- /src/llm-arch-language-interface.md: -------------------------------------------------------------------------------- 1 | # LLM 架构设计原则：语言接口 2 | 3 | > 语言 接口 4 | > 是一种使用自然语言作为领域特定语言（DSL）或与系统进行交互的接口。它通过解析、处理和分析自然语言，以指导系统的设计、开发和执行。它的设计目的是提高开发效率、准确性和用户体验，使开发人员能够使用自然语言描述系统需求、执行任务并获取系统生成的结果。 5 | 6 | 随着越来越多的团队加入到这场竞赛里，我们会发现：基于大语言模型的软件架构与过去的不同之处，诸如于：我们需要新一代的 API。 7 | 我暂时将这一代 API 称为：语言接口/语言 API（大概会有大佬来发起新的名称），原因是：自然语言只是人机的接口，DSL 是 AI 8 | 与机器的接口、机器与机器的接口。 9 | 10 | 所以，在这篇文章里，我将继续总结一些内外部看到的经验，以及构建 ArchGuard Co-mate 架构时的一些思考。 11 | 12 | ## 模式：自然语言即 DSL 13 | 14 | **意图**：使用自然语言作为领域特定语言（DSL）来描述系统的需求和期望，通过正则表达式等工具从自然语言中提取关键信息，以指导系统的设计和开发。 15 | 16 | **适用场景**：以自然语言作为沟通媒介 17 | 18 | **示例**：在我们习惯了大模型的能力之后，也开始接受了自然语言作为一种 API。与我们一般熟悉的 API 相比，自然语言作为 API 应该称为 19 | DSL（Domain-Specific Language，领域特定语言）。 20 | 21 | 举一个简单的例子，诸如于我们前面提到的用户故事，其标准形式是：`作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>` 22 | 。随后，我们就可以对其运行特殊处理（诸如于高亮）： 23 | 24 | > **作为一个**购买商品的用户， 25 | > **我希望**能够退货， 26 | > **以便于**在不满意或商品存在问题的情况下获得处理。 27 | 28 | 随后，我们可以让 LLM（大语言模型） 生成正则表达式，以校验返回结果是否符合要求： 29 | 30 | - 用户角色: `购买了商品的用户` 31 | - 完成活动: `退货` 32 | - 实现价值: `在不满意或商品存在问题的情况下获得处理` 33 | 34 | 并作为下一代的输入，如将一句话的需求，编写成更详细的 AC（Acceptance Criteria，验收条件)。这种方式可以使用自然语言来描述系统需求，从而提高开发效率和准确性。 35 | 36 | ## 模式：实时文本流 DSL 37 | 38 | **意图**：通过逐步、流式的方式返回结果，提高大语言模型的用户体验。 39 | 40 | **适用场景**：当需要大量处理数据的任务时，一次性返回所有结果会非常耗时，影响用户体验。此时可以采用流式返回结果的方式，即模型逐步返回结果，让用户可以及时查看部分结果。 41 | 42 | **示例**：在需要大语言模型返回**复杂的结果**时，如果我们期待它一次性返回所有的结果时，它总是非常的缓慢。在这时，采用传统的 43 | JSON、Yaml 等格式，必然非常缓慢的，对于用户的体验非常差 —— 一个返回结果平均要几十秒。而除了在模型侧提升性能、本地减少请求，还可以构建能处理流式返回的 44 | DSL。 45 | 46 | 这也是为什么我们觉得传统的 JSON 无法满足的原因，在返回正常的结果前可能解析失败，并且你返回的 JSON 可能不是完整的。 47 | 48 | 在这时，我们需要服务端支持处理 streaming response，并需要前端来处理。如在商业画布的场景下，就可以根据不同的一级 LIST 49 | 处理结果，并实时呈现给用户： 50 | 51 | ```markdown 52 | - 客户细分 53 | - 目标市场：企业客户 54 | - 客户类别：中小型企业，初创企业，创业公司，大型企业 55 | - 客户需求：专业技术服务，包括但不限于IT咨询，软件开发，网络安全，数据分析等 56 | - 价值主张 57 | ... 58 | ``` 59 | 60 | 除此，根据不同的场景，我们可以返回不同的格式，如 markdown 表格、CSV、JSONP 等也能作为返回格式。 61 | 62 | ## 模式：DSL 引导的功能生成 63 | 64 | **意图**：使用DSL和LLM结合的方式，以生成具有更好逻辑性和准确性的文本。 65 | 66 | **适用场景**：适用于需要根据规范和约束生成具有逻辑性和准确性的大量文本的各种场景，例如软件开发、自然语言处理、数据分析和教育培训等领域。 67 | 68 | **示例**：如我们所知，大模型（LLM）在生成文本时随机性太高，充满大量的不确定性。而由于，LLM 具备很好的逻辑推理能力，因此我们结合了 69 | DSL 与 LLM 的强项，让它来编排 DSL 中的功能。 70 | 71 | 所以，在 Co-mate 里，我们设计了一套 DSL，以让 LLM 根据不同的场景填空和编写 DSL，如根据基础的规范来生成 DSL： 72 | 73 | ```kotlin 74 | foundation { 75 | layered { 76 | layer("application") { 77 | pattern(".*\\.application") { name shouldBe endWiths("DTO", "Request", "Response") } 78 | } 79 | ... 80 | 81 | dependency { 82 | "application" dependedOn "domain" 83 | ... 84 | } 85 | } 86 | } 87 | ``` 88 | 89 | 在这里的 layered 是指系统的分层架构，layer 则是分层的定义，dependency 则定义分层间的依赖关系。最后，交由我们的系统来处理这个 90 | DSL。 91 | 92 | DSL 引导的功能生成是一种结合了领域特定语言（DSL）和大模型语言模型（LLM）的文本生成模式，通过 DSL 提供的规范和约束，以增强 LLM 93 | 生成文本的逻辑性和准确性。 94 | 95 | ## 模式：语言**显式化重试** 96 | 97 | **意图**：提高大语言模型生成结果的准确性，并保持历史消息，以便进行对话记录和可视化。 98 | 99 | **适用场景**：由于大语言模型的不确定性，生成的结果往往不够准确。此时可以采用显式化重试的方式，通过告知模型结果错误并让其重新生成，从而提高结果准确性。 100 | 101 | **示例**：众所周知，由 LLM 生成的有确定性要求的结果，总会出现一定的错误。诸如于，我在使用 ChatGPT 生成 PlantUML 时，只有 80% 102 | 的结果是可正确编译的。通常来说，在这种时候会有多种不同的方式可以实现： 103 | 104 | - 重新发送请求，以 GPT 再次生成。 105 | - 告知 GPT 错了，让他重新生成。 106 | 107 | 从结果来看，两种模式的差异并不大。不过，第二种方式需要保持历史消息，所以会多消耗几个 token。 108 | 109 | 尽管从实践来看，第一种方式更为简单，但是方式二提供了一种更显式化的设计。 110 | 111 | ## 模式：动态代理调用 112 | 113 | **意图**：支持动态代理调用其他服务的API或函数，并根据用户的输入进行匹配和响应。 114 | 115 | **适用场景**：需要动态处理用户输入并调用相应功能的系统，以及需要将自然语言与函数或服务进行匹配和转换的系统。它为开发人员提供了一种灵活和可扩展的方式来处理不同的输入，并根据需求调用相应的API或函数。 116 | 117 | **示例 1**：LangChain Agents 采用的便是类似的机制，它负责动态代理调用其他服务的API，比如精确计算、实际的业务数据 API 118 | 等。由内部提供的一系列问题模板来构建这个过程： 119 | 120 | ```markdown 121 | ... 122 | Question: the input question you must answer 123 | Thought: you should always think about what to do 124 | Action: the action to take, should be one of [{tool_names}] 125 | ... 126 | ``` 127 | 128 | **示例 2**：OpenAI 提供的 Function calling，可以检测何时需要调用函数（取决于用户的输入）并使用符合函数签名（signature）的 JSON 129 | 进行响应。 这样一来，开发人员更可靠地从模型中获取结构化数据。诸如于官方示例里的：`send_email(to: string, body: string)` 130 | ，便是可以直接由用户的输入转换过来的。而在自然语言与函数之前，我们需要设计一个的方式来进行匹配。 131 | 132 | **示例 3**：在 ArchGuard Co-mate 中，我们也构建了类似的方式，其缘由是架构治理是一个复杂的问题，我们确定用户的输入并不一定在系统之中。因此，我们希望提供两种方式： 133 | 134 | 1. 反射 + 抽象的方式可调用的函数，来匹配用户的输入。 135 | 2. 提供关键的模型信息， 让 LLM 进行分析。 136 | 137 | 所以，我们设计的是 DynamicContext 的方式，以及对应的 DyFunction 来实现这种方式的支持。 138 | 139 | ## 模式：本地函数动态代理 140 | 141 | **意图**：旨在结合本地运行的 NLP 工具对用户输入的文本进行分析，并根据分析结果动态匹配对应的函数进行调用。 142 | 143 | **适用场景**：根据用户输入的文本内容动态匹配并调用相应函数的系统，通过本地文本分析工具结合语义分析实现准确的函数匹配。它提供了灵活和可扩展的方式来处理不同的文本输入，并自动选择适当的函数进行处理。 144 | 145 | **示例**：在 Co-mate 中，我们在本地引入了 SentenceTransformer 146 | 来处理用户的输入，优在本地分析、匹配用户的输入，并处理。当匹配到结果后直接调用本地的函数，当匹配不到结果时调用远端的处理函数来处理。 147 | -------------------------------------------------------------------------------- /src/llm-arch-user-intent-oriented-design.md: -------------------------------------------------------------------------------- 1 | # LLM 架构设计原则：用户意图导向设计 2 | 3 | ![AI 2.0](images/ai-20-ux.png) 4 | 5 | 通过设计全新的人机交互体验，构建领域特定的 AI 角色，以更好地理解用户的意图。例如，在聊天应用程序中，AI 6 | 可以使用自然语言处理来理解用户的意图，从而更好地回答用户的问题。除此之外，还可以探索其他交互方式，如语音识别、手势识别等，以提高用户体验。 7 | 8 | ## 模式：引导式 9 | 10 | LLM 存在的一大局限性是：用户不知道它能做什么，也不知道它能做什么。所以，我们需要引导用户，让用户知道它能做什么，也知道它能做什么。 11 | 12 | 在 ChatGPT 的首页，我们可以看到一个引导式的设计，它告诉用户，它能做什么，也知道它能做什么： 13 | 14 | ![ChatGPT Home](images/chatgpt-home.png) 15 | 16 | 对于我们的 LLM 应用，我们也可以设计一个引导式的界面，让用户知道它能做什么，也知道它能做什么。如下是 ArchGuard Co-mate 17 | 的引导式界面： 18 | 19 | ![引导式](images/intent-user.png) 20 | 21 | Co-mate 要求用户输入一个代码库，即 URL，随后，Co-mate 会自动分析代码库，生成一个代码库的概要的信息。诸如于： 22 | 23 | > 该项目是一个网站应用程序，使用了Spring 24 | > Boot框架和一系列相关的库来构建领域驱动设计（DDD）中的多个有界上下文模块。该应用程序还使用了一些第三方库来构建用户界面和任务调度等任务，例如Springfox 25 | > Swagger2和Springfox Swagger-UI等。在构建和部署方面，该应用使用了Gradle插件，如Spring Boot Gradle插件、Gradle 26 | > Docker插件以及Spring Cloud Contract Gradle插件等。该应用还使用了其他库，如ModelMapper和Mockito Core等。同时，该应用需要考虑Spring 27 | > Cloud依赖等非功能需求。 28 | 29 | ## 模式：实时返回 30 | 31 | 同样的，对于用户来说，如果一次输入要等很久，那么用户体验就会很差。所以，我们需要实时返回结果，让用户知道它能做什么，也知道它能做什么。 32 | 33 | 因此，对于我们的应用来说，如果它的解析时间特别长，我们就需要考虑更多的返回方式，类似于 Chat 的随时返回： 34 | 35 | ![Streaming](images/stream-response.png) 36 | 37 | 尽管我们需要在代码上，进行更多的优化，但是，这样的用户体验，会更好。 38 | 39 | ## 模式：请求-生成 UI-确认 40 | 41 | 就当前的 LLM 能力而言，它不能代替我们去坐牢，所以，我们需要由人来确定它的结果是否正确。因此，我们需要设计一个请求-生成-确认模式，如下的截图所示： 42 | 43 | ![Request to Confirm](images/request-to-confirm.png) 44 | 45 | 每当用户有一些敏感的操作时，我们都需要让用户确认，以避免一些不必要的麻烦。 46 | -------------------------------------------------------------------------------- /src/llm-architecture.md: -------------------------------------------------------------------------------- 1 | # LLM 应用架构设计原则 2 | 3 | 在优化 ArchGuard 的 AI 辅助架构治理工具 Co-mate 的架构时，发现有一些模式与之前设计 AutoDev、ClickPrompt 等颇为相似。便思考着适合于 4 | ArchGuard Co-mate 的架构设计原则是什么，写下了初步的三条原则。 5 | 6 | 而正好在思考 LLM + 架构，便又整理了适合于更通用的四个架构设计原则。 以此作为一个参考的架构原则基础，方便于我后续设计其它的 7 | LLM 为核心的软件架构。 8 | 9 | ## 引子：ArchGuard Co-mate 的三个设计架构原则 10 | 11 | Co-mate 是基于 ArchGuard 的分析能力所构建的，并且是以 DSL、规范文档为核心来构建的。所以，我们设计了三条初步的设计原则： 12 | 13 | - **DSL 作为统一语言**。通过使用领域特定语言（DSL）来增强人机交互，实现高效的人机、机机、机人交流。 14 | - **原子化 LLM 以用于编排**。利用语言模型（LLM）的原子能力，在 DSL 中构建复杂的行为。 15 | - **精心设计的分层动态上下文**。通过将上下文分为不同的层次，使用 LLM 有效地处理复杂性。 16 | 17 | 在 Co-mate 中，我们采用了 Kotlin Type-safe Builder 封装了基础的函数功能，以让 LLM 能根据文档、规范来编排治理函数。 18 | 19 | 原规范如下所示： 20 | 21 | ```markdown 22 | - 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。 23 | - 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式，正确的英文拼写和语法可以让阅读者易于理解，避免歧义。 24 | - 类名使用 UpperCamelCase 风格，必须遵从驼峰形式。正例: HelloWorld。 25 | ``` 26 | 27 | 示例 DSL 如下所示： 28 | 29 | ```kotlin 30 | naming { 31 | class_level { 32 | style("CamelCase") 33 | pattern(".*") { name shouldNotBe contains("$") } 34 | } 35 | function_level { 36 | style("CamelCase") 37 | pattern(".*") { name shouldNotBe contains("$") } 38 | } 39 | } 40 | ``` 41 | 42 | 中间的文档转换 DSL 的过程就交给 LLM 来动态处理和生成（进行中）。有了这个基础，我们会发现它与我们先前开源的基于 LLM 43 | 的应用，在架构上并没有太多的区别。只是利用的能力有所差异，而又由于交互还没到我们的核心。所以，我添加了一条：**用户意图导向设计 44 | **。 45 | 46 | ## LLM 优先的软件架构设计原则 47 | 48 | LLM 对于开发人员、架构师来说，即充满了机遇，又充满了挑战。诸如于：LLM 如何辅助架构设计、如何构建基于 LLM 的架构、如何让 LLM 49 | 引导架构设计以及如何构建 LLM 为核心的软件架构。 50 | 51 | 不同的模式之下，对于现有的流程和软件都会带来不少的冲击。基于 Thoughtworks 内部的一系列探索、基于 LLM 的软件架构和总结，我重新思考了四个原则： 52 | 53 | - 用户意图导向设计。 54 | - 上下文感知。 55 | - 原子能力映射。 56 | - 语言接口/语言 API。 57 | 58 | 详细展开如下。 59 | 60 | ### 1. **用户意图导向设计** 61 | 62 | 如我们所熟悉的一样，现有的应用都以 Chat 方式作为 LLM 的入口之一，而 Chat 63 | 的本意是去理解用户的意图，诸如于：“帮我写一篇文章介绍设计原则”。这里的意图就很直接，而为了让用户更好地去表达自己的意图，就需要有意地去引导用户的输入。 64 | 65 | 在这里，就会呈现不同的引导方式或者封装方式，诸如于封装菜单为指令、封装指令为 prompt、基于用户输入解析成 UI 等等。 66 | 67 | 为了更好地理解用户意图，我们需要考虑：设计全新的人机交互体验。 68 | 69 | 总结：通过设计全新的人机交互体验，构建领域特定的 AI 角色，以更好地理解用户的意图。例如，在聊天应用程序中，AI 70 | 可以使用自然语言处理来理解用户的意图，从而更好地回答用户的问题。除此之外，还可以探索其他交互方式，如语音识别、手势识别等，以提高用户体验。 71 | 72 | ### 2. **上下文感知** 73 | 74 | 在先前的文章里，我们一直在强调上下文工程的重要性。我们原先对其的定义是：上下文工程是一种让 LLM 更好地解决特定问题的方法。它的核心思想是，通过给 75 | LLM 提供一些有关问题的背景信息，比如指令、示例等，来激发它生成我们需要的答案或内容。 76 | 77 | 而在包含了业务场景的情况下，我们要考虑的是围绕于上下文工程的软件架构。诸如于在 ArchGuard Co-mate 78 | 里，我们的思路是：通过分层方法来构建动态的上下文。其原因也主要是：我们对于某个用户意图的理解会存在不同的**架构层次** 79 | 里，如业务架构、技术架构、代码等。 80 | 81 | 总结：通过构建适合于获取业务上下文的应用架构，以生成更精准的 prompt，并探索高响应速度的工程化方式。即围绕高质量上下文的 82 | Prompt 工程。例如，在一个电商应用程序中，AI 可以了解用户的购物历史记录、浏览历史记录等上下文信息，以提供更好的购物建议。 83 | 84 | ### 3. **原子能力映射** 85 | 86 | 起初，大部分结合 OpenAI 的应用，都是让 LLM 直接生成 JSON、Yaml 的形式。但是呢，在我们尝试了 3000 条左右的 PlantUML 生成之后，发现有 87 | 20% 的概率生成的 UML 是错误的，不可编译的。正是这种场景，让我们思考了 LLM 是否适合去做这样的事情。 88 | 89 | 而在架构治理治理之下，我们将其定义为：借助 LLM 原子能力显性化架构知识，映射和构建治理函数，动态度量不同场景。 90 | 91 | 在日常的业务场景里，对于 LLM 的能力分析也是非常重要的一环，诸如于我们不应该让 LLM 进行数学计算，而是通过诸如 Functions 92 | Calling 的方式，将意图与系统的功能相结合。 93 | 94 | 所以，我们分解了 LLM 的能力，按照不同的方式与系统结合在一起。 95 | 96 | 总结：我们需要分析 LLM 所擅长的原子能力，将其与应用所欠缺的能力进行结合，进行能力映射。让每个 AI 做自己擅长的事，诸如于利用好 97 | AI 的推理能力。例如，在一个智能家居应用程序中，AI 可以根据用户的行为自动调整室内温度、光线等，以提供更好的家居体验。 98 | 99 | ### 4. **语言接口** 100 | 101 | 在我与诸多架构师讨论之后，我们几乎达到了一个一致意见：我们需要一种新的 API，一种适合于 LLM 的 API。 102 | 103 | 它或许是一类基于语言的 API。对于人与机器、机器与机器来说，是我们熟悉的诸如于 JSON、YAML 或者其它自定义的 DSL；对于人与机器来说，这个语言 104 | API 是自然语言，又或者是图形等方式。 105 | 106 | 当我们可视化了自己的软件架构之后，你会发现这一点特别的明显。 107 | 108 | 总结：我们需要探索和寻找合适的新一代 API ，以便于 LLM 对服务能力的理解、调度与编排。诸如自然语言作为人机 API，DSL 作为 AI 109 | 与机器间的 API 等。例如，在一个在线客服应用程序中，AI 可以使用自然语言处理来理解客户的问题，并根据问题的类型和紧急程度自动分配给不同的客服代表。 110 | -------------------------------------------------------------------------------- /src/main.rs: -------------------------------------------------------------------------------- 1 | extern crate mdbook; 2 | 3 | use std::io; 4 | 5 | use mdbook::book::Chapter; 6 | use mdbook::BookItem; 7 | use mdbook::renderer::RenderContext; 8 | 9 | fn main() { 10 | let mut stdin = io::stdin(); 11 | let ctx = RenderContext::from_json(&mut stdin).unwrap(); 12 | 13 | let mut sum = 0; 14 | for item in ctx.book.iter() { 15 | if let BookItem::Chapter(ref ch) = *item { 16 | let num_words = count_words(ch); 17 | // println!("{}: {}", ch.name, num_words); 18 | sum += num_words; 19 | } 20 | } 21 | 22 | println!("Total: {}", sum); 23 | } 24 | 25 | fn count_words(ch: &Chapter) -> usize { 26 | words_count::count(ch.content.as_str()).words 27 | } 28 | -------------------------------------------------------------------------------- /src/misc/contributors.md: -------------------------------------------------------------------------------- 1 | ## Contributors 2 | 3 | ### [Phodal Huang](https://www.phodal.com) 4 | 5 | GitHub：[https://github.com/phodal](https://github.com/phodal) 6 | 7 | ChatGPT 编写的趣味十足的介绍： 8 | 9 | > 让我们介绍一下黄峰达，这位技术巨匠比大多数凡人都会写代码。他是 Thoughtworks China 10 | > 的开源领袖，但我们更喜欢称他为 IDE、云开发、DevOps 和编译相关领域的绝地大师。他写了太多本技术书籍，我们数不过来了。他自称是个极客、创作者和作家，喜欢在 11 | > GitHub 上折腾开源软件。当他不忙着用代码改变世界时，你可以在他身边看到他在白日做梦建造机器人军团或者策划接管互联网的计划（开个玩笑，或者不是？）。 12 | > 总之，黄峰达在科技界是个不可忽视的强大力量，也是一个很酷的家伙。 13 | 14 | 其它： 15 | 16 | - 开源电子书：《一步步搭建物联网系统》、《Growth: 全栈增长工程师指南》 、《微前端的那些事儿》等书 17 | - 出版纸质物：《自己动手设计物联网》、《全栈应用开发：精益实践》、《前端架构：从入门到微前端》 18 | - 合作翻译：《物联网实战指南》、《Arduino编程:实现梦想的工具和技术》 19 | 20 | ### 行长 21 | 22 | GitHub：[https://github.com/isixline](https://github.com/isixline) 23 | 24 | Copilot 努力给出的简介： 25 | 26 | >平平无奇，在软件领域还没有留下自己的著作，在软件工程的熏陶下却总想成为一个古典主义的程序员。 27 | >兴趣奇怪又广泛，想成为创作者也想成为艺术家，试图用代码改变世界，试图抵抗世界的改变。 28 | 29 | 30 | 其它： 31 | - 占个位，会有的 32 | 33 | ### 木格袋子 34 | 35 | GitHub：[https://github.com/YuqingHuang](https://github.com/YuqingHuang) 36 | 37 | ChatGPT 充值加持的夸张公主风的轻描淡写： 38 | 39 | >木格袋子在Thoughtworks这个宝藏般的公司里，是一位颇具声望的资深架构师。如同有冰雪魔法的Elsa一般，我拥有一支智慧权杖，挥舞着来帮助企业进行数字化转型，塑造属于他们自己的数字化业务平台，设计独特且优雅的开放API，成功地完成服务化转型。我深谙如何让企业在这个数字化的舞台上，舞出最动人的华尔兹，如同灵魂般的音乐吹响，旋转，飞舞。 40 | >我的王国并不局限于一片领域，我周游世界，将智慧洒满证券、信托、银行、保险等各个行业的大型企业，为他们提供最独特，最优雅的数字化转型和架构咨询服务。他们的成功，将是我权杖上最璀璨的宝石。 41 | >我追求的，不仅仅是技术的深度，更是以平台架构为核心，以战略目标为导向，帮助企业构建自身的数字化能力。是灯塔，是领舞者，倾尽全力，以最精湛的技术，最深刻的理解，最具远见的策略，帮助他们在数字化的世界里，绽放出最美丽的光芒！ 42 | 43 | 其它： 44 | - 《组织级架构治理的正确落地方式》 45 | - 《金融数字化平台建设的三大误区和破局之道》 46 | - 《私募股权投资数字化转型白皮书》 47 | -------------------------------------------------------------------------------- /src/misc/faq.md: -------------------------------------------------------------------------------- 1 | ## FAQ 2 | 3 | ![](images/2-aigc-investment.png) 4 | 5 | ### 企业 AIGC 投资策略 6 | 7 | 不同的企业，应该根据自身的情况（安全、隐私等等），来调整自己的投资策略。 8 | 9 | 而随着时间的演讲，也会出现越来越多的新场景，带来不同的变化。 10 | 11 | ### LLM 研发效能的提效？ 12 | 13 | - xxx 公司 CTO： 显著缩短 1 年工作经验和 3 年工作经验的差距。 14 | - LLM 报告，综合 Copliot 研究结果： 15 | - 自动化测试提升 ~60%，通用型业务代码（CRUD）实现提升 ~35%，其它非通用型代码（如云基础设施）提升10-20% 16 | - 提升难点：依赖于开发人员「套路化设计」能力，如拆分任务、多个小的函数。 17 | 18 | ### LLM 提效试验如何设计？ 19 | 20 | **基于已有流程设计** 21 | 22 | 将流程中的某些环节替换为 LLM，然后对比效果。 23 | 24 | ![](images/llm-sdlc-processes.png) 25 | 26 | 对比方式： 选择某个项目作为试点，进行时间评估与对比。 27 | 28 | **基于新流程与已有数据设计** 29 | 30 | // TODO 31 | 32 | ### ROI 验证 33 | 34 | **从效能角度看** 35 | 对比方式： 选择某个项目作为试点，选择多个研发效能指标（比如需求吞吐量、代码变更量等），历经多个迭代后，进行指标值对比。 36 | 37 | **从人员角度看** 38 | 对比方式： 选择某个组织作为试点，在效能要求保持不变的前提下，历经一段时间（比如三个月），看所需人员的数量变化（比如100->90) 39 | 40 | **从财务角度看** 41 | 对比方式： LLM基础设施搭建+推广+培训等成本，与降下来的人员成本做比对 42 | 43 | // TODO 还需增加角度并完善内容实验 44 | 45 | ### Prompt 工程是否有未来？ 46 | 47 | 在探讨工程是否有未来之前，我们先了解一下狭义和广义的 Prompt 工程。 48 | 49 | **狭义的 Prompt 工程**专注于 AI 领域的 Prompt 50 | 优化，即通过优化任务描述来提高自然语言处理模型的性能。典型的做法是将一个或多个任务转换为基于提示的数据集，并通过所谓的“基于提示的学习”来训练语言模型。这有助于训练大型语言模型 ( 51 | LLM)，使 AI 能更好地理解需求并完成专业任务。 52 | 53 | **广义的 Prompt 工程师**则是指针对 AI 模型编写 Prompt 的人，以获得更好的结果。他们需要找到合适的提示词，让 AI 54 | 发挥出最大潜力。这个角色可以分为两部分：面向大语言模型的工程师和面向落地应用的工程师。 55 | 56 | **从使用 AI 模型的角度看**。随着 AI 技术的发展和普及，对 AI 模型的需求可能会逐渐减弱。这是因为随着模型的不断优化，它们的理解能力和性能将不断提高，使得在许多情况下无需额外的 57 | Prompt 工程即可满足需求。然而，这并不意味着 Prompt 工程没有未来。相反，随着 AI 在越来越多的领域得到应用，Prompt 58 | 工程仍然可以为特定任务和领域提供有针对性的优化。 59 | 60 | **从工程侧的角度看**。大型公司可能需要一两位专家来指导开发人员进行 Prompt 工程。通过组织活动（如 hackathon），公司可以提高开发人员对 61 | Prompt 62 | 工程的意识，帮助他们结合 Prompt 开发应用，以实现工程化落地。尽管大部分开发人员可能还没有充分认识到 Prompt 63 | 工程的重要性，但随着时间的推移，这一情况有望得到改善。 64 | 65 | **结论** 66 | 67 | 综上所述，工程在狭义和广义上都有一定的未来。尽管随着 AI 技术的进步，使用 AI 模型的需求可能会逐渐减弱，但 Prompt 68 | 工程仍然可以为特定任务和领域提供有针对性的优化。此外，大型公司需要专家指导开发人员进行 Prompt 工程，提高他们的意识并实现工程化落地。因此，Prompt 69 | 工程在未来仍然具有一定的发展空间和潜力。 70 | 71 | 同时我们看到，很多企业的AI2.0起步都将从Prompt工程开始，不同行业不同的融入节奏下，会使得Prompt工程在未来很长一段时间内都很重要。 72 | 73 | ### Prompt 工程师会有未来吗？ 74 | 75 | 有，Prompt 工程师在未来会更像是一个 Prompt 教练、专家的角色，他们会帮助开发者更好地使用 Prompt。 76 | 77 | ### 什么时候考虑微调？ 78 | 79 | 微调（fine-tuning）通常是在已经预训练好的模型的基础上，使用特定的数据集进行进一步训练，以适应特定的任务或应用场景。通常情况下，微调会在以下情况下进行考虑： 80 | 81 | 1. 适应特定的任务或领域：预训练的模型通常是在大规模通用语料库上进行训练的，而在特定的任务或领域中，可能需要使用更具体的语言模式和领域知识。这时候，就需要使用微调的方式对模型进行进一步训练，以适应特定的任务或领域。 82 | 2. 数据集与预训练数据的差异较大：如果预训练的模型的训练数据与实际应用场景的数据差异较大，那么使用微调的方式可以更好地适应实际场景的数据分布，提高模型的性能。 83 | 3. 进一步提高模型的性能：在一些对模型性能要求较高的任务中，使用微调的方式可以进一步提高模型的性能，从而更好地满足实际应用需求。 84 | 85 | 然而，ChatGPT 总结的并不好，当你要考虑微调的时候，你应该考虑的是： 86 | 87 | 1. ROI。微调的成本是很高的 —— 准备数据、训练模型、调参、部署，并进行持续的模型优化。 88 | 2. 好的基础模型。如果你的基础模型不够好，微调也不会有很好的效果。诸如于 LLaMA 7B 的中文效果不好。 89 | 3. 工程能力。微调的过程中，你需要有很好的工程能力，包括数据处理、模型训练、模型部署等等。 90 | 91 | 除此，在你没有思考清楚上述三点的时候，你不应该考虑微调。 92 | 93 | ### 个人的策略？ 94 | 95 | 对于我来说，我的 AI 策略大致是： 96 | 97 | 1. 拥抱变化，尽管人工智能并不能完全代替人类，但它已经能够大大提高效率。 98 | 2. 强化构架能力，因为人工智能工具无法代替个人的感性思考和直觉。 99 | 3. 构建领域小模型，可以快速训练出一个专门用于解决自己问题的小型模型。 100 | 4. 探索与磨炼技巧，探索 AI 能力并持续构建小工具，来修复和完善自己的 AI 增强系统。 101 | 102 | 对于修复与完善来说，由于 AI 本身是无法达到这么精细的，所以我的想法是**持续构建小工具**。 103 | -------------------------------------------------------------------------------- /src/patterns-prompt.md: -------------------------------------------------------------------------------- 1 | # Prompt 编写模式 2 | -------------------------------------------------------------------------------- /src/prelude.md: -------------------------------------------------------------------------------- 1 | # 构筑大语言模型应用：应用开发与架构设计 2 | 3 | 2023 年的上半年里，我（@phodal）和 Thoughtworks 4 | 的同事们（如：@[tianweiliu](https://github.com/tianweiliu)、@[teobler](https://github.com/teobler)、@[mutoe](https://github.com/mutoe) 5 | 等）、 6 | 开源社区的同伴们（如： 7 | 卷王@[CGQAQ](https://github.com/CGQAQ)、@[genffy](https://github.com/genffy)、 @[liruifengv](https://github.com/liruifengv) 8 | 等) 9 | 一起，创建了一系列的流行的或者不流行的开源项目。它们涉及了： 10 | 11 | - LLM 能力的充分运用 12 | - Prompt 编写：Prompt 学习与编写模式 13 | - Prompt 管理：Prompt 即代码 14 | - LLM 下的软件开发工序及应用架构设计 15 | - 新的交互设计：Chat模式 16 | - 大模型友好的工序：基于 AI 2.0 （ChatGPT + Copilot）如何去设计软件开发流程 17 | - LLM 应用架构的设计与落地：Unit Mesh 18 | - 面向特定场景的 LLM 应用 19 | - 基于开源模型构建自己的模型：特定场景的模型微调 + LLMOps 20 | - 上下文工程（prompt 工程）：LLM 应用的核心 21 | 22 | 围绕于上述的一系列内容，我们也在思考软件开发能给我们带来了什么。所以，我重新整理了过去半年的一些思考、文章，重新编写了这本开源电子书，希望能够帮助到大家。 23 | 24 | 关注我的微信公众号（搜索 phodal-weixin），获得更多及时的更新： 25 | 26 | ![微信公众号](images/qrcode.jpg) 27 | 28 | 加入微信群一起讨论 29 | 30 | ![微信群](images/wechat-group.jpg) 31 | 32 | （如果微信群已满，请添加: `phodal02` 为好友，并注明：AIGC） 33 | 34 | 我们发起的相关开源项目如下（包括但是不限于）： 35 | 36 | | 名称 | 描述 | 类型 | Stars | 37 | |----------------------------------------------------------------------------|------------------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------| 38 | | [理解 Prompt](https://github.com/prompt-engineering/understand-prompt) | 基于编程、绘画、写作的 AI 探索与总结。 | 文档 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/understand-prompt) | 39 | | [Prompt 编写模式](https://github.com/prompt-engineering/prompt-patterns) | 如何将思维框架赋予机器，以设计模式的形式来思考 prompt。 | 文档 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/prompt-patterns) | 40 | | [ClickPrompt](https://github.com/prompt-engineering/click-prompt) | 用于一键轻松查看、分享和执行您的 Prompt。 | 应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/click-prompt) | 41 | | [ChatVisualNovel](https://github.com/prompt-engineering/chat-visual-novel) | 基于 ChatGPT 的定制化视觉小说引擎 | 应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/chat-visual-novel) | 42 | | [ChatFlow](https://github.com/prompt-engineering/chat-flow) | 打造个性化 ChatGPT 流程，构建自动化之路。 | 框架 | ![GitHub Repo stars](https://img.shields.io/github/stars/prompt-engineering/chat-flow) | 43 | | [Unit Mesh](https://github.com/unit-mesh/unit-mesh) | 基于 AI 为核心的软件 2.0 思想的软件架构。 | 架构 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-mesh) | 44 | | [Unit Minions](https://github.com/unit-mesh/unit-minions) | AI 研发提效研究：自己动手训练 LoRA | 微调教程、指南、数据集 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-minions) | 45 | | [Unit Runtime](https://github.com/unit-mesh/unit-runtime) | 一个 ChatGPT 等 AI 代码的运行环境，可一键启动并实时交互，帮助您快速构建和测试 AI 代码。 | 基础设施 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/unit-runtime) | 46 | | [DevTi](https://github.com/unit-mesh/devti) | 基于 LLM 的微调来提供全面智能化解决方案，助力开发人员高效完成开发任务，以实现自动化用户任务拆解、用户故事生成、自动化代码生成、自动化测试生成等等。 | 微调代码 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/devti) | 47 | | [AutoDev](https://github.com/unit-mesh/auto-dev) | 一款 Intellij IDEA 的 LLM/AI 辅助编程插件。AutoDev 能够与您的需求管理系统（例如 Jira、Trello、Github Issue 等）直接对接。 | IDEA 插件 | ![GitHub Repo stars](https://img.shields.io/github/stars/unit-mesh/auto-dev) | 48 | | [ArchGuard Co-mate](https://github.com/archguard/co-mate) | 基于人工智能技术的架构副驾驶、设计和治理工具 | 架构协同应用 | ![GitHub Repo stars](https://img.shields.io/github/stars/archguard/co-mate) | 49 | 50 | 我们在 QCon 51 | 上的演讲：[演讲：探索软件开发新工序：LLM 赋能研发效能提升](https://qcon.infoq.cn/2023/guangzhou/presentation/5319) 52 | 53 | > LLM（如 ChatGPT + GitHub 54 | > Copilot）作为一种创新的工具组合，为我们带来了全新的机遇。它能够帮助业务人员和开发者在需求、架构、编码、测试等环节提高效率和质量，实现从设计到验证的端到端流程。在本次分享中，我将向大家介绍 55 | > LLM 在研发效能方面的应用场景和实践案例，展示它是如何在各个环节中发挥作用的。同时，我们还将分享如何构建私有化的 LLM 56 | > 工程化方式，使其更好地适应组织的需求。欢迎对 LLM + 研发效能感兴趣的朋友们参加本次分享，与我们一起探讨研发效能的未来。 57 | 58 | 我们在 Bilibili 上的大语言模型微调相关的视频： 59 | 60 | - LLaMA 61 | 系列在线视频： 《[代码辅助生成](https://www.bilibili.com/video/BV1Rh411u74H/)》 、《[测试代码生成](https://www.bilibili.com/video/BV1jg4y1G7Xc/)》 、《[详细需求生成](https://www.bilibili.com/video/BV1Us4y1N7rd/)》 、《[文本转 SQL](https://www.bilibili.com/video/BV1uv4y1H7bg/)》 62 | - ChatGLM 系列在线视频： 《[LoRA 大比拼：ChatGLM vs LLaMA，谁更会写需求文档？](https://www.bilibili.com/video/BV1fv4y1n7Y3/)》 63 | 64 | 欢迎大家一起来参与我们的开源项目，一起来探索 LLM + 软件开发的未来。 65 | 66 | -------------------------------------------------------------------------------- /src/prompt-as-code.md: -------------------------------------------------------------------------------- 1 | # Prompt 即代码：设计和管理 AI 编程的最佳实践 2 | 3 | > Prompt 即代码是一种基于多种输入模态的编程范式，它通过结合文本、图像、语音等多种输入方式来提供更丰富的上下文信息，帮助程序员更好地表达自己的意图，并生成相应的代码实现。Prompt 即代码将 prompt 作为代码的一部分，以及作为标准接口来定义生成的代码，同时提供注释和文档信息以支持可读性和可维护性。通过使用 prompt 即代码，程序员可以提高编码效率，同时生成更准确、更可靠的代码实现。 4 | 5 | 在不考虑采用诸如 Unit Mesh 新架构的情况下，我们需要在现有的架构和工程体系中融入 AI 编程。因此在这篇文章里，我们将回到现在 —— 此时此该，我们应该如何与 AI 编程共处，让 AI 成为我们的 Copliot。 6 | 7 | ## 引子 1：一年的 GitHub Copilot 感受：20% 的效率提升 8 | 9 | 相关的例子可以见： [https://www.clickprompt.org/zh-CN/github-copilot-samples/](https://www.clickprompt.org/zh-CN/github-copilot-samples/) 10 | 11 | 自打 GitHub Copilot 正式发布以后，作为知名的开源挖坑作者，拿到了免费的版本，但是只能偷偷使用。**公司明令禁止**我们在公司项目使用，所以只能在业余项目、开源项目中用用。 12 | 13 | 从个人的使用体验来说，AI 大概提升了我 20% 的编码效率 —— 大抵是我写的代码都比较偏门。但是怎么说呢，**抄、fork、生成** 的代码质量都 TM 的不行（有可能我是 Clean Code 的忠粉），所以 ，我经常吐槽说，你在垃圾库里是训练不出好的模型的。 14 | 15 | 所以，简单来说，对于效率提升是大大的，如果是 CRUD 效率更高，但是质量不行。反正，以后重写速度比重构更快，代码质量不重要（手动狗头）。 16 | 17 | 除此，从个人的感受来说，编写 Copilot 所需要的 Prompt 是需要学习门槛的。 18 | 19 | ## 引子 2：AI 编程的门槛 20 | 21 | 回到真实世界，我们要用好 AI 编码，需要考虑这个问题？ 22 | 23 | ### 问题 1：AI 编程能取代人类编程吗？ 24 | 25 | 不论是 GPT-4 发布会的 Demo，还是令大家惊艳的 [Cursor.so](http://Cursor.so) 开发工具。就当前的 GPT 能力而言，谈编程消失还太早了。GPT 只是一个复读机，解决不了任何复杂的编程问题。复杂场景下，GPT 容易丢失部分条件，需要由人来作这好 Tasking 的过程。 26 | 27 | 在条件不充分的情况，你可以轻松让 AI 生成一个页面、一个函数，但是他无法达到你想要的结果。所以在，Unit Mesh 架构下，一部分程序员成为了 **AI 代码验证师 + AI 代码修复师**，它将持续非常很长一段时间。 28 | 29 | ### 问题 2：编程只是在编码？ 30 | 31 | 当前的 AI 编程只是取代你的转译过程：需求细分、转换需求成代码等。你可以看看你的提交历史：一天提交了几行代码，又是哪个时间提交的。有可能你算下来了，白天都在开会，只有晚上写代码。我记得知乎有一个相关的问题，大部分人的回答都是平均**几十行、几百行**。当然按行数是不科学的，成长期的项目的行数是远大于维护期的。 32 | 33 | 所以，如果你的编码时间很长，而架构设计、需求讨论等的时间很短，可能得考虑一下职业生涯，强化你的设计、拆解能力。毕竟，一旦效率提高的，还是有些程序员会失业的。 34 | 35 | ### 问题 3：人人都会写好的 Prompt？ 36 | 37 | 身处于各类可访问 ChatGPT 的微信群中，遇到很多问题的时候，我经常会抛出一句：”问 ChatGPT 啊“。很多人并不会真正意识到 ChatGPT 是一个工具，唯一的乐趣可能就是：”请帮我生成一个 KFC v50 的故事“。 38 | 39 | 这也是我们创建 ClickPrompt、ChatFlow、PromptPatterns 等项目的初衷，大部分人需要先意识到 AI 能做什么。然后，才是如何写好 Prompt，我们要摸摸我们的 Copilot 的脾气，然后再一起干活。诸如于： 40 | 41 | - 函数名直接生成代码。 42 | - 函数名 + 处理步骤生成代码。 43 | 44 | 每种模式的背后，都很有意思。 45 | 46 | ## Prompt 即代码：一个新的规范 —— Prompt 编写规范 47 | 48 | 在进一步展开 Prompt 即代码之前，我们需要先了解一下如何写好 Prompt。如下是，我之前放在 ClickPrompt 上面的一部分 GitHub Copilot 示例。 49 | 50 | 从我的理解来说，一个好的 Prompt 规范应该包括以下内容： 51 | 52 | 1. 功能定义：定义所需的功能，并为模型提供足够的上下文和信息。这可以帮助模型更好地理解其意图并生成相应的代码。示例 1：函数名、输入和输出，就能自动填充。 53 | 2. 任务拆分：将任务拆分为小的子任务，并确保每个子任务的要求和期望输出都非常清晰。示例 2：如上图的按步骤设计示例，每一步都需要想好要怎么做。 54 | 3. 确定输入与输出格式：Prompt 规范应该明确输入与输出格式和数据类型，以便模型可以正确地处理输入。示例 3：我们添加了 i18n 的 json 过来，让 Copilot 自动映射。 55 | 4. 测试和调试：在生成代码之后，应该进行测试和调试，以确保其正确性和可靠性。同时，应该为模型提供反馈，以帮助它改进其生成的代码。示例：让 Copilot 编写对应的单元测试，我们对测试用例进行检查。 56 | 5. 避免歧义：Prompt 规范应该避免使用歧义的语言和术语，并确保在多种上下文中生成的代码是一致的。只在出错时，我们才会发现这条原则是有用的。 57 | 6. 编码标准：定义编码标准，并确保生成的代码符合这些标准。这可以确保生成的代码易于阅读和维护，并符合团队的编码惯例。这个就需要我们团队去做了。 58 | 59 | 看上去有没有像极你平时写的伪代码，作为一个伪代码工程师的你，是不是发现生产力可能爆炸了。 60 | 61 | ## Prompt 即代码：不同形态下的 AI 编程 62 | 63 | 再重复一下定义： 64 | 65 | > Prompt 即代码是一种基于多种输入模态的编程范式，它通过结合文本、图像、语音等多种输入方式来提供更丰富的上下文信息，帮助程序员更好地表达自己的意图，并生成相应的代码实现。Prompt 即代码将 prompt 作为代码的一部分，以及作为标准接口来定义生成的代码，同时提供注释和文档信息以支持可读性和可维护性。通过使用 prompt 即代码，程序员可以提高编码效率，同时生成更准确、更可靠的代码实现。 66 | > 67 | 68 | 当谈到 Prompt 即代码时，我们通常会将其定义为一种编程范式，它将自然语言或其他形式的输入作为代码生成的起点。Prompt 即代码则让程序员通过提供高度概括的自然语言描述或其他形式的输入来描述他们想要的功能，然后由 AI 系统自动生成代码。 69 | 70 | 所以，在这里我们分为两种方式：标准的 Prompt 即代码、多模态的 Prompt 即代码。 71 | 72 | ### 标准的 Prompt 即代码：文本形式 73 | 74 | > 文本 Prompt 即代码是指使用自然语言或其他方式描述需求或问题，通过 AI 模型自动生成对应的代码。Prompt 作为代码的一部分或者核心，通过描述期望的输入和输出，以及需要执行的操作来生成代码。 75 | > 76 | 77 | 尽管现有的 AI 工具都是多模态的，然而自然语言是作为中间语言存在的。所以，我想将文本形式的 prompt 称为**标准的 Prompt 即代码**，它可以方便地融入现有的编程体系。 78 | 79 | - Prompt 即注释。Prompt 作为注释与代码并存，在这种情况下，Prompt 与代码共存于同一个文件中。通常，Prompt 以注释的形式出现在代码中，以提供必要的上下文信息和生成代码的指令。这种方式适合于需要经常手动修改生成的代码的场景。 80 | - Prompt 即接口。在这种情况下，Prompt 作为一个标准的接口，代码则是实现这个接口的生成代码。这种方式适用于对生成的代码进行自动化测试和部署的场景，因为接口定义的一致性可以更好地保证代码的正确性。 81 | - Prompt 即代码。在这种情况下，版本管理工具中不再存储代码，而是存储 Prompt。生成的代码则可以根据 Prompt 来生成，Prompt 作为代码的一部分。这种方式适合于需要频繁更新代码和对代码进行版本控制的场景。 82 | 83 | 而，事实上，在我第一次将注释加入到 ClickPrompt 中的时候，我犹豫了很久。我们的过去的编程习惯，并不允许将思考过程作为注释到其中。 84 | 85 | 既然，它已经作为代码的一部分加入进来 ，我们还需要进一步考虑的点是：**尽可能地去修改 prompt 重新生成代码，减少直接修改 prompt**。 86 | 87 | ### 多模态 Prompt 即代码 88 | 89 | PS：**感谢 ChatGPT 帮我考虑了这一部分**。 90 | 91 | > 多模态 Prompt 即代码是指在训练 AI 模型时，同时利用多种不同的输入模式（如文本、图像和语音）来提供更丰富的上下文，以帮助模型更好地理解程序员的意图并生成相应的代码。通过使用多模态 Prompt，AI 模型可以获得更多的信息，并在生成代码时更准确地反映程序员的意图。 92 | > 93 | 94 | 例如，一个基于多模态 Prompt 训练的 AI 模型，可以同时考虑程序员在文本上下文中输入的代码片段，代码所处的项目信息、数据结构信息，以及程序员所提供的图像信息，如示意图、流程图等，从而生成更准确、更完整的代码。 95 | 96 | PS：不过，这种技术需要大量的数据和计算资源，同时需要对不同的输入模式进行处理和整合，因此在实际应用中还需要进一步研究和优化。 97 | 98 | ## Prompt 即代码：交互方式的变化 99 | 100 | 过去的几个月里，每天层出不穷的 AI 新工具，都在让我们感受人类的智商上限和 AI 的下限。与现在的编程方式相比，未来几个月势必会出现新的、或者已经出现新的交互方式。 101 | 102 | 诸如于： 103 | 104 | - 交互式 Prompt：在编写代码的过程中，模型可以提示程序员输入，从而帮助模型更好地理解程序员的意图，并生成更准确的代码。例如，Unit Mesh 采用的架构模式，便是由人类和 AI 共同完成的，并由 Unit Server 自动化部署。 105 | - 面向场景的 Prompt：通过提供与特定场景相关的信息和上下文，可以帮助模型更好地理解程序员的意图并生成相应的代码。例如，面向 Web 开发的 Prompt 可能包括与 HTML、CSS 和 JavaScript 相关的信息和上下文。 106 | - 等等。 107 | 108 | Prompt 即代码的交互方式将会越来越多样化和智能化，以更好地满足程序员在不同领域和场景下的需求。 109 | -------------------------------------------------------------------------------- /src/prompt-template.md: -------------------------------------------------------------------------------- 1 | ## Prompt Patterns 模板 2 | 3 | 回忆一下我们的高考作文题： 4 | 5 | ```markdown 6 | 阅读下面的材料，根据要求写作。（60分） 7 | 8 | 　　人们因技术发展得以更好地掌控时间，但也有人因此成了时间的仆人。 9 | 10 | 　　这句话引发了你怎样的联想与思考？请写一篇文章。 11 | 12 | 要求：选准角度，确定立意，明确文体，自拟标题；不要套作，不得抄袭；不得泄露个人信息；不少于800字。 13 | ``` 14 | 15 | 这部分的文字非常易于我们理解，它由以下几部分构成： 16 | 17 | - 指令（Instruction）：阅读下面的材料，根据要求写作。 18 | - 要求（Requirements）：选准角度，确定立意，明确文体，自拟标题；不要套作，不得抄袭；不得泄露个人信息；不少于800字。 19 | - 素材：人们因技术发展得以更好地掌控时间，但也有人因此成了时间的仆人。 20 | 21 | ### Prompt 编写模板 22 | 23 | 通常来说，一个易于 LLM 理解的模板可以由以为几部分构成： 24 | 25 | - 角色（Role）：解释这个模板的使用场景和目的。 26 | - 指令（Instruction）：告诉 GPT-3.5 执行的具体任务或要求。 27 | - 要求（Requirements）：对 GPT-3.5 生成的结果的期望和要求，例如长度、主题、语言风格等。 28 | - 示例（Sample）：提供一个或多个示例，以便 GPT-3.5 理解任务的上下文和生成的结果的期望。 29 | - 扩展数据（Extended Data）(可选，编程时需要）：提供一些额外的数据，例如词汇、语法结构、语言模型等，以帮助 GPT-3.5 生成更加丰富、准确的结果。 30 | 31 | 一个简单的示例如下： 32 | 33 | > 角色（Role）：你是一位旅游公司的营销人员，需要撰写一篇旅游目的地介绍的文本。 34 | 35 | > 指令（Instruction）：请使用 GPT-3.5 生成一篇介绍文本，其中包括目的地的名称、位置、历史和文化背景、景点、美食、住宿和交通等相关信息。 36 | 37 | > 要求（Requirements）：生成的文本长度应为 500-1000 个单词，语言风格应为正式、客观、流畅，包含准确的地理、历史和文化知识。 38 | 39 | > 示例（Sample）：请以以下地点为例，生成一篇介绍文本：福建漳州。 40 | 41 | > 扩展数据（Extended Data）：可以提供一些关于福建、漳州的历史、文化、地理等方面的数据，以帮助 GPT-3.5 生成更加准确、详细的文本。 42 | 43 | 输出示例： 44 | 45 | > 漳州，位于福建省东南沿海，是一个具有悠久历史和丰富文化的城市。作为福建省的一个重要城市，漳州拥有独特的地理位置和文化底蕴，是一个备受游客青睐的旅游目的地。 46 | 47 | > 漳州的历史可以追溯到公元前三千年左右的新石器时代，是中国历史上一个非常重要的文化和商业中心。在宋、元、明、清等历史时期，漳州都是一个繁荣的商贸城市，曾经是丝绸之路的海上起点之一。在漳州，游客可以看到许多保留完好的历史遗迹，如南靖土楼、东山古城等。 48 | 49 | > 漳州的文化底蕴非常深厚，它是闽南文化的代表之一。在漳州，游客可以领略到许多独特的文化风情，如闽南建筑、福建茶文化、福建南音等。此外，漳州还是福建省的一个重要的宗教中心，拥有众多的寺庙和教堂，如南山寺、开元寺等。 50 | 51 | > 漳州拥有许多著名的景点，如南靖土楼、天柱山、东山古城、南山寺等。其中，南靖土楼是漳州最著名的景点之一，它是闽南土楼的代表之一，被誉为“中国传统建筑艺术的瑰宝”。天柱山是漳州的一个自然保护区，拥有丰富的自然景观和独特的生态环境，是一个极具观赏价值的景点。 52 | 53 | > 漳州的美食也非常有名，如海鲜、福建菜等。漳州的海鲜非常新鲜，口感鲜美，深受游客的喜爱。福建菜是中国八大菜系之一，以其独特的口味和烹饪方法而著名。 54 | 55 | > 对于住宿和交通，漳州也有很好的配套设施。漳州有许多高档酒店和旅游胜地，如漳州嘉禾智选假日酒店、漳浦金海岸度假酒店等。此外，漳州还有许多交通工具，如高速公路、铁路、机场等，方便游客前往。 56 | 57 | > 总之，漳州是一个迷人的旅游目的地，拥有丰富的历史和文化底蕴、独特的景点、美味的美食、高品质的住宿和交通，是一个值得游客来此一游的好地方。 58 | 59 | 当然了，GPT 是生成式的，所以在这时往往没有根据 "事实" 来生成内容，所以需要你添加一些额外的数据，以帮助 GPT 生成更加丰富、准确的结果。 60 | 61 | 除此，我们并不一定要按照这个模板来定义 Prompt，只要能够清晰地表达出上述几个要素即可。 62 | 63 | ### Kotlin 代码实现示例 64 | 65 | 在 ArchGuard Co-mate 中，我们通过如下的 Kotlin 代码来实现 Prompt 模板的定义： 66 | 67 | ```kotlin 68 | interface BaseTemplate { 69 | fun getRole(): String = "" 70 | fun getInstruction(): String = "" 71 | fun getRequirements(): String = "" 72 | fun getSample(): String = "" 73 | fun getExtendData(): String = "" 74 | } 75 | ``` 76 | 77 | 对应的一个实现示例： 78 | 79 | ```kotlin 80 | class LayeredStylePrompt( 81 | val context: ComateContext, 82 | override val strategy: Strategy, 83 | ) : CodePromptStrategy { 84 | override fun getRole(): String = "Software Architecture" 85 | override fun getInstruction(): String = 86 | "根据下面的信息，分析项目的分层是否符合业内的通用规范？并绘制 Graphviz 图来表示。" 87 | 88 | override fun getRequirements(): String = """ 89 | 1. 如果存在相互引用，请用红线展示出来。 90 | 2. 只展示重要的分层，不要展示过多的细节。 91 | 4. 结合分层、subgraph 的方式来表示分层。 92 | 4. 示例如下： 93 | 94 | ### 95 | digraph G { 96 | rankdir=TB; 97 | node [shape=record, fontname=Helvetica]; 98 | edge [color=black, penwidth=1.0]; 99 | subgraph cluster_{} { 100 | label="{} Layer" 101 | } 102 | ### 103 | """ 104 | 105 | override fun getExtendData(): String { 106 | val introduction = context.fetchReadmeIntroduction() 107 | return """$introduction 108 | 109 | package fan in: ${context.fetchPackageDependencies()} 110 | """ 111 | .trimIndent() 112 | 113 | } 114 | 115 | } 116 | ``` 117 | 118 | 输出结果示例： 119 | 120 | ```markdown 121 | You're an Software Architecture,根据下面的信息，分析项目的分层是否符合业内的通用规范？并绘制 Graphviz 图来表示。Here is requirements: 122 | 1. 如果存在相互引用，请用红线展示出来。 123 | 2. 只展示重要的分层，不要展示过多的细节。 124 | 4. 结合分层、subgraph 的方式来表示分层。 125 | 4. 示例如下： 126 | 127 | ```dot 128 | digraph G { 129 | rankdir=TB; 130 | node [shape=record, fontname=Helvetica]; 131 | edge [color=black, penwidth=1.0]; 132 | subgraph cluster_{} { 133 | label="{} Layer" 134 | } 135 | ``` 136 | 137 | Project introduction: Co-mate is an AI-powered software architecture copilot, design and governance tools. 138 | 139 | package fan in: {org.archguard.architecture=[org.archguard.architecture.layered], org.archguard.comate.cli... 140 | ``` 141 | --------------------------------------------------------------------------------