本文描述了底层的大语言模型（LLM）API。高级的LLM API参见AI服务。
1 LLM API的类型
1.1 LanguageModel
非常简单—，接受一个String作为输入，并返回一个String作为输出。
该API现正逐渐被聊天API（第二种API类型）取代。
1.2 ChatLanguageModel
这种API接受一或多个ChatMessage作为输入，并返回一个AiMessage作为输出。 ChatMessage通常包含文本，但有些LLM还支持混合文本和Image的输入。如OpenAI的gpt-4o-mini和Google的gemini-1.5-pro都属于这种。
LangChain4j中，将不再扩展对LanguageModel的支持，因此所有新功能采用ChatLanguageModel API。
ChatLanguageModel是LangChain4j中的底层API，提供了最大的功能和灵活性。还有高级API（如Chain和AiServices）。
除了ChatLanguageModel和LanguageModel，LangChain4j还支持以下类型的模型：
EmbeddingModel：可将文本转换为EmbeddingImageModel：可生成和编辑Image。ModerationModel：可检查文本中是否包含有害内容。ScoringModel：可根据查询对多段文本进行评分（或排名），以确定每段文本与查询的相关性。这在RAG（检索增强生成）中非常有用。
2 ChatLanguageModel API
public interface ChatLanguageModel {
String generate(String userMessage);
...
}
generate接受一个String作为输入并返回一个String作为输出，类似LanguageModel。这是一个便捷方法，可快速使用它，无需将String包装在UserMessage中。
但这才是实际的聊天API：
...
Response<AiMessage> generate(ChatMessage... messages);
Response<AiMessage> generate(List<ChatMessage> messages);
...
这些generate接受一或多个ChatMessage作为输入。ChatMessage是一个表示聊天消息的基础接口。
3 ChatMessage的类型
目前有四种聊天消息类型，每种消息对应不同的“来源”：
UserMessage：这是来自用户的消息。用户可以是您的应用程序的最终用户（人类）或应用程序本身。
根据LLM支持的模态，UserMessage可以包含仅文本（String）或文本和/或图像（Image）。AiMessage：AI生成的消息，通常是对UserMessage的响应。 如你所见，generate返回一个包含在Response中的AiMessage。AiMessage可包含文本响应（String）或请求执行工具（ToolExecutionRequest）。ToolExecutionResultMessage：ToolExecutionRequest的结果SystemMessage：系统的消息。通常，作为开发者应定义此消息的内容。可在此编写关于LLM在对话中的角色、应如何表现、以何种风格回答等指令。 LLM被训练得更关注SystemMessage，因此要小心，最好不要让最终用户随意定义或注入一些输入到SystemMessage中。 它通常位于对话的开始。
如何在对话中组合它们？
最简单的场景，可在generate方法中提供一个UserMessage实例。 这与第一个版本的generate方法类似，它接受一个String作为输入。 主要区别在于它现在返回的不是String，而是Response<AiMessage>。
Response是一个包装了内容（负载）的对象，经常看到它作为*Model类的返回类型。 除了内容（在这种情况下是AiMessage），Response还包含生成的元信息：
TokenUsage，统计了输入（提供给generate方法的所有ChatMessage）中包含的token数及输出（AiMessage）中生成的token数，并给出总数（输入 + 输出）。需要这些信息来计算每次调用LLM的成本FinishReason，枚举类型，表示生成停止的各种原因。通常，如果LLM自行决定停止生成，则原因会是FinishReason.STOP
创建UserMessage
有多种方式，取决于内容。最简单的new UserMessage(“Hi”)或UserMessage.from(“Hi”)`。
4 多个ChatMessage
为啥要提供多个ChatMessage作为输入，而不仅是一个？ 因为LLM本质上是无状态的，这意味着它们不会维护对话的状态。 因此，如果你想支持多轮对话，则需要自己管理对话的状态。
假设想构建一个聊天机器人。想象一下用户和聊天机器人（AI）之间的简单多轮对话：
- 用户：你好，我叫JavaEdge
- AI：你好JavaEdge，我能帮你什么？
- 用户：我叫什么名字？
- AI：JavaEdge
这就是与ChatLanguageModel交互的样子：
UserMessage firstUserMessage = UserMessage.from("Hello, my name is JavaEdge");
AiMessage firstAiMessage = model.generate(firstUserMessage).content(); // JavaEdge，我能帮你什么？
UserMessage secondUserMessage = UserMessage.from("What is my name?");
AiMessage secondAiMessage = model.generate(firstUserMessage, firstAiMessage, secondUserMessage).content(); // JavaEdge
如你所见，在第二次调用generate方法时，不仅提供了secondUserMessage，还提供了对话中的前几条消息。
手动维护和管理这些消息比较繁琐，因此引入ChatMemory。
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
- 中央/分销预订系统性能优化
- 活动&券等营销中台建设
- 交易平台及数据中台等架构和开发设计
- 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
- LLM Agent应用开发
- 区块链应用开发
- 大数据开发挖掘经验
- 推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：