本文将介绍 Chocolate Factory 框架背后的一系列想法和思路。在我们探索和设计框架的过程中，受到了：LangChain4j、LangChain、LlamaIndex、Spring AI、Semantic Kernel、PromptFlow 的大量启发。

欢迎一起来探索：https://github.com/unit-mesh/chocolate-factory 。

在我们的参考架构里，框架/SDK 只是整体参考架构的一小部分。

为什么开发 JVM 语言的 LLM 开发框架

在过去的几个月里，我们一直在结合已有的 JVM 体系基础设施构建 LLM 应用。诸如于：

• 在 ArchGuard Co-mate 里，我们探索了架构 Copilot + Agent Tool （架构分析工具）的正确打开方式。
• 在 AI 辅助编程工具 AutoDev 中，我们给出了市面上最好的开源 IDE 插件的上下文构建模式 —— 构建复杂上下文（语言、框架、规范等）的 Prompt 策略，以及支持不同的大语言模型（除了市面上的大模型，还有内部的 MaaS 平台）。
• ……

这些尝试是围绕于我们过去的另外一个假设：当大模型成本降低，可靠性上升之后，AIGC 会与业务应用紧密结合。在这时，我们需要致力于：

• 开发结合 LLM 内部基础设施的 SDK
• 探索快速构建 RAG （检索增强）相关 PoC （概念证明）的方式
• 更友好的 prompt 开发与设计工具

简单来说，我们需要一些封装内部基础设施的框架、调试应用，以快速支撑 AI 应用的开发。

诸如于，我们在构建本地化代码搜索时，需要如下的工具：

dependencies {
  // 核心库
    implementation("cc.unitmesh:cocoa-core:0.3.4")
    // 代码拆分
    implementation("cc.unitmesh:code-splitter:0.3.4")
    // Elastisearch 向量化存储，普通搜索
    implementation("cc.unitmesh:store-elasticsearch:0.3.4")
    // 本地化的 embedding，用于每次更新代码，重新 embedding => CPU
    implementation("cc.unitmesh:sentence-transformers:0.3.4")
}

每个模块并不复杂，只是一些基本的 API 与基本的逻辑封装。但是，可以直接与现有的 AI 应用结合，再配套内部的 MaaS（模型即服务平台），就能快速在现有的业务中接入 LLM 能力。

起步：总结 LLM 应用所需要的能力

如先前的文档所说，我们将 LLM 优先的软件架构分为三类：。

• 通过简单的 prompt 来与大模型进行交互。
• 结合向量化（Embedding）的方式，来与大模型交互。
• 自动化规划的方式，基于 workflow 的方式。

在当前，我们优先关注于结合向量化，也就是大部分 RAG 场景下的交互。即基于特定的业务场景，分析用户的意图，自动提供相应的上下文，交由大模型来进行自动化分析。对于这三种类型来说，或者不同场景时，各自的关注度是不一样的。

• 与大模型的 API 交互。主要会由两部分组成，第一部分是：依赖于 MaaS 平台的标准的 LLM 接口模型封装；第二部分是：支持流式、自定义二次处理结果的交互 API。（第二部分其实是最难的）
• 文档向量化（Embedding）。主要会由三部分组成，第一部分是：支持不同格式文档的处理，及其拆分模式与策略的代码化设计；第二部分是：不同精度（出于成本考虑）需求的向量化模型接入；第三部分是：支持查询扩展的中间层与多种类型数据库检索，即结合向量数据库和传统数据库。
• 自动化规划（Flow + Agent）。尽管我们尝试去做更多相关的尝试，但是由于精力有限，并不能给出一个非常精确的结果。所以，在这里就暂时不展开这部分相关的内容。

开发一个框架与过去的东西差别不多。但是，有意思的一点是，由于我们构建的是一个框架，所以当看到新的 RAG 论文，第一反应就是能否交由框架来支持。

抽象：回顾 LLM 的数据处理

诸如于 LangChain、LlamaIndex 在这方面已经做了非常好的抽象，我们在设计的时候，参考（复制）了大量的相关思想。在 LlamaIndex 的文档上，已经给出了很好的抽象，在这里我们使用我们新开发的 RAGScript （可以直接运行）来表达相关的内容：

rag {
    indexing {
        val document = document("filename.text")
              val chunks = document.split()
        store.indexing(chunks)
    }

    querying {
        val results = store.findRelevant("Hello World").lowInMiddle()
        llm.completion {
            "// 结合 results 处理 prompt"
                }
    }
}

上面的代码段非常言简意赅的表达 RAG 的过程。简单来说，一个 RAG 分为 Indexing 和 Querying 两个阶段：

• 在 Indexing 阶段里，我们关注于如何将数据加工和分解（split），并注入到向量数据库中。
• 在 querying 阶段里，我们关注于如何加工检索完的数据，再结合 LLM 来处理

而现有的 LangChain、LlamaIndex 已经能提供我们很好的思路。唯一的挑战是，如何结合不同场景去探索合适的应用示例。

原型：从应用 PoC 中迭代抽象接口

在不同的 LLM 应用开发框架或者 LLM 数据处理引擎里，都有大量的基础设施支持。但是，由于我们的场景往往是多种多样的，所以有时候显得有些不足。诸如于：

• 本地化向量化（Emdeddbing）模型 SentenceTransformers 的引入，以降低代码向量化的成本。为此，我们需要引入 Onnx Runtime， 以在客户端或者服务端进行向量化操作。
• 更精准的代码切分。对于框架型代码逻辑解释而言，能提供 interface 等抽象类的拆分，保持类之间的继承关系，以及其它更精准的规则处理，明显会比通用的拆分规则更有实际意义。

同时，为了更好的开发框架，除了结合过往开发 LLM 应用的经验，还得思考一些新的场景作为试验田。诸如于：

• 交互式的 UI 代码辅助设计场景。
• 简单场景下的代码解释器。
• 基于文档的规范查询。
• 基于自然语言的语义化代码搜索。
• 长数据场景下的测试用例设计

每种场景之下，对于框架的支持要求是不一样的。对于简单的场景，应该直接由 core 模块来提供所有的能力；对于复杂的场景，需要提供基本的 workflow 支持，以实现快速的应用开发。

除此，在复杂的场景之后，大部分的数据需要经过二次处理，也就是：

• 实时返回模式。只用于向用户提供快速的反馈。诸如代码生成时，先返回代码；又或者是基于流式的 DSL 来响应数据。
• 结果二次处理。当模型返回所有的结果时，需要再处理。诸如于，执行用户的代码，以生成的图表。

而在某些场景，我们需要的是长等待时间，即等待所有的用户返回内容。而对于这种不能由框架支持的功能，则稍微显得麻烦一些，我们得考虑通过示例向用户呈现这个过程。

插曲：解释 RAG 实现的 RAGScript

在开发了基本的 Chocolate Factory 功能之后，为了更好的让其他同事参与进来。我们尝试编写一系列的文档和示例，以向其他人解释：如何开发一个基于 LLM 的 RAG 应用？

为此，我们基于已有的 API 能力，构建了 RAGScript，以快速向其他人解释完整的过程。完事的示例代码如下所示：

rag("code") {
    // 使用 OpenAI 作为 LLM 引擎
    llm = LlmConnector(LlmType.OpenAI)
    // 使用 SentenceTransformers 作为 Embedding 引擎
    embedding = EmbeddingEngine(EngineType.SentenceTransformers)
    // 使用 Memory 作为 Retriever
    store = Store(StoreType.Memory)

    indexing {
        // 从文件中读取文档
        val document = document("filename.txt")
        // 将文档切割成 chunk
        val chunks = document.split()
        // 建立索引
        store.indexing(chunks)
    }

    querying {
        // 进行相关性查询
                val revelant = store.findRelevant("Hello World")
        // 结合 Lost in the Middle 的长上下文重新排序
                val results = revelant.lowInMiddle()
        println(results)
    }
}

当然了，在我们的 RAG 示例中，还提供了代码语义化解释搜索的示例。详细见：https://framework.unitmesh.cc/docs/rag 。

Prompt 调试：LLM 的工程化开发难点

尽管我们开发的是模式二（Co-pilot 型应用）优先的 LLM 应用框架，但是在我们开发示例的过程中，我们依旧会发现对于 Prompt 的调试与编排是最大的挑战。

在 Chocolate Factory 的 DDD 思想的工作流中，我们推荐的实践是：

• Apache Velocity Engine 作为模板引擎
• 构建每个 Workflow 独立的 Context 环境，与变量 resolver。

然而，对于一个大型的组织来说，内部会存在不同的 LLM。对于不同的 LLM 而言，相应的 prompt 编写模式也是有差异的。所以，我们正在思考采用同 PromptFlow 相似的方式，即采用独立的模板文件，结合工作流编排，以适应不同模式的 promtp 差异。如下是 PromptFlow 的模板示例：

system:
You are a helpful assistant.

{% for item in chat_history %}
user:
{{item.inputs.question}}
assistant:
{{item.outputs.answer}}
{% endfor %}

user:
{{question}}

再结合 CLI 或者 IDE 可视化的方式进行探索。

总结

总的来说，这篇文章深入探讨了设计 JVM 语言的 LLM 应用开发框架的思考过程，强调了框架的多样性和复杂性，以及如何通过框架和工具来支持各种 LLM 应用场景。我们提供了有用的示例代码和抽象概念，有助于读者更好地理解和开发 LLM 应用。