AI 概念

本节介绍 Spring AI 所使用的核心概念。我们建议你仔细研读，以理解 Spring AI 实现背后的理念。

模型

AI 模型是用于处理和生成信息的算法，往往模仿人类的认知功能。 通过从海量数据集中学习模式与洞见，这些模型能够进行预测、生成文本和图像或其他输出，从而增强各行各业的各种应用。

有许许多多不同类型的 AI 模型，各自适用于特定的用例。 尽管 ChatGPT 及其生成式 AI 能力通过文本输入输出吸引了大量用户，但许多模型和公司提供多样化的输入与输出。 在 ChatGPT 之前，许多人已被 Midjourney、Stable Diffusion 等文本到图像的生成模型所折服。

下表根据输入与输出类型对若干模型进行了分类：

Spring AI 目前支持以语言、图像和音频作为输入与输出的模型。 上表最后一行以文本为输入、以数字为输出，通常被称为文本嵌入（embedding），它表示 AI 模型内部所使用的数据结构。 Spring AI 对嵌入的支持可让你实现更高级的用例。

GPT 之类模型的特别之处在于它们的预训练特性——正如 GPT 中的“P”，即 Chat Generative Pre-trained Transformer（生成式预训练变换器）。 这种预训练特性让 AI 成为一种通用开发者工具，无需具备深奥的机器学习或模型训练背景。

提示词

提示词是引导 AI 模型产生特定输出的基于语言的输入基础。 对于熟悉 ChatGPT 的人来说，提示词可能看似只是输入到对话框并发往 API 的一段文本。 但它包含的东西远不止于此。 在许多 AI 模型中，提示词的文本并非只是简单的字符串。

ChatGPT 的 API 在一个提示词内含有多段文本输入，每段文本输入都被赋予一个角色。 例如有 system（系统）角色，它告诉模型该如何表现并为交互设定上下文。 还有 user（用户）角色，通常对应来自用户的输入。

打磨高效的提示词既是一门艺术，也是一门科学。 ChatGPT 本就是为人类对话而设计的。 这与用 SQL“问问题”截然不同。 你必须像与另一个人交谈一样，与 AI 模型进行沟通。

正是这种交互方式如此重要，以至于“Prompt Engineering（提示词工程）”一词已演变为一门独立的学科。 不断有一批批技术涌现，用以提升提示词的有效性。 在打磨提示词上投入时间，能够显著改善最终的输出结果。

共享提示词已成为一种社区惯例，学界也在这一主题上积极开展研究。 举个例子，说明创建一个有效提示词有时多么有悖直觉（比如与 SQL 相比），一篇 近期研究论文 发现，你能用到的最高效的提示词之一，开头竟是“Take a deep breath and work on this step by step.” 这应当能让你明白语言为何如此重要。 对于这一技术的既往迭代（如 ChatGPT 3.5），我们尚且不完全懂得如何最优地使用，更何况正在开发的新版本。

提示词模板

创建有效的提示词，需要确立请求的上下文，并用特定于用户输入的数值来替换请求中的某些部分。

这一过程使用基于文本的传统模板引擎来进行提示词的创建与管理。 Spring AI 为此采用了开源库 StringTemplate。

例如，考虑一个简单的提示词模板：

Tell me a {adjective} joke about {content}.

在 Spring AI 中，提示词模板可以类比为 Spring MVC 架构中的“视图（View）”。 你会提供一个模型对象（通常是 java.util.Map）来填充模板中的占位符。 “渲染”后的字符串即成为提供给 AI 模型的提示词内容。

发往模型的提示词，其具体数据格式存在很大的差异。 提示词最初只是简单的字符串，如今已演化为包含多条消息，其中每条消息里的每个字符串都代表模型的一个不同角色。

嵌入

嵌入是文本、图像或视频的数值表示，用于捕捉输入之间的关系。

嵌入的工作原理是将文本、图像和视频转换为浮点数数组，即所谓向量。 这些向量旨在捕捉文本、图像和视频的含义。 嵌入数组的长度被称为该向量的维度。

通过计算两段文本的向量表示之间的数值距离，应用就可以判断生成这两个嵌入向量的对象之间的相似度。

作为一名探索 AI 的 Java 开发者，你不必理解这些向量表示背后复杂的数学理论或具体实现。 只要对它们在 AI 系统中的作用与功能有基本的了解就足够了，尤其是在你把 AI 能力集成到自己的应用中时。

嵌入在诸如检索增强生成（RAG）这类实际应用中尤为相关。 它们让你能够将数据表示为语义空间中的点，这类似于欧几里得几何中的二维空间，只是维度更高。 这意味着，正如欧氏几何中平面上两点根据坐标可近可远，在语义空间中，点之间的邻近程度反映了含义上的相似性。 关于相似主题的语句在这个多维空间中位置更近，就像图上彼此靠近的点一样。 这种邻近性有助于文本分类、语义搜索乃至产品推荐等任务，因为它让 AI 能够根据相关概念在这个扩展的语义版图中的“位置”来辨识并归类它们。

你可以把这个语义空间想象成一个向量。

令牌

令牌是 AI 模型运作的基本单元。 在输入时，模型将词语转换为令牌；在输出时，再将令牌转换回词语。

在英文中，一个令牌大约对应一个词的 75%。作为参考，莎士比亚的全部作品约 90 万个词，转换后大约为 120 万个令牌。

或许更重要的是：令牌即金钱（Tokens = Money）。 在托管 AI 模型的场景下，你的费用由所用令牌的数量决定。输入与输出都会计入整体的令牌数量。

此外，模型都受令牌上限的约束，这限制了单次 API 调用中可处理的文本量。 这个阈值常被称为“上下文窗口（context window）”。超出该限制的文本，模型不会处理。

例如，ChatGPT3 有 4K 的令牌上限，而 GPT4 提供了不同档位，如 8K、16K 和 32K。 Anthropic 的 Claude AI 模型具备 100K 的令牌上限，Meta 的近期研究更是产出了一个 100 万令牌上限的模型。

要用 GPT4 总结莎士比亚全集，你需要设计软件工程策略来切分数据，并在模型的上下文窗口限制内呈现数据。 Spring AI 项目会在这一任务上助你一臂之力。

结构化输出

AI 模型的输出传统上以 java.lang.String 的形式返回，即便你要求它以 JSON 回复。 它可能是合法的 JSON，但它并不是一个 JSON 数据结构，而只是一个字符串。 而且，在提示词里“要求 JSON”也并非百分之百准确。

这种微妙之处催生了一个专门的领域：编写提示词以产出期望的输出，随后再把得到的简单字符串转换为可用于应用集成的数据结构。

结构化输出转换 使用了精心设计的提示词，往往需要与模型进行多次交互才能达到期望的格式。

把你的数据与 API 带到 AI 模型

你该如何让 AI 模型获取它未曾在其上训练过的信息？

请注意，GPT 3.5/4.0 的数据集只延伸到 2021 年 9 月。 因此，对于需要该日期之后知识的问题，模型会回答不知道。 一个有趣的小细节是，这个数据集大约有 650GB。

将你的数据融入 AI 模型、对其进行定制，有三种技术：

• 微调（Fine Tuning）：这种传统的机器学习技术涉及定制模型并改变其内部权重。 然而，即便对于机器学习专家，这也是一项颇具挑战的过程，而且对于 GPT 这类因体量庞大的模型而言极其耗费资源。此外，某些模型可能根本不提供这个选项。

• 提示词塞入（Prompt Stuffing）：一个更务实的替代方案，是把你的数据嵌入到提供给模型的提示词中。鉴于模型的令牌上限，需要用一些技术来在模型的上下文窗口内呈现相关数据。 这种方法通俗地被称为“提示词塞入（stuffing the prompt）”。 Spring AI 库帮助你实现基于“提示词塞入”技术的方案，也就是众所周知的 检索增强生成（RAG）。

• 工具调用（Tool Calling）：这项技术允许注册工具（用户自定义的服务），将大语言模型连接到外部系统的 API。 Spring AI 极大地简化了为支持工具调用而需要编写的代码。

检索增强生成

一种称为检索增强生成（RAG）的技术已经出现，用以解决“如何把相关数据纳入提示词以获得准确的 AI 模型响应”这一难题。

该方法采用批处理式的编程模型：作业从你的文档中读取非结构化数据，对其进行转换，然后写入向量数据库。 从宏观上看，这是一个 ETL（抽取、转换、加载）流水线。 向量数据库用于 RAG 技术的检索环节。

在把非结构化数据加载进向量数据库的过程中，最重要的转换之一就是把原始文档切分成更小的片段。 这种将原始文档切分为更小片段的流程包含两个关键步骤：

1. 切分文档时保留内容的语义边界。 例如，对于含段落和表格的文档，应避免在段落或表格的中间切分。 对于代码，应避免在某个方法实现体的中间切分。
2. 将文档的各部分进一步切分成大小约占 AI 模型令牌上限一小部分的片段。

RAG 的下一阶段是处理用户输入。 当需要由 AI 模型回答用户的某个问题时，会把该问题以及所有“相似”的文档片段一起放入发送给 AI 模型的提示词中。 这正是使用向量数据库的原因——它非常擅长查找相似内容。

• ETL 流水线 提供了关于编排“从数据源抽取数据并存入结构化向量库、确保数据在传给 AI 模型前处于最优格式”这一流程的更多信息。
• ChatClient - RAG 说明了如何使用 QuestionAnswerAdvisor 在你的应用中启用 RAG 能力。

工具调用

大语言模型（LLM）在训练完成后即被冻结，导致其知识陈旧，并且无法访问或修改外部数据。

工具调用 机制弥补了这些不足。 它允许你把你自己的服务注册为工具，将大语言模型连接到外部系统的 API。 这些系统可以为 LLM 提供实时数据，并代表它们执行数据处理动作。

Spring AI 极大地简化了为支持工具调用而需要编写的代码。 它会代你处理工具调用的协商过程。 你可以把自己的工具作为一个用 @Tool 注解标注的方法提供，并在提示词选项中提供它，使其对模型可用。 此外，你还可以在单个提示词中定义并引用多个工具。

1. 当我们想让某个模型可用一个工具时，会在聊天请求中包含它的定义。每个工具定义都由名称、描述以及输入参数的模式（schema）组成。
2. 当模型决定调用某个工具时，它会返回一个响应，其中包含工具名称以及依照所定义模式构造的输入参数。
3. 应用负责使用该工具名称，以所提供的输入参数来识别并执行该工具。
4. 工具调用的结果由应用进行处理。
5. 应用将工具调用的结果发回给模型。
6. 模型使用工具调用的结果作为额外上下文，生成最终响应。

关于如何将此功能与不同 AI 模型一起使用，请参见 工具调用 文档以获取更多信息。

评估 AI 响应

有效地评估 AI 系统在响应用户请求时的输出，对于确保最终应用的准确性和实用性至关重要。 若干新兴技术让你能够利用预训练模型本身来完成这一目的。

这一评估过程涉及分析生成的响应是否与用户的意图以及查询的上下文相符。我们会使用相关性、连贯性和事实正确性等指标来衡量 AI 生成响应的质量。

一种做法是把用户的请求以及 AI 模型的响应一并呈现给模型，询问该响应是否与所提供的数据相符。

此外，利用存储在向量数据库中的信息作为补充数据，可以增强评估过程，帮助判断响应的相关性。

Spring AI 项目提供了一个 Evaluator API，目前可用来访问评估模型响应的一些基本策略。 更多信息请参见 评估测试 文档。