在了解此类的工具之前，我一直以为这种工具只是调用大模型api的一个工具类。实际了解之后，发现虽然它确实是工具类，但是却做到了很多我之前没想到的事情。 工具的诞生都是为了解决某类问题，所以用问题来标识springai这类工具的话，那么这类问题就是大模型如果在生产实践中如何落地。使用Spring AI在你的应用中嵌入大模型之后，你可以直接在对话中问q3季度跟q4比哪些项目盈利，并且盈利有多少，可以实现大模型可以直接调用你的应用中的接口获得数据。而且如果单独调用API每次的对话都是独立没有历史的，那在Spring AI中有单独的
ChatMemory可以实现对话记忆，不用每次都在调用的时候输入大量的上下文。诸如此类的问题有好多，我会在自己学习的时候做一个总结，整合成一个系列，争取能够弄清楚Spring AI的作用以及如何使用。
要想了解汽车发动机是怎么被装进汽车中完美运行，就得先了解一下发动机，最起码要知道它是怎么运行的，才能在装配的过程中完美发挥发动机的性能。把AI模型比成发动机的话，那么springai就是汽车工厂，要想知道汽车工厂怎么将发动机装进汽车，首先要了解大模型是怎么回事。
AI模型的诞生是2017年，Google提出了基于自注意力机制的神经网络结构——Transformer架构。具体这个架构是怎么回事，是什么注意力模型，现在不必过多关注，我们只需要知道，这个架构是现在所有AI模型的原型。而它的原理其实简单来说就是将人类语言转换成了向量，然后根据向量之间的相似性从问题得出答案。打个比方，AI模型相当于一只高度智能的电子鹦鹉，它会基于自己的知识库，按照这个模型得出一个符合人类预期的答案。所以就目前来说，现在的人工智能是一个比较聪明的搜索引擎，本身并不具备思考问题的能力。好多时候我们会觉得现在的AI模型已经达到了真正的人工智能，其中是有人类的参与的。我们给出了大量的提示词以及提前的训练量，才会使AI模型达到理想的程度。但是即便如此，AI模型能够做到的事情已经很多了，因为我们日常生活中大量的信息处理工作都是简单且重复的。但是现在AI模型能够做到的事情已经超出了很多人。所以在这个时代，保持思考的能力是多么重要。
了解完AI模型，我们简单了解一下Spring AI
该项目从 LangChain 和 LlamaIndex 等著名 Python 项目中汲取灵感，但 Spring AI 并不是这些项目的直接移植。项目成立的信念是，下一波生成式人工智能应用将不仅仅是 Python 开发人员的专利，它将在多种编程语言中无处不在。
介绍几个概念
模型
其实上文的内容讲的都是模型，Spring AI官方文档中根据输入跟输出类型进行进行了分类，其中最常用的就是LLM(Large Language Model)，即大语言模型
提示
提示词是指导模型正确的输出你想要内容的重要部分。如何让AI能更听话:【Promt Engineering】 现在已经是一门独立的学科。
例如，一个简单的提示词模板如下：
Tell me a {adjective} joke about {content}.
在 Spring AI 中，提示词模板可类比 Spring MVC 架构中的 “View” 层。系统会提供一个模型对象（通常是 java.util.Map）来填充模板中的占位符，最终 “渲染” 生成的字符串将作为传递给 AI 模型的提示内容。
Embedding
嵌入是将文本、图像或视频转化为数值表示的技术，能够捕捉输入数据之间的关联性。
嵌入通过将文本、图像和视频转换为浮点数数组（称为向量）来工作。这些向量旨在捕捉文本、图像和视频的含义。嵌入数组的长度称为向量的维度。
通过计算两段文本向量表示之间的数值距离，应用程序即可判定原始对象在嵌入向量空间中的相似程度。
嵌入技术在检索增强生成（RAG）等实际应用中尤为重要。它们将数据表示为语义空间中的点 — 类似于欧氏几何的二维空间，但维度更高。就像欧氏几何中点的坐标决定其远近，语义空间中点的距离反映含义的相似性：话题相近的句子在多维空间中的位置更接近，如同图表上相邻的数据点。这种邻近性助力文本分类、语义搜索及产品推荐等任务，使 AI 能根据概念在这个扩展语义 “地图” 中的 “坐标” 来识别和归类相关内容。
Token
令牌（Token）是 AI 模型运作的基础单元。输入时，模型将词语转换为令牌；输出时，再将令牌转换回词语。
在英语中，1 个 Token 大约对应 0.75 个单词。作为参考，莎士比亚全集约 90 万单词，对应约 120 万 Token。
结构化输出
AI 模型的输出传统上以 java.lang.String 形式返回 — 即便要求生成 JSON 格式的答复。它可能是格式正确的 JSON，但本质仍是字符串而非 JSON 数据结构。要注意，在提示词中简单要求 “输出 JSON” 并不能百分百保证结果准确性。
这一复杂性催生了一个专门领域：既要设计能生成预期输出的提示词，又需将返回的原始字符串转换为可供应用程序集成的数据结构。
将你的数据以及API接入AI模型
需注意，GPT-3.5/4.0 的训练数据仅更新至 2021 年 9 月。因此，对于需要该日期之后知识的提问，模型会回答 “不知道”。有趣的是，该训练数据集大小约为 650GB。
现在有三种技术可定制AI模型以整合你的数据
- 微调
- 这个是在模型内部进行调整，需要消耗专业机器以及计算量。当时DeepSeek就是在原来的基础上进行的微调才在原来的基础上只消耗了1/18的资源就达到了新的高度。
- 提示词填充
- 将数据直接嵌入到模型的提示词中。很多大模型的输入输出都有token量的限制，所以需要特定的是技术确保数据能适配上次问窗口，这种技术就是提示词填充。
- Spring AI 库能帮助你基于该技术（现多称为检索增强生成/RAG）实现解决方案。
- 工具调用
- 该技术支持注册工具（用户自定义服务），将大语言模型与外部系统 API 连接。Spring AI 大幅简化了实现 工具调用 所需的代码量。
检索增强生成（RAG）
检索增强生成（RAG）技术应运而生，专门解决将相关数据整合到提示词中以获取准确 AI 响应的难题。
该技术采用批处理编程模型：首先从文档中读取非结构化数据，经转换后写入向量数据库。本质上这是一个 ETL（抽取-转换-加载）流程，而向量数据库正是 RAG 技术中检索环节的核心组件。
将非结构化数据加载到向量数据库时，关键转换步骤之一是将原始文档分割成小块。这个分割过程包含两个重要环节：
-
在保留内容语义边界的前提下，将文档分割成若干部分。例如，对于包含段落和表格的文档，应避免在段落或表格中间分割文档。对于代码，应避免在方法实现的中间部分分割代码。
-
将初步分割后的文档块进一步细分，确保每个块的体积不超过 AI 模型 Token 限制的较小百分比（如15%-20%）。这种精细化处理既能适配模型上下文窗口，又最大限度保留语义连贯性。
RAG 的下一阶段是处理用户输入。当需要 AI 模型回答用户问题时，系统会将问题与所有 “相似” 的文档片段一起放入提示词中发送给模型。这正是使用向量数据库的原因 — 它极其擅长快速定位语义相似的内容。
工具调用
大语言模型（LLM）在训练完成后即固化，导致知识陈旧，且无法直接访问或修改外部数据。
工具调用机制 有效解决了这些局限。该功能允许你将自定义服务注册为工具，将大语言模型与外部系统 API 连接，使 LLM 能获取实时数据并委托这些系统执行数据处理操作。
Spring AI 极大简化了支持工具调用所需的编码工作，自动处理工具调用的对话交互。你只需将工具定义为带有 @Tool 注解的方法，并通过提示选项提供给模型即可调用。此外，单个提示中可定义和引用多个工具。
小结
我在这个文章里使用了大量的个人理解而非官方文档。一方面是为了加深自己的理解，一方面也是想把这部分写出来，抛砖引玉，大佬们如果觉得我哪说得不对的地方，加以指正。
其次，我认为Spring AI，或者说常规的java相关工作者想要在以后跟着AI发展，其主要的工作方向就在检索增强生成（RAG）,工具调用这两个部分。一部分内容是如何将数据整合到提示词中，如何增加AI回答的准确性；一部分是如何将AI高度嵌入到你当前的应用中。
另外，大家看这个标题应该可以看出来，这是一个系列，当前这个文章主要讲的是一些AI和Spring AI的一些概念以及理解。往后的形式会以问题的形式，比如《如何在使用过程中植入对话记忆--ChatMemory的使用》。这样以问题为出发点，篇幅会更短，且能直接对应实际使用的过程。
最后再叠下甲，本人对于AI的造诣非常浅，文章的大部分内容都是本人在学习过程中的一些感悟以及理解，有不对的地方请大家指正。
