A thousand miles begins with a single step .
本页介绍如何使用底层 LLM API 进行响应流式传输。如需高层级 LLM API，请参阅 AI Services。
LLM 逐 token 生成文本，因此许多 LLM 提供商提供了按 token 流式传输响应的方式，而无需等待整个文本生成完毕。这显著改善了用户体验，因为用户无需等待未知时长的处理时间，几乎可以立即开始阅读响应内容。
ChatModel 和 LanguageModel 接口分别对应 StreamingChatModel 和 StreamingLanguageModel 接口。它们具有相似的 API支持流式传输响应。这些接口接受一个 StreamingChatResponseHandler 接口的实现作为参数。
RAG 流程分为两个截然不同的阶段：索引阶段和检索阶段，LangChain4j 为两个阶段都提供了工具支持。
在索引阶段，文档会被预处理，以便在检索阶段实现高效搜索。这个过程会根据所使用的信息检索方法而有所不同。对于向量搜索，通常包括：清洗文档、用额外数据和元数据丰富文档、将文档分割成更小的片段（即分块）、对这些片段进行嵌入编码，最后将它们存储到嵌入存储（即向量数据库）中。
索引阶段通常发生在离线状态下，这意味着不需要终端用户等待其完成。例如，可以通过 cron 定时任务在周末每周一次重新索引公司内部文档。负责索引的代码也可以是一个单独的应用程序，仅处理索引任务。然而，在某些场景下，终端用户可能希望上传自定义文档以使其可被 LLM 访问。在这种情况下，索引应在在线状态下执行，并作为主应用程序的一部分。
以下是索引阶段的简化示意图：
1 | 文档 → 清洗/丰富 → 分块 → 嵌入 → 嵌入存储（向量数据库） |
一些大语言模型（LLM）除了生成文本之外，还可以触发动作。这个被称为”工具”或”函数调用”的概念，它允许 LLM 在必要时调用一个或多个通常由开发者定义的可用工具。工具可以是任何东西：网络搜索、调用外部 API，或执行特定的代码片段等。LLM 实际上不能自己调用工具，相反，它们在响应中表达调用特定工具的意图（而不是以纯文本形式响应）。
所有支持工具的 LLM 可以在此处找到（参见”Tools”列）。
并非所有 LLM 对工具的支持程度都一样，理解、选择并正确使用工具的能力在很大程度上取决于具体的模型和它的能力。有些模型可能完全不支持工具，而另一些则可能需要精心设计的提示词或额外的系统指令。
LangChain4j 为使用工具提供了两个抽象层级：ChatModel级别和AI—Services级别。
许多 LLM 和 LLM 提供商支持以结构化格式（通常是 JSON）生成输出。这些输出可以轻松映射到 Java 对象，并在应用程序的其他部分使用。
例如，假设我们有一个 Person 类：
1 | record Person(String name, int age, double height, boolean married) { |
我们的目标是像下面这样的非结构化文本中提取 Person 对象：
John is 42 years old and lives an independent life.
He stands 1.75 meters tall and carries himself with confidence.
Currently unmarried, he enjoys the freedom to focus on his personal goals and interests.
目前，根据 LLM 和 LLM 提供商的不同，有三种方式可以实现这一目标（从最可靠到最不可靠）：
因为ChatModel、ChatMessage、ChatMemory 等底层组件工作非常灵活，但也正式由于给予的这些自由，迫使开发者需要编写大量的样板代码。而由于 LLM 驱动的应用程序通常需要多个组件协同工作（例如提示模板、聊天记忆、LLM、输出解析器、RAG 组件：嵌入模型和存储），并且通常涉及多次交互，协调所有这些组件变得更加繁琐。故LangChain4j 目前提供了两个高级概念来解决这个问题：AI 服务（AI Services） 和 链（Chains），以便于开发者能专注于业务逻辑而不是底层细节。
链的概念源于 Python 版的 LangChain，其理念是为每个常见用例提供一个 Chain，例如聊天机器人、RAG 等。链将多个底层组件组合起来，并协调它们之间的交互。链的主要问题在于，如果你需要自定义某些内容，它们过于僵化，所以LangChain4j 目前只实现了两个链（ConversationalChain 和 ConversationalRetrievalChain），并不计划添加更多。
为了维护和管理 ChatMessage ，LangChain4j 提供了 ChatMemory 抽象以及多种开箱即用的实现，。ChatMemory 既可以作为独立底层组件使用，也可以作为高级组件（如 AI Services）的一部分。
ChatMemory 充当 ChatMessage 的容器（底层由 List 支持），并附带以下功能：
翻译自官方文档：https://modelcontextprotocol.io/docs/learn/architecture
本模型上下文协议 (MCP) 概述讨论了其范围和核心概念，并提供了一个示例来演示每个核心概念。由于 MCP SDK 抽象掉了许多细节，大多数开发者可能会发现数据层协议部分最有用。它讨论了 MCP 服务器如何向 AI 应用程序提供上下文。有关具体的实现细节，请参考您所用编程语言的 SDK的文档。
模型上下文协议包括以下方面：
MCP 仅关注上下文交换的协议——它并不规定 AI 应用程序如何使用 LLM 或管理所提供的上下文。
翻译自官方文档：https://modelcontextprotocol.io/docs/getting-started/intro
模型上下文协议 (MCP) 是一个用于将 AI 应用连接到外部系统的开放协议标准。
通过 MCP，像 Claude 或 ChatGPT 这样的 AI 应用可以连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流（例如专用提示）——使它们能够访问关键信息并执行任务。
可以把 MCP 想象成 AI 应用的 USB-C 接口。正如 USB-C 为电子设备提供标准化的连接方式一样，MCP 为 AI 应用与外部系统的连接提供了标准化方式。