虽然本文是面向软考架构师和系分总结的八股文，但这些知识都是AI相关的常识了，方才建议每个IT从业者都应该掌握，AI是一定要去学起来和用起来的。

ps：方才也根据相关知识点，录制了AI系列的题目，以便大家练习。

1. AI大模型原理

1.1. Agent智能体工作过程？

1）接收与理解输入：Agent首先“感知”环境或用户输入，将自然语言指令转为内部可处理的表示，以明确目标和约束条件。
2）规划：基于输入，LLM生成多步行动计划，拆解为子任务并排序，就像制定详细食谱确保烹饪思路清晰。
3）工具调用：Agent根据计划动态选择并调用外部工具或API（如搜索、数据库、计算器等）来完成各子任务。
4）观测：在每次工具执行后，Agent将输出作为“Observation”反馈给LLM，用于更新当前状态和后续决策。
5）记忆：关键观测和交互细节被存入短期或长期记忆，提高多轮对话或复杂任务中的上下文一致性。
6）决策：基于最新的观测结果、记忆内容和任务目标，Agent判断是否继续执行下一步操作或结束流程。
7）输出：在所有必要步骤完成后，Agent汇总信息，生成并返回最终结果给用户。
8）反思与纠错：可选地启动自我反思模块，评估已执行行动的正确性，必要时重规划或修正策略，避免重复错误。

1.2. A2A协议与MCP协议

MCP 和 A2A 分别从工具调用和智能体协作两个维度，推动 AI 从 “单点智能” 迈向 “全域协同”。

MCP 通过标准化工具接口降低AI-Agent 开发门槛，A2A 通过开放生态实现跨Agent的协作。两者结合，使得 AI 智能体不仅能 “单打独斗”（调用工具），还能 “组队作战”（多智能体协同），为智能制造、智慧医疗、金融风控等领域的复杂场景提供技术支撑。

随着谷歌、Anthropic 等企业的持续推动，以及苹果、微软等厂商的生态接入，这两大协议有望成为未来 AI 基础设施的核心组成部分。

对比维度	MCP协议（Model Context Protocol）	A2A协议（Agent-to-Agent）
提出方与时间	Anthropic，2024年11月发布	Google联合50余家科技公司，2025年4月推出，后捐赠给Linux基金会
核心定位	模型与外部工具/数据源的标准化通信桥梁，解决“模型调用工具”难题	跨厂商/框架智能体的协作通用标准，解决“智能体间协同”孤岛问题
核心功能	1. 统一工具调用规范，实现“即插即用”； 2. 支持工具向用户动态征询信息； 3. TLS 1.3加密+三维权限矩阵保障安全	1. 通过“Agent Card”自动发现能力，动态组建协作网络； 2. 支持任务全生命周期管理（进度跟踪/异步通信）； 3. 多模态交互+W3C DID身份验证
技术特点	1. 兼容性强，支持主流大模型（Claude/GPT等）与工具； 2. 轻量化，内存占用低至800KB以下	1. 开放中立，由Linux基金会托管，社区驱动； 2. 基于HTTP/SSE等现有标准，易集成企业IT系统
典型应用场景	1. 企业级多数据库（MySQL/MongoDB）联动分析； 2. 模型调用本地工具执行文件操作/图像生成	1. 企业ERP系统中订单-库存-物流智能体协同； 2. 智能家居温控-灯光智能体联动调节
与对方协作关系	为A2A协议提供“智能体调用工具”的底层能力支撑	为MCP协议扩展“工具调用结果跨智能体共享”的协作范围

1.3. A2A协议详解

A2A 是一种开放协议，为Agent之间的协作提供了一种标准方式，与底层框架或供应商无关，核心作用是让“客户端Agent”和“远程Agent”之间顺利沟通。

1.3.1. 5大原则

协议遵循以下几个核心原则：

• • 拥抱 Agentic 能力。A2A 专注于使 agent 能够以自然、非结构化的方式进行协作，即使它们不共享内存、工具和上下文。谷歌正在启用真正的多 Agent 场景，而不是限制 Agent 成为一个工具。

• • 建立在现有标准之上。该协议建立在现有的流行标准之上，包括 HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有 IT 栈集成。

• • 默认安全。A2A 旨在支持企业级身份验证和授权，在发布时与 OpenAPI 的身份验证方案具有同等效力。

• • 支持长时间运行的任务。支持从快速任务到深度研究的各种场景，当任务处于循环中时，这些场景可能需要数小时甚至数天才能完成。在整个过程中，A2A 可以向用户提供实时反馈、通知和状态更新。

• • 模态无关。Agent世界不仅限于文本，这就是为什么我们设计了 A2A 来支持各种模态，包括音频和视频流。

1.3.2. 工作原理

客户端Agent负责创建并下发任务，而远程Agent则根据这些任务提供信息或执行操作。整个过程中，A2A 提供了几个关键功能：

• • 能力发现：每个Agent都有一张“Agent卡”，以 JSON 格式描述它能做什么。客户端Agent可以通过这些卡片，找到最适合执行当前任务的远程Agent，并通过 A2A 协议与之建立通信。

• • 任务管理：客户端与远程Agent的交互围绕任务展开。每个任务都有一个由协议定义的“任务对象”，并且具有生命周期。有些任务可以立刻完成，而对于运行时间较长的任务，Agent之间可以持续沟通，保持状态同步，确保任务按预期推进。任务完成后会产生一个“工件”，也就是最终的执行结果。

• • 协作能力：Agent之间可以直接通信，发送包含上下文、回复、工件或用户指令的消息，便于协同完成更复杂的任务。

• • 用户体验协商：每条消息可以包含多个“部分”，每部分代表一个完整的内容片段，比如生成的图像。每个部分都有明确的内容类型，客户端和远程Agent可以据此协商最合适的展示格式，同时也可以决定是否支持如 iframe、视频、网页表单等用户界面功能，从而根据用户需求和设备能力，提供更好的使用体验。

1.4. MCP协议详解

有兴趣的伙伴可跳转阅读： MCP官方文档。

1.4.1. 是什么？

MCP（模型上下文协议）是一种用于将 AI 应用程序连接到外部系统的开源标准。将 MCP 视为用于 AI 应用的 USB-C 端口。正如 USB-C 提供了连接电子设备的标准化方式一样，MCP 也提供了将 AI 应用程序连接到外部系统的标准化方式。

1.4.2. 有什么用？

使用 MCP，Claude 或 ChatGPT 等人工智能应用程序可以连接到数据源（例如本地文件、数据库）、工具（例如搜索引擎、计算器）和工作流程（例如专门提示），使它们能够访问关键信息并执行任务。

MCP 的作用主要体现在以下几个方面：

1. 1. 标准化数据接入：通过 MCP，我们无需为每个模型编写单独的代码，而是通过统一的协议接口，实现一次集成，随处连接。这大大简化了模型与外部系统的集成过程。

2. 2. 增强模型能力：MCP 使得模型能够实时访问最新的数据和工具，例如直接从 GitHub 获取代码库信息，或从本地访问文件。这不仅提升了模型的实用性，也拓展了其应用场景。

3. 3. 提升系统可维护性：通过标准化的协议，系统的各个组件可以更加模块化地协作，降低了维护成本和出错概率。

1.4.3. 核心组件

MCP 的架构采用客户端-服务器模型，主机应用可以连接多个 MCP 服务器，每个服务器处理不同的资源和工具。这种模块化设计提高了系统的扩展性和可维护性。有3个核心组件：

• • MCP Host：协调和管理一个或多个 MCP Client的 AI 应用程序；

• • MCP Client ：维护与 MCP Server 的连接并从 MCP Server获取上下文供 MCP Host 使用的组件；

• • MCP Server ：向 MCP Client 提供上下文的程序；MCPServer可以在本地或远程执行，运行在本地的成为 local MCP Server，运行在远程的成为 remote MCP Server。

其中 MCP Host （如 Claude Code 或 Claude Desktop 等 AI 应用程序）建立与一个或多个 MCP Server的连接。MCP Host 通过为每个 MCP Server创建一个 MCP Client来实现这一点。每个 MCP Client都与其相应的 MCP Server保持专用的一对一连接。

例如 ：Visual Studio Code 充当 MCP 主机。当 Visual Studio Code 建立与 MCP 服务器（如 Sentry MCP 服务器）的连接时，Visual Studio Code 运行时会实例化一个 MCP 客户端对象，该对象维护与 Sentry MCP 服务器（就是 remote MCP Server）的连接。当 Visual Studio Code 随后连接到另一个 MCP 服务器（例如本地文件系统服务器）时，Visual Studio Code 运行时会实例化一个额外的 MCP 客户端对象来维护此连接，从而保持 MCP 客户端与 MCP 服务器的一对一关系。

1.4.4. 通信机制

MCP 使用 JSON-RPC 2.0 作为其底层 RPC 协议。客户端和服务器相互发送请求并做出相应的响应。当不需要响应时，可以使用通知。

MCP 支持两种传输机制：

• • Stdio transport  标准传输 ：使用标准输入/输出流在同一台机器上的本地进程之间进行直接进程通信，提供最佳性能，没有网络开销。

• • Streamable HTTP transport   可流式 HTTP 传输 ：使用 HTTP POST 处理客户端到服务器消息，并使用可选的服务器发送事件来实现流式处理功能。此传输支持远程服务器通信并支持标准 HTTP 身份验证方法，包括持有者令牌、API 密钥和自定义标头。MCP 建议使用 OAuth 来获取身份验证令牌。

1.4.5. 如何工作的？

MCP 的工作流程如下：

1）初始化连接：主机应用程序（如 Claude Desktop 或 IDE 插件）启动并初始化 MCP 客户端，每个客户端与一个 MCP 服务器建立连接。

2）获取工具列表

在系统初始化阶段，MCP Client 首先从 MCP Server获取可用的工具清单和能力描述。这些工具可以是 API、脚本、数据库查询方法等。这个步骤相当于“能力注册”，让模型知道有哪些可以用的“外部技能”。

3）构造 Function Calling 请求

当用户输入一个问题后，MCP Client 会将这些工具描述（包括参数、用途、返回值等）一并传给 LLM。传输方式采用 Function Calling，即结构化地把“能用的函数长什么样”告诉模型，让它来决定是否要使用。

4）模型智能判断是否调用工具

LLM 根据当前对话上下文以及工具信息判断是否要使用某个工具，并决定调用哪一个、传入什么参数。这个阶段完全由模型推理完成，比如它可以判断“这题需要查天气，那我就调用 getWeather 工具”。

5）工具调用执行阶段

如果模型发起调用请求，MCP Client 会根据模型的选择，通过 MCP Server发起工具调用。这一步是真正的“执行动作”——MCP Server 去实际跑工具的逻辑，并把结果返回给客户端。

6）结果返回与模型整合

工具执行结果（比如调用 API 得到的数据）被传回 LLM，由模型将这个结果与原始用户问题、已有上下文等信息整合，生成最终的自然语言回应。

7）用户响应输出

最后，MCP Client 将模型生成的回答展示给用户，完成一次完整的“智能+工具”协作流程。

ps：时序图如下，注意因为方才是使用mermaid格式绘制的，这个格式返回消息的线只能实线，但在UML时序图的规范中，返回消息应该是虚线，大家知晓下即可：

1.4.6. 安全性设计

MCP协议的安全性设计涵盖多个关键方面，旨在确保大模型系统在与外部工具和资源交互时的安全性和可靠性。MCP 的安全性设计主要包括以下几个方面：

1）用户同意和控制

所有模型对工具、资源和提示的访问请求都必须经过用户的授权。主机负责管理权限、提示用户批准，并在必要时阻止未经授权的访问。用户必须知道哪些数据是需要提供给大模型的，用户在授权使用之前应该了解每个工具的功能。

2）隔离与沙箱机制

MCP 的设计将实际工具调用封装在 MCP Server 内部，模型本身无法直接访问敏感数据，这种 “中间层”设计有效地降低了直接暴露内部业务系统的风险。同时，沙箱机制可以限制工具调用的执行环境，防止任意代码执行或恶意操作对系统造成破坏。

3）加密传输与来源验证

MCP 内置了安全机制，确保只有经过验证的请求才能访问特定资源，相当于在数据安全又加上了一道防线。同时，MCP协议还支持多种加密算法，以确保数据在传输过程中的安全性。

除了以上这些，我们在开发时应该还要考虑以下几个方面：

1）密钥加密处理

有些的 MCP 服务是需要输入第三方服务的密钥的，比如高德导航MCP，需要输入开放平台申请的key，客服端和服务器端传输的过程可能有泄露的风险，应该使用某种签名或者加密算法来保障数据安全。

2）模型诱导攻击

攻击者可能通过精心设计的提示词诱导模型执行不当的操作，例如泄露敏感信息或调用危险的工具。为防范此类攻击，建议在主机层面实施提示词过滤和上下文审查机制。

3）日志记录与调用链追踪

MCP 客服端和服务端都要记录每一次工具调用的详细日志，包括请求参数、响应结果和执行时间等信息，便于后续的实时监控和问题排查。

1.5. 什么是RAG技术？

RAG（检索增强生成，Retrieval-Augmented Generation）是一种结合信息检索与语言模型生成的技术框架，通过动态整合外部知识库的信息，显著提升生成内容的准确性、时效性和可信度。其核心思想是让模型在生成回答前先 “查阅资料”，而非仅依赖内部参数记忆，从而有效解决传统大模型的 “幻觉”、知识滞后等问题。

1.5.1. 核心组件

检索器（Retriever）：负责从外部知识库（如文档库、数据库、实时网络数据）中精准定位相关信息。主流方法包括：

• • 稀疏检索（如 BM25）：基于关键词匹配，擅长精确查询；

• • 稠密检索（如 DPR、Embedding 模型）：通过语义向量捕捉深层语义关联；

• • 混合检索：结合两者优势，平衡召回率与准确性。

生成器（Generator）：通常为大型语言模型（如 GPT-4、Claude 3），将检索结果与用户问题结合生成回答。融合方式包括：

• • 拼接输入：直接将查询与文档片段拼接后输入模型（如<CLS> Query (SEP) Doc1 (SEP) Doc2 ...）；

• • 注意力注入：在模型中间层动态注入文档向量（如 Fusion-in-Decoder 技术）。

• • 外部知识库：需经过文本清洗、分块（Chunking）和向量化预处理。分块策略包括固定大小分块、语义分割或递归分块，以平衡上下文完整性与检索效率。

1.5.2. 工作流程

• • 检索阶段：基于用户的输入，从外部知识库中检索与查询相关的文本片段，通常采用向量化表示和向量数据库进行语义匹配。

• • 生成阶段：将用户查询与检索到的内容作为上下文输入给生成模型，由模型输出最终回答。通俗来说，就是在本地检索到相关内容后，将其增强到提示词里，再进行结果生成。

加上知识库向量化的过程：

1.5.3. 核心优势与应用场景

1. 1. 关键优势

• • 降低幻觉风险：生成结果基于真实文档而非纯参数记忆，通过注意力机制约束内容范围；

• • 动态知识更新：实时接入外部数据源（如新闻、法规），解决模型知识截止问题；

• • 领域适配灵活：无需重新训练模型，只需更新知识库即可适应医疗、法律等专业领域。

• 2. 典型应用

• • • 智能客服与文档问答：如企业内部制度检索、学术论文关键信息提取，支持多轮追问和信息溯源；

  • • 医疗与法律辅助：检索最新医学文献或法规判例，为诊断和法律研究提供证据支持；

  • • 个性化资讯生成：根据用户偏好动态整合新闻、科技动态，生成定制化摘要并适配阅读场景（如通勤听新闻）。

  1.6. 护栏技术

  护栏技术是AI系统开发中用于确保模型输出安全、合规、符合伦理的一系列防御性技术手段，核心作用是防止AI产生有害、错误或违背人类价值观的结果。

  比如：当AI生成内容时，护栏技术会实时检测是否包含歧视、虚假信息、暴力内容等，并阻止或修正这类输出。它就像给AI系统加了一层“安全围栏”，让AI在既定的规则和目标范围内运行，避免“失控”。

  常见的护栏技术包括：

  1. 1. 内容安全过滤（如识别有害文本/图像）

  2. 2. 伦理规则引擎（预设禁止行为的逻辑判断）

  3. 3. 错误处理机制（当AI无法处理问题时，拒绝回答或引导人工介入）

  护栏技术的核心实现方式，大致流程如下：

  1. 1. 内容审核（用NLP模型检测关键词、语义风险）

  2. 2. 伦理规则校验（按预设规则库判断，如“禁止性别歧视”）

  3. 3. 安全边界检查（确保输出不超出模型训练范围，如拒绝回答专业医学问题）

  4. 4. 应急处理（触发风险时，返回安全提示/禁用功能/人工审核）→ 最终输出）

  主要的技术细节是：

  • • 规则引擎：通过人工编写或机器学习生成“禁止条件”，比如“包含‘攻击’‘杀死’等词且指向具体人物时，阻断输出”。

  • • 对抗样本检测：识别恶意输入（如故意诱导AI违规的prompt），防止被“越狱攻击”。

  • • 输出校准：对低风险但有争议的内容进行优化，比如将“男性不适合当程序员”改写为“职业选择与性别无关”。

  1.7. LangChain详解

  可参考阅读：LangChain官方文档

  1.7.1. 是什么？

  LangChain 是一个用于构建基于大语言模型（LLM）应用的开发框架，核心是解决 LLM 与外部数据、工具的连接与协同问题。

  这个框架的价值在于，它让开发者无需从零搭建复杂流程，就能快速实现“LLM 调用 + 数据处理 + 工具交互”的端到端应用，比如智能客服、知识库问答、自动化工作流等。

  LLM 本身存在明显局限，而 LangChain 正是针对这些局限提供解决方案：

  1. 1. 数据时效性差：LLM 训练数据有截止日期（如 GPT-4 截止到 2023 年 4 月），无法获取实时信息。LangChain 可连接搜索引擎、数据库，让 LLM 调用实时数据。

  2. 2. 上下文窗口有限：LLM 单次能处理的文本长度有限（如 GPT-3.5 为 4k/16k tokens），LangChain 通过“文档拆分 + 向量存储”，让 LLM 高效读取长文档。

  3. 3. 无法直接调用工具：LLM 不能主动操作软件（如发邮件、查 Excel、调用 API），LangChain 提供“工具调用”模块，让 LLM 根据需求触发外部工具。

  1.7.2. 核心组件

  这些组件是构建应用的基础模块，可灵活组合使用：

  组件类别	核心功能	常见应用场景
  Models	集成各类 LLM（如 OpenAI、Anthropic、开源模型 Llama 2）、embedding 模型（用于文本向量化）	选择合适的模型完成“生成文本”“文本向量化”任务
  Prompts	管理和优化提示词（Prompt），支持动态插入变量（如用户问题、文档片段）	构建结构化提示词，提升 LLM 回答准确性（如“基于{文档内容}回答{用户问题}”）
  Chains	将多个步骤串联成流程（如“加载文档→拆分→向量化→匹配相关片段→传给 LLM 生成回答”）	实现“多步骤自动化”，避免手动拼接流程
  Indexes	处理外部文档（拆分、向量化、存储到向量数据库），支持快速检索相关内容	构建“知识库问答”，让 LLM 基于特定文档（如公司手册、学术论文）回答
  Agents	让 LLM 自主决策“是否需要调用工具”“调用哪个工具”，无需固定流程	复杂任务（如“帮我查明天北京天气，再根据天气推荐穿搭，并生成日程表”）
  Tools	提供预设工具集（如搜索引擎、计算器、文件读取器、API 调用器），也支持自定义工具	让 LLM 执行具体操作（如查实时股价、读取 Excel 数据、发送 Slack 消息）

  1.7.3. 典型应用场景

  基于上述组件，开发者可快速落地多种应用：

  1. 1. 检索增强生成（RAG）：这是最主流的场景，让 LLM 基于特定文档回答问题（如“基于本公司 2024 年财报，回答营收增长原因”）。核心流程是“文档入库→用户提问→检索相关片段→LLM 结合片段生成回答”。

  2. 2. 智能代理（AI Agent）：让 LLM 像“助理”一样自主完成任务，例如“帮我整理本周邮件中的待办事项，按优先级排序，并生成 Outlook 日程”。

  3. 3. 多模态应用：结合文本、图片、音频等数据，例如“分析用户上传的产品图片，生成商品描述，并同步到电商平台”。

  4. 4. 自动化工作流：串联多个工具与 LLM，例如“监控行业新闻 API，当出现关键词‘AI 政策’时，自动提取核心信息并生成简报，发送到团队邮箱”。

  1.7.4. 优势与局限

  优势：

  • • 低代码门槛：封装了复杂逻辑（如文档拆分、工具调用），开发者用少量代码即可搭建应用。

  • • 高度灵活性：组件可自由组合，支持切换不同 LLM、工具或数据库，适配不同需求。

  • • 生态丰富：已集成主流 LLM（OpenAI、Google Gemini）、向量数据库（Pinecone、Milvus）和工具（Slack、Notion）。

  局限：

  • • 性能依赖 LLM：应用效果受底层 LLM 能力影响，若 LLM 逻辑错误，LangChain 无法修正。

  • • 调试难度较高：复杂 Chains 或 Agents 的流程较长，出现问题时定位原因（如提示词、工具调用）较麻烦。

  • • 轻量化场景冗余：若仅需简单调用 LLM（如生成文案），使用 LangChain 会增加不必要的复杂度。

  1.7.5. 与SpringAI的对比

  • • LangChain 更适合快速验证 AI 应用想法，尤其对 Python 开发者友好，生态灵活但缺乏标准化企业级特性。

  • • Spring AI 更适合 Java 技术栈的企业级应用，能无缝融入现有 Spring 系统，提供更规范的开发模式，但生态成熟度仍在发展中。

  对比维度	LangChain	Spring AI
  核心定位	通用 LLM 应用开发框架，支持多语言（Python 为主）	基于 Spring 生态的 AI 开发框架，专注 Java 生态
  主要技术栈	以 Python 为核心，支持 JavaScript 等	基于 Java，深度集成 Spring Boot、Spring Cloud
  工具调用方式	通过 Agent + Tool 抽象，支持动态选择工具	通过 AiTool 接口定义，结合 FunctionCall 机制
  Prompt 管理	提供 PromptTemplate 等丰富的模板工具	支持 PromptTemplate，与 Spring 资源管理集成
  LLM 集成	支持 OpenAI、Anthropic、开源模型等数十种	支持主流闭源模型（OpenAI、Azure）及部分开源模型
  向量存储集成	支持 Pinecone、Milvus、FAISS 等 30+ 向量数据库	支持主流向量数据库，与 Spring Data 风格统一
  生态适配	独立框架，需手动集成其他系统	天然适配 Spring 生态（如 Spring MVC、Security）
  部署方式	灵活部署，可嵌入各类应用	适合企业级部署，支持容器化、微服务架构
  学习门槛	较低，Python 开发者易上手	依赖 Spring 知识，适合 Java 开发者
  典型场景	快速原型开发、RAG 应用、轻量 Agent 工具	企业级 AI 应用、微服务中的 AI 能力集成
  社区活跃度	社区庞大，插件和第三方集成丰富	较新框架，社区成长中，背靠 Spring 生态

  1.8. 向量数据库

  向量数据库是RAG技术的核心底层组件之一，同时也是相似度检索、个性化推荐等应用的底层组件，也用于大模型辅助训练和优化，有必要再复习下。

  在综合知识部分，方才在存储技术中也介绍过：P2-数据库：常见的存储技术

  1.8.1. 主流数据库

  常见的向量数据库有 Milvus、Pinecone、Weaviate、Qdrant、Chroma、Faiss、Annoy 等。

  在选型时需综合考虑 功能特性、性能表现、成本预算、扩展性、团队技术栈 等因素。例如，Milvus 开源且支持大规模分布式部署，适合企业级应用；Pinecone 是全托管服务，便于快速部署但成本较高；Chroma 轻量级，适合小规模数据场景快速验证。

  主流向量数据库介绍：

  • • Milvus：开源国产，支持 TB 级向量的增删改和近实时查询，采用分布式架构，适合推荐系统、图像检索、NLP 等场景。例如电商平台中处理海量商品描述的向量检索。

  • • Pinecone：全托管式商业服务，开箱即用，高并发性能好，适合实时搜索、快速原型开发，但按使用量付费，成本较高。

  • • Weaviate：支持文本、图像等多模态数据，内置语义搜索，适合知识图谱、智能问答，但复杂查询时延迟较高。

  • • Qdrant：支持向量与元数据联合搜索，过滤和排序灵活，轻量级部署，适合推荐系统中元数据（如价格、品类）与向量结合的复杂查询。

  • • Chroma：专注嵌入式向量存储，支持本地化部署，Python SDK 集成简单，适合中小规模数据（如小型知识库项目）。

  • • Faiss：高效的相似性搜索库，支持 CPU/GPU 计算，适合研究型场景或对速度要求极高的任务，但安装依赖复杂，不支持元数据存储。

  • • Annoy：基于近似最近邻（ANN）的搜索库，适合大规模数据集的快速检索，常用于搜索引擎底层优化。

  上面是专用的向量数据库，除此之外还有一些支持向量搜索的开源数据库。

  例如：OpenSearch、PostgreSQL、ClickHouse 和 Cassandra。

  还有一些支持向量搜索的商用数据库

  例如：Elasticsearch、Redis、Rockset 和 SingleStore。

  1.8.2. 核心原理

  向量数据库的核心原理是通过将高维数据（如图像、文本）转换为多维向量，并基于相似性度量（如余弦相似度、欧氏距离），利用高效的索引结构和近似最近邻（ANN）算法，快速检索与目标最相似的向量结果。关键三步：

  1. 1. 向量化：将非结构化数据转化为数值向量，保留语义或特征信息；

  2. 2. 索引构建：通过HNSW图、产品量化（PQ）、位置敏感哈希（LSH）等结构预处理向量，加速搜索；

  3. 3. 近似搜索：允许一定误差，用ANN算法在速度与准确性间平衡，返回Top-K相似结果；

  整体流程：原始数据 → 向量化 → 索引构建（HNSW/PQ/LSH） → 输入查询向量 → ANN近似搜索 → 返回Top-K结果  

  对比传统数据库

  • • 传统数据库像查字典：必须精确拼写单词（比如搜“apple”才能找到苹果）。

  • • 向量数据库像描述找人：“找一个穿白T恤、戴眼镜的男人”（特征相似就行，允许误差）。

  2. AI项目应用篇

  ps：这部分内容是方才VIP社群的专属了，嘿嘿。

  3. 实战项目的分享

  ps：这部分内容也是方才VIP社群的专属，嘿嘿。

  备考资料&交流群

  2025最新的系分/架构备考资料和备考交流群，扫码即可领取加入：

  

  最后，方才软考架构师刷题系统已经上线了，欢迎大家使用（公众号后台回复【666】，即可一键体验，pc端地址：https://fangcaicoding.cn/papers）。

  推荐阅读：2025-方才的系分&架构VIP服务，助你一次性拿下软考