跳至主要內容

大模型LLM 常见面试题

LangChain

什么是 LangChain？

LangChain 是一个开源框架，专为快速构建复杂的大语言模型应用而设计。它通过模块化组件(Agents、Memor、Tools 等)和预制工具链，解决了传统LLM开发中的三大痛点

  1. 上下文管理：通过 Memory 组件(如对话历史缓存、实体关系跟踪)实现长对话连贯性,
  2. 多工具协同：支持动态调用外部API、数据库、搜索引擎等工具(如 GooglesearchTool)，例如在回答“2025年全球GDP排名”时自动触发实时数据查询。
  3. 复杂任务编排：通过 chains(链)和 Agents(代理)将多个LLM调用和工具操作组合成工作流，例如“分析财报一提取关键指标一生成可视化建议”的端到端流程。

LangChain 的核心组件有哪些？

LangChain 是一个专为大语言模型(LLM)应用开发而设计的框架，其核心组件包括：

  1. Models(模型)：支持多种语言模型，如 OpenAl、Anthropic、Mistral、Llama等，提供统一的接口，便于在不同模型之间切换。
  2. promotTemplates《提示词模板)：允许用户创建动态提示司，提高模型的泛化能力。通过模板化的方式，可以根据不同的输入生成相应的提示词，从而引导模型生成更准确的输出。
  3. Memory(记忆)：用于存储对话的上下文信息，支持短期记忆和长期记忆，短期记忆通常用于当前会话的上下文，而长期记忆则结合向量数据库，持久化存储重要信息，便于在未来的对话中调用。
  4. Chains(链式调用)：将多个外理步骤围联起来，形成一个处理流程。支持 Simple Chains(单步任务)和 Sequential chains(多步任务)，使得复杂任务的外理更加模块化和可复用。
  5. Agents(智能体)：通过 ReAct 框架，Agent 可以根据用户的输入动态选择合适的工具来完成任务，实现更灵活的任务处理。
  6. Tools(工具)：提供访问外部资源的能力，如 API、Google 搜索、SQL 数据库等，扩展了模型的功能，使其能够处理更复杂的任务,。

LangChain核心架构是什么样的

LangChain 的核心架构由四大关键模块组成：LangChain Libraries、LangChain Templates、LangServe 和 LangSmith。它们各自承担不同的角色，共同构建了一个完整的 LLM 应用开发、部署与监控的闭环体系

  • LangChain Libraries：这是整个框架的基础，包含多个子模块:
    • langchain-core：提供核心抽象，如模型接口、工具、向量存储等，设计轻量，便于扩展。
    • langchain：构建链(Chains)和代理(Agents)的主要模块，处理复杂的业务逻辑和外部 API 交互。
    • langchain-community：整合社区贡献的第三方工县和集成，如模型操作、提示词模板、文件解析、向量化等。
  • LangChain Templates：提供一系列易于部署的参考架构，适用于各种任务。这些模板预配置了常用的集成，便于快速上手和定制。
  • LangServe：用于将 LangChain 构建的链部署为 REST API 的库，集成了 FastAPI，支持流式、批量处理等功能，方便将应用推向生产环境,
  • LangSmith：开发者平台，提供调试、测试、评估和监控功能帮助开发者优化和部署基于LanaChain 构建的应用

什么是 LangChain Agent?

langchainAgent 是 langchain 框架中的一个核心组件，它的作用是利用大语言机型 (LLM)的推理能力，根据用户的输入动态地选择并调用合适的工具或链 (Chin)，以完成复杂的任务，与传统的链式调用不同，Agent不依赖于预定义的流程，而是能够根据实际情况灵活地决策和执行操作。

简单来说，LangChain Agent 就像是一个智能的指挥官，接收用户的指令后，分析任务需求，制定执行计划，选择合适的工具或方法，并根据执行结果进行调整，直到完成任务。

什么是 LangChain model?

langchain中的Model模块，主要是为了解决和各种语言模型(LLM)打交道时的接口统一问题，它提供了一套标准化的方式，让我们可以用司样的方式去调用不同厂商的模型，比加 OpenAl、Anthropic、Huging face等，这就像是给各种不同品牌的家电配上了通用的插头，我们不需要为每个品牌单独准备一个插座。

具体来说，LangChain 的 Model 模块包括以下几个核心部分：

  • LLM 和 ChatModel 接口：LLM 接口适用于传统的文本输入输出模型，而 ChatModel 接口则专为对话式模型设计，支持多轮对话的上下文管理。
  • Prompt 模板系统：提供了一种灵活的方式来构建和管理提示词，支持变量替换、条件逻辑等功能，方便生成动态的输入内容。
  • 输出解析器(Output Parsers)：用于将模型的原始输出转换为结构化的数据格式，比如 JSON、列表等，便于后续处理。
  • 同步与异步支持：无论我们是需要同步调用还是异步处理，LangChain 都提供了相应的支持，满足不同的应用场景需求。
  • 批量处理与流式输出：支持一次性处理多个输入，以及在生成过程中实时获取输出，提升了处理效率和用户体验。

LlamaIndex 如何与 LangChain 结合？

Lamalndex和 langchain 的结合，主要是为了构建更强大、更灵活的 RAG系统，LlamaIndex 擅长数据的索引和检索，而langchain 提供了丰富的链式调用、代理和工具集成能力，通过将LlamaIndex 的检索能力作为 LangChain 的工具(Tool)进行调用，可以实现复杂的多步骤推理和动态数据访问。

什么是 LangGraph ？

langGraph是Langchain 生态下的一个基于图结构的开源框架，专为构建状态化、多代理协同的复杂AI应用而设计。它通过将任务流程建模为有向无环图(DAG)结构对各节点 (Agent、工具、状态)及其交互进行精细控制。

它可以：

  • 通过拖拽界面设计工作流，非技术人员也能快速搭建复杂逻辑(如企业级客服系统)
  • 可以在关键节点(如财务审批、合规审核)插入人工确认环节，避免AI决策风险。
  • 实时展示模型生成过程(如逐句输出报告内容)，提升用户信任度。

LangGraph 编排的原理是什么？

LangGraph 的编排原理是通过图结构将复杂的 AI 任务分解为可编排的节点(如代理、工具、流程终点)，并通过状态流转和条件边实现动态流程控制，核心包含三个要素：

  • 节点 (Node)：代表独立处理单元(如 Agent 调用 LLM、Tool执行工具函数)，每个节点接收状态并返回更新后的状态
  • 边(Edge)：定义节点间的流转路径，支持条件分支(如根据用户输入选择不同处理逻辑)和循环(如需要多次修正结果)
  • 状态(State)：、贯穿整个流程的上下文数据(如对话历史、中间结果)，驱动节点间的动态交互

简单来说 LangGraph 像“流程图引擎”，我们通过画图(定义节点和边)描述任务逻辑，框架自动根据状态流转执行节点，支持复杂的多 Agent 协作和动态决策,

LangChain 和 LangGraph 有什么区别？

LanaChain 是基于链式结构(Chain)，适合线性任务(如文档问答、简单客服)，通过预定义步骤顺序执行，类似工厂流水线

LangGraph：基于图结构(Graph)，支持循环、分支和动态决策，适合需要多角色协作、状态跟踪的复杂任务(如临床试验审批、多智能体投资分析)

简单来说 LangChain 更像是一个“模块化 AI 应用框架”，用于拼接模型、工具、记忆等组件。而LangGraph 是专注于流程控制和任务编排的“有状态执行图框架”

在我们实际开发中，可根据任务复杂度选择：简单任务用LangChnain，复杂任务用langGraph，超复杂场景结合两者，如用Langchnain 处理基础链，LangGraph管理全局流程(要注意哈，两者并非替代关系，而是互补! langGraph可作为 LangChain 的扩展，在需要动态控制流和状态管理的场景中提升应用的灵活性和可靠性)。

什么是 Manus？说说你对它的了解

Manus是咱们由中国团队 Monica.im 于2025年3月推出的 全球首款通用型AI智能体，其核心突破在于能够独立思考、规划并执行复杂任务，直接交付完整成果(如股票分析报告、简历筛选结果)，而非仅提供对话式建议。

它通过一个 中央 模块、将用户的高层指令拆解为多个子午务，再由不同的内部智能体(Agent)或工具执行，形成端到端的自动化执行流程，底层还是调用大模型例如 Glaude、Qwen等来实现规划与决策。

Computer Use 是什么？说说它的原理

Computer Use 是 Anthropic 在 Claude 3.5 Sonnet 中推出的 AI 操作计算机的能力，允许 AI 直接通过 模拟鼠标点击键盘输入 等方式与操作系统和软件交互，实现从“文字对话”到“实际操作”的跨越
核心原理如下：

  1. API驱动的自动化交互：通过 操作系统级 API(如 Windows AP、macOs 系统调用)，将自然语言指令转化为计算机可执行的操作(如“打开 Chrome 搜索Seven一 启动浏览器并输入关键词)。
  2. 多智能体协作：内置 任务规划代理(分解任务)、工具调用代理(执行操作)、验证代理(校验结果)，形成流水线式处理(如“生成报告”一 拆分为“数据获取”“图表绘制”“格式校验”)。
  3. 视觉与语义结合：利用 OCR 技术 识别屏幕内容，结合 语义理解 定位目标(如“点击页面右上角的“登录”按钮”一 分析页面结构并模拟点击)

解释LangChain框架中的Chain和Agent概念，并举例说明各自的应用场景

LangChain框架中的Chain和Agent是两个核心组件，它们的主要区别在于执行方式:

  • Chain(链)：Chain是一个预定义的固定操作序列，按照既定的顺序执行任务。类似于一条生产线，每个步骤都是预先设定好的，按部就班地执行。
  • Agent(代理)：Agent则是一个能够动态决策的智能体，它可以根据当前情况自主选择使用什么工具、采取什么行动来完成任务。Agent使用语言模型作为推理引擎，能够实时判断和选择最优的行动序列。

使用LangChain实现RAG系统时，如何处理PDF文档中的表格数据召回问题？

处理 PDF 文档中的表格数据召回问题，需要采用多步骤处理策略：

  • 精确提取：使用专业的 PDF 解析工具(如 Unstructured.io)提取表格数据，确保表格结构完整性。
  • 上下文增强，为每个表格生成上下文描述，包含:
    • 表格主题和用途
    • 关键列名解释
    • 数据单位说明
    • 与文档其他部分的关联
  • 格式标准化：将表格转换为统一的 Markdown 格式，提升向量化效果和模型理解能力。
  • 统一嵌入：将上下文描述和标准化后的表格合并为"表格块"，优化向量数据库存储和检索效果

Agent

什么是大模型 Agent？它与传统的 AI 系统有什么不同？

大模型 Agent 是基于大型语言模型并结合模块化规划、记忆和工具调用的自主决策系统，它能够根据最终目标把复杂任务拆分成子任务，调用 API、检索数据库或使用插件，再通过内部循环不断优化执行流程，基本不需要人在每一步都监督。

主要区别如下:

  • 目标导向 vs 被动响应：传统大模型通常根据用户输入生成文本，缺乏主动性；而 Agent 以明确目标为驱动，能够主动规划并执行任务。
  • 记忆与状态管理：Agent具备短期和长期记忆能力，能够维护状态信息并根据历史经验调整行为；而传统大模型通常依赖于上下文窗口进行信息处理。
  • 多任务协同能力：Agent 能够处理复杂的多步骤任务，协调多个子任务的执行；而传统大模型通常处理单一任务，缺乏任务协同能力。
  • 推理与环境适应能力：和传统 AI 系统主要依赖预先设定的规则引擎或静态模型不同，大模型Agent 具备多步推理能力和动态环境适应能力，它能在执行过程中不断评估结果、调整策略，真正实现端型端的目标导向执行。

LLM Agent 的基本架构有哪些组成部分？

  • Agent核心(LLM本身)：作为“大脑”，负责理解输入、生成计划和下发指令，串联其他模块协同工作。
  • 规划模块(Planning))：将复杂目标拆解成有序的子任务，制定多步执行方案，并在必要时动态重规划。
  • 记忆模块(Memory)：短期保存当前对话或任务状态，长期存储跨会话的知识和经验，保障多轮交互的连贯性和上下文保持。
  • 工具使用(Tool use)：接入搜索、计算、数据库、代码执行、第三方插件等多种外部工具，为执行模块提供能力扩展。

LLM Agent 常见功能有哪些？

  • 指令理解与上下文处理：通过自然语言解析用户指令，理解任务目标和上下文信息。
  • 任务规划与分解：LLM Agent能先拟定解决问题的多个步骤，再按顺序逐步执行，确保思路清晰、有条不紊地推进任务。
  • 外部工具使用：具备调用搜索引擎、数据库、计算器、各类API 等工具的能力，以获取或处理信息，实现“知其然，更知其所以然”的效果
  • 巡环观测与执行：在每次工具调用后，观测模块会收集执行结果并反馈给决策模块，形成持续的Action-Observation循环，不断微调策略,
  • 记忆管理：支持短期对话上下文记忆和长期任务历史记忆，将关键数据存储以备后续参考，提升多轮交互的一致性和深度
  • 决策与分支：根据观测结果和已有记忆灵活做出决策，处理条件分支和循环逻辑，使执行路径能够动态调整，避免僵化流程。
  • 检索增强生成：集成检索模块，必要时调用外部知识库或文档，以检索增强生成(RAG)的方式提高回答的准确性和信息丰富度
  • 自我反思与纠错：通过内省模块评估自身输出的正确性和完整性，发现偏差时触发重试或修正策略，实现自我纠错。
  • 多模态能力：结合图像、音频等多种输入输出方式，扩展应用场景。

Agent智能体的工作过程是怎样的？

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

如何让 LLM Agent 具备长期记忆能力？

LLM 本身的上下文窗口通常只有几千到数万 tokens，所以需要借助外部机制来扩展其“记忆”能力，无法直接处理过多的历史交互信息，

  • 通过向量数据库+RAG机制增强长期记忆“先将对话和知识转换成向量 embedings 存入外部数据库(如FIASS、ChromaDB 或 Pinecone)，在新会话发起时根据用户查询检索相关历史内容，再将检索到的结果拼接至模型输入上下文，弥补原生上下文窗口的缺陷。
  • Memory Transformer/分层记忆体系：结合短期记忆(会话上下文)和长期记忆(外部存储的关键摘要或 embeddings)，通过 Memory Networks、Neural Turing Machines 或类似机制，将重要信息定期摘要成紧凑表示，存入专用存储，并在需要时根据上下文召回，实现分层记忆管理。

LLM Agent 如何进行动态 API 调用？

在面对让 LLM Agent 动态调用外部 API 的需求时，核心思路就是让模型能够像调用本地函数一样，把各种 AP| 当作“工具”提供给它，然后根据用户的意图自动选择并执行对应的工具，

  • 插件机制：先在平台(如 OpenAl Plugin 或 LangChain Agents)中注册好各类 API，把它们封装成插件或工具，当模型检测到用户需要某项功能时，就会自动加载对应插件并发起调用。
  • 动态函数调用：利用 OpenAI GPT-4 Turbo的function calling能力，事先定义好函数接口(函数名、参数格式、返回值结构等)，模型在生成响应时如果判断需要调用，就会输出符合该接口的 JSON，并由后端框架解折后触发真实 API 调用。
  • 代码解释器：部署一个受限的Python运行环境(或沙箱)，当模型需要做一些计算、数据处理甚至调用第三方库时，会生成相应的代码片段，在该环境中执行后再将结果反馈给模型和用户。

LLM Agent 在多模态任务中如何执行推理？

LLM Agent 在多模态推理中，核心是先把不同模态的数据(如图像、音频、视频、文本) 转换成统一的向量或语义表示，再将这些表示注入到大模型进行跨模态融合和推理。

  • 视觉-语言模型：常见做法是用 CLIP、BLIP-2等视觉编码器将图像转为 embeddings，然后与文本输入一起提供给LLM；或者直接使用 GPT-4V这样内置视觉理解能力的模型来处理图(像并输出自然语言回答
  • 语音-文本桥接：用 Whisper 或者其他,ASR 模型将音频转换成文本，再交给 LLM 去分析和生成响应，前后端串联即可实现多模态推理。
  • 工具链调用：结合OCR、物体检测、视频帧提取等工具，LLM Agent 根据任务需求按需调用这些工具，将结果合并进它的上下文，再由模型执行更高级别的推理或决策,

市面上有哪些主流的 LLM Agent 框架？各自的特点是什么？

  • LangChain：模块化设计，支持多模型接入、链式调用、工具集成和记忆管理，适合快速构建复杂的 LLM 应用。
  • Llamalndex(原 GPT Index)：专注于数据索引和检索，优化 LLM 与外部数据的结合，增强检索能力(RAG)
  • AutoGPT：实现自主 AI 代理，能够生成目标、拆解任务、自主迭代，适用于需要自主决策的场景。
  • BabyAGI：最小化的自主 Al Agent，基于 OpenAl+ Pinecone 进行任务迭代，适合轻量级的任务调度。
  • CrewA1：支持多个 Agent 组成团队协作，不同 Agent 具有不同角色，适用于复杂的工作流程。
  • LangGraph：基于有向无环图(DAG)的 LLM 工作流管理，使 Agent 任务更具可控性和可扩展性，适合多步骤推理和任务分解。

ReAct 是什么？说说它的原理

ReAct(Reasoning and Acting)是一种基于大语言模型的智能体框架，它让模型在生成回答时交替输出“思考”和“行动”步骤，从而在内部推理与外部交互之间形成闭环，能够边“想”边“做”来完成复杂任务,

核心原理

  1. 推理 (Reasoning)：模型先通过自然语言生成“思考过程”，明确是否需要工具、需要什么工具、输入什么参数。
  2. 行动(Action)：根据当前思路选择合适的操作 (如调用搜索、工具 API、环境交互等)，并输出具体的指令。
  3. 观察(Observation)：执行Action 后，系统将返回的结果(网页片段、环境反馈等)提供给模型。
  4. 循环迭代：将 Observation 附加到上下文，模型在新的上下文中继续“思考一行动一观察”循环，直到输出最终答案或结束指令

什么是 ReAct？如何基于 ReAct 模式构建具备自主规划能力的 AI 智能体？

ReAct，即 Reasoning+Acing(推理与行动)，是一种结合推理和行动的智能体架构，它模仿人类解决问题时“思考一行动一观察”的循环，AI 首先对问题进行推理(Reason)，将原始问题拆分为多步骤任务，明确当前要执行的步骤、然后，它会调用外部工具执行行动(Act)，比如调用慢索引引擎或访问网页，最后，它会观察(0bserve)工具返回的结果，并将这些结果反馈给智能体，用于下一步的决策，这个过程会不断循环法代，直到任务完成或达到预设的终止条件。

基于 ReAct 模式构建具备自主规划能力的 AI 智能体，核心在于实现这个 “思考-行动-观察”的循环。这意味着智能体要实现：

  • 接收用户指令后，能分析并拆解成可执行的子任务。
  • 根据子任务的需要，从可用的工具集中选择合适的工具并执行。
  • 分析工具执行的结果，判断任务进展，决定下一步是继续调用工具、向用户澄清还是结束任务。

什么是 OpenManus？它的实现原理是什么？

OpenManus 是一个开源的自主规划智能体项目，它的核心亮点在于其“自主执行”能力，能自主规划任务，并且在虚拟机中调用各种工具 （如编写代码，获取数据）来完成用户指定的复杂任务、它的实现原理主要基干以下几点：

  • 分层代理架构：OpenManus 采用了分层的代理架构，不同层次的代理负责不同的功能，方便系统的扩展和维护。主要代理层次包括 BaseAgent(基础代理，管理伏态和执行循坏)、 ReActAgent(实现 ReAct模式)、ToolCallAgent(扩展了工具调用能力)以及具体的智能体实例(如 Manus )。
  • ReAdt模式：OpenManus 的工作流程遵循“思考,行动,观察”的循环， TollCallAgent 的 think 方法负责与大模型交互、选择工具，act 方法负责执行工具，并将结果反馈给大模型进行下一步决策。
  • 工具系统：OpenManus拥有一个灵活的工具系统，所有工具都继承自 BaseTool 抽象基类，提供统一的接口和规范化的参数描述，方便大模型理解和调用。ToolCollection 类可以管理多个工具实例，实现了工具系统的可插拔性。
  • 核心组件：包括记忆系统(memory类存储对话历史和中间状态)、大模型(LLM类提供思考和决策能力)以及流程控制(AgentState 和执行循环管理状态转换和任务流程)
  • 特殊工具设计：比如， Terminate工具是让智能体自主决定何时结束任务， AskHuman 工具则是让智能体在遇到困难时向人类寻求帮助。
  • MCP 协议：最新版本的 OpenManus 已经支持，通过 mcpclients 类将 MCP 服务集成到其工具系统中，让远程工具能够像本地工具一样被调用。

什么是 CoT 思维链？如何实现 CoT 思维链？

CoT(Chain of Thought)思维链的目的是让 AI 像人类一样“思考”

在处理复杂问题的时候，引导模型展示推理过程，按步骤进行思考，从而提高回答的准确性，尤其对于复杂的推理类问题效果更佳。

与此同时，让模型展示推理过程也可以帮助我们理解和优化 AI的决策路径。

为了实现 CoT 思维链，我们通常会在输入 Prompt 时加入特定的引导语。OpenManus 项目的早期版本就使用了特定的系统提示词来实现 CoT。除了直接在系统提示词中给出指令外，还可以结合few-shot learning 的技巧，也就是在 prompt 中提供一两个包含清晰思维链的问题和答案示例，直接让模型学习如何构建和展示自己的思维链

什么是 CoT 思维链和 ReAct 模式？它们如何提高 AI 推理能力？

CoT 思维链(Chain of Thought) 和 ReAct 模式 (Reasoning + Acting) 都是增强大型语言模型推理和解决复杂问题能力的技术

  • CoT思维链：生成最终答案之前，先引导AI 模型输出一系列中间的、连贯的推理步现，引导模型“思考过程化”，模拟人类解决问题时逐步分析和推导的过程。它通过让模型显式地写出思考步骤，可以帮助模型分解复杂问题，减少在复杂逻辑链条中出错的概率。这些中间步骤也为我们理解模型的“思路”提供了便利，调试和优化都会更简单方便。
  • ReAct模式：一种将LLM的推理(Reasoning)能力与行动(Acting)能力相结合的框架。它让模型不仅能思考，还能决定采取何种行动(通常是调用外部工具，例如文件操作、联网搜索)，然后根据行动的观察结果执行下轮的思考和行动，形成一个“思考-行动-观察”的循环。

CoT主要关注提升模型内部的逻辑推理连贯性和深度，通过显化思考过程实现。ReAct 更注重于让模型与外部世界互动,，通过“推里驱动行动,，行动反馈观察，观察指导推理”的闭环来解决那些需要外部信息或操作才能完成的复杂任务，更考验模型动态调整推理路径的能力。

Copilet 模式和 Agent 模式的区别是什么？

  • Agent(代理智能体模式)：主要可以自主驱动，大模型独立拆解任务(如规划旅行行程)、调用工具(如API、数据库)完成端到端操作。比如，用户仅需设定目标(如“安排下周会议”)，Agent自主规划、执行并反馈结果。
  • Copilot(副驾驶协助模式)：大模型作为“助手”提供实时建议(如代码补全、文案润色)，但用户保留最终决策权。比如，用户明确输入需求(如“写一段 Java 排序代码”)，然后多轮交互优化结果

其实还有个 Embedding(嵌入模式)，主要是后台辅助，将大模型作为“隐藏组件”集成到现有系统中(如推荐算法、搜索优化)，用户无感知。

一句话总结：Embedding是“隐形的数据助手”，Copilot是“协作的智能搭档”，Agent是“全能的AI管家”

AutoGPT 如何实现自主决策？

AutoGPT 之所以能够实现自主决策，主要得益于其引入了一套完整的反馈循环机制。这套机制包括以下几个关键步骤:

  1. 目标设定：用户只需提供一个高层次的目标，AutoGPT会将其细化为多个子任务。
  2. 任务规划：系统会对目标进行分析，制定出实现目标的详细计划。
  3. 任务执行：AutoGPT 会按照计划调用相应的工具或执行代码，以完成各个子任务。
  4. 结果评估：在每个任务执行后，系统会对结果进行评估，判断是否达到预期目标。
  5. 策略调整：根据评估结果，AutoGPT 会对原有计划进行调整，优化后续的任务执行策略。

通过这样的循环，AutoGPT 能够在无需人工干预的情况下，自主地完成复杂的任务。

Agent 死循环问题有遇到过吗?如何解决?

有的，当时在构建基于大模型的 Agent 时，遇到这样一个现象：调用链是“先査订单号 → 得到物流单号 → 査物流单号 → 返回物流信息”；但一定的概率会是：订单号给到大模型，拿到了物流单号，再把订单号和物流单号一起给到大模型，大模型给你返回的还是物流单号，并且没返回 endFlag。导致Java 侧死循环调用

主要原因是输入提示词设计不明确、Agent 没有添加明确的状态流转判断，且还欠缺调用次数/语义差异的兜底保护策略。因此我们做了改造：

  1. 强制声明 “若已获取物流单号，直接调用查物流接口，无需重复生成”
  2. 状态变量(如 step=1/2/3)跟踪当前步骤，输入时附带状态标识，模型按状态执行对应动作。
  3. 设置调用兜底机制：最多调用3次，并检查返回字段是否变化，检查是否包含 endFlag。

RAG

为什么有RAG？

因为，随着自然语言处理技术的发展，纯生成模型虽然可以生成流畅的文本，但有时知识会滞后或不够精准。

通过引入检索模块，RAG 模型能够从外部知识库中提取实时且丰富的信息，再经过生成模型综合处理，提升回答的准确率和爱盖面，而无需重新训练模型

什么是 RAG？RAG 的主要流程是什么？

RAG(Retrieval Augmented Generation，检索增强生成)是一种结合信息检索和生成式模型的技术方案，其主要流程包括两个核心环节：

  1. 检索(Retrieval): 基于用户的输入，从外部知识库中检索与查询相关的文本片段，通常使用向量化表示和向量数据库进行语义匹配
  2. 生成(Generation): 将用户查询与检索到的内容作为上下文输入给生成模型(如 GPT等)，由模型输出最终回答。

即我们在本地检索到相关的内容，把它增强到提示词里，然后再去做结果生成简单来说就是利用外部知识动态补充模型生成能力，既能保证回答的准确性，又能在知识库更新时及时反映最新信息(还有一点就是部分业务是内部文档，网上没有，因此可以本地提供知识库来增强 AI 的知识)

整体流程如下：

  1. 文本向量化(Embedding)：使用语义模型 (如 OpenAl的 text-embedding-ada-002，或者 Sentence-BERT等)将文档和问题转为高维向量表示
  2. 向量数据库检索：使用如 Faiss、Milvus等向量数据库存储所有文档向量。用户提问后，对问题进行向量化，并在数据库中执行最近邻搜索，找出语义最相近的N 条内容
  3. 构建 Prompt：将用户原始问题和检索到的内容拼接成上下文输入，传入生成模型
  4. 生成回答：由大语言模型(如 GPT、LLaMA 等)综合已有上下文生成最终输出。

什么是向量数据库？在基于大模型的应用开发中，向量数据库主要解决什么问题？

向量数据库是一种专门设计用来存储和管理向量嵌入(vector embedding)的数据库系统，它可以将非结构化数据(如文本、图片、音频等)转换成高维向量的形式进行存储，并提供高效的相似性搜索功能

在基于大模型的应用开发中，向量数据库主要解决以下核心问题：

  • 高效的相似性搜索：通过将用户查询转换为向量，可以快速找到语义相似的内容，这对于实现智能问答、推荐系统等功能至关重要。
  • 海量数据处理：能够高效处理大模型生成的海量数据，传统数据库难以处理百万甚至数十亿的数据点，而向量数据库专门针对这种场景进行了优化。
  • 实时交互支持：在需要实时用户交互的应用中(如聊天机器人)，向量数据库可以确保快速检索相关上下文信息，提供实时响应,

你都了解哪些向量数据库？如何选型？

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

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

  • Milvus：开源国产，支持T8级向量的增删改和近实时查询，采用分布式架构，适合推荐系统、图像检索、NLP等场景。例如电商平台中处理海量商品描述的向量检索。
  • Pinecone：全托管式商业服务，开箱即用，高并发性能好，适合实时搜索、快速原型开发，但按使用量付费，成本较高
  • Weaviate：支持文本、图像等多模态数据，内置语义搜索，适合知识图谱、智能问答，但复杂查询时延迟较高。
  • Qdrant：支持向量与元数据联合搜索，过滤和排序灵活，轻量级部署，适合推荐系统中元数据(如价格、品类)与向量结合的复杂查询
  • Chroma：专注嵌入式向量存储，支持本地化部署，Python SDK集成简单，适合中小规模数据(如小型知识库项目)。
  • Faiss：高效的相似性搜索库，支持 CPU/GPU 计算，适合研究型场景或对速度要求极高的任务，但安装依赖复杂，不支持元数据存储
  • Annoy：基于近似最近邻(ANN)的搜索库，适合大规模数据集的快速检索，常用于搜索引擎底层优化。

上面是专用的向量数据库，除此之外还有一些支持向量搜索的开源数据库.例如：OpenSearch、PostgreSQL、ClickHouse 和 Cassandra

还有一些支持向量搜索的商用数据库：Elacticcearch、Redis、Rocket 和 SingleStore

向量数据库原理是什么？ 请简述下它的原理

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

  1. 向量化：将非结构化数据转化为数值向量，保留语义或特征信息
  2. 索引构建：通过HNSW图、产品量化(PQ)、位置敏感哈希(LSH)等结构预处理向量，加速搜索
  3. 近似搜索：允许一定误差，用ANN算法在速度与准确性间平衡，返回Top-K相似结果

向量数据库中的 HNSW、LSH、PQ 分别是什么意思？

它们是向量数据库中三种核心索引与压缩技术，用于加速高维向量的相似性搜索

HNSW (Hierarchical Navigable Small World)图：

  • 在高维空间中，将所有向量组织成分层“小世界”图。
  • 查询时，从上层稀疏图贪心跳转到最相似邻居，逐层下探到密集的底层图，快速找到近似最邻近点

LSH(Locality-Sensitive Hashing)哈希

  • 利用一组专门设计的哈希函数，把相似向量映射到同一个或相邻的哈希桶。
  • 查询时只需查对应桶内的候选项，再做精确排序，极大缩小检索范围。

PQ(Product Quantization)量化

  • 将高维向量切分成若干子块，对每块分别做聚类，用“码字”来近似原始子向量。
  • 存储时只保存每段的码字索引，检索时通过查预先计算好的子块距离表来快速估算向量间距离

向量数据库中的 ANN 是什么？为什么需要用它？

ANN 是"近似最近邻 (Approximate Nearest Neighbor)”的缩写，它不是某一种具体算法，而是一类通过牺牲一定精确性来换取搜索速度的算法推架或者技术

其核心是在海量高维向量中，快速找到与目标向量“近似相似”的结果，而非耗费大量时间寻找绝对精确的最近邻。

因为当数据量达到百万甚至十亿级时，暴力遍历所有向量计算距离(精确搜索)会慢到无法接受，而ANN通过智能索引和近似策略，实现毫秒级响应，满足实时搜索需求。

向量数据库中，常见的向量搜索方法：余弦相似度、欧几里得距离和曼哈顿距离分别是什么？有什么区别？

  • 余弦相似度：衡量两个向量的“方向相似性”，不关心向量长度，取值范围[-1,1]，值越大方向越接近(比如“猫”和“狗”的文本向量)
  • 欧几里得距离(欧氏距离)：计算两个向量在空间中的“直线距离”，取值20，距离越小向量越相似(比如两张图片的像素特征向量)。
  • 曼哈顿距离：计算两个向量在各维度上的差值绝对值之和，类似“在城市街区中沿道路行走的距离”，取值≥0，适用于网格状数据(如地图坐标)

简单来看：余弦比“方向”，欧氏比“绝对距离”，曼哈顿比“线性累加距离”。因此：

  • 文本、推荐系统常用余弦相似度(不关心文本长度，只看语义方向)
  • 图像、视频检索常用欧氏距离(直接比较像素特征的空间差异)
  • 网格数据(如城市坐标、表格数据)常用曼哈顿距离(符合实际移动逻辑，稀数据的处理)

向量数据库的工作流程有哪些？请简述下

向量数据库的工作流程可拆解为五步，核心是将非结构化数据转化为可计算、可检索的向量形式

  1. 数据处理：清洗数据(去噪、归一化)、标注元数据(如标签、时间)
  2. 向量化：用AI模型(如BERT、ResNet)提取特征，生成高维向量
  3. 向量存储：将向量与原始数据关联，存入分布式存储(如分块存储)
  4. 索引构建：用HNSW、LSH等技术组织向量，建立高效检索结构
  5. 相似性检索：输入目标向量，通过索引快速返回Top-K近似结果

RAG 的文档处理流程是怎样的？

RAG 文档处理流程的目的是把原始文档转化为 AI 可检索、可理解的格式，从而增强 Al 的回答质量,

这个流程主要包含以下四个核心步骤:

  1. 文档收集和切割
    1. 收集(Extract):从各种数据源收集原始文档资料。比如本地文件系统中的 PDF、Markdown 文档，或者网页、数据库等
    1. 预处理与切割(Transform):对收集到的原始文档进行清洗，去除无关信息(比如 HTML标签、广告内容)并统一格式，然后将篇幅较长的文档分割成更小、更易于处理的文本块。
  4. 向量转换和存储:
    1. 向量转换：使用专门的 Embedding 模型把上一步得到的每个文本块转换为高维的数字向量
    1. 向量存储(Load):把生成的向量及对应的原始文本块内容和元数据一起存入向量数据库中。

前两个步骤经历了完整的 ETL流程，也就是对文档进行抽取、转换和加载。

  1. 文档过滤和检索:
    1. 查询处理：当用户提出一个问题(查询)时，这个查询文本也会被同一个Embedding 模型转换为向量形式。
    2. 相似度搜索：系统使用用户查询的向量，在向量数据库中搜索与之最相似的文档向量。一般会检索出 Top-K个最相似的结果。
    3. 过滤机制：在检索过程中，可以根据文档的元数据进行过滤，例如只检索特定来源或特定时间范围内的文档，提高检索结果的精确性,。
  2. 查询增强和关联:
    4. 上下文组装：把上一步检索到的相关文档块提取出来，跟用户的原始查询组合在一起，形成一个增强的提示。
    内容生成：这个增强的提示会被发送给大模型，大模型利用这些检索到的、作为额外上下文的知识来生成回答，因为有了相关的、可能更新的外部知识，生成的回答通常比仅依赖其内部预训练知识更为准确和具体。
    2. 源引用与后处理：生成的回答可以附带信息来源的引用，即说明哪些信息来自哪些检索到的文档。还可以进行一些后外理，如格式化输出、内容摘要等，优化最终呈现给用户的结果。

这个流程帮助 AI 在回答问题时，能够参考到最新的、特定的外部知识，有效缓解大模型的知识陈旧和“幻觉”问题

RAG 的完整流程是怎么样的？

RAG(检索增强生成)的完整流程可分为5个核心阶段:

  1. 数据准备：清洗文档、分块处理(如PDF转文本切片)
  2. 向量化：使用嵌入模型(如BERT、BGE)将文本转为向量
  3. 索引存储：向量存入数据库(如Milvus、Faiss、Elasticsearch)
  4. 检索增强：用户提问向量化后检索相关文档,
  5. 生成答案：将检索结果与问题组合输入大模型生成回答

也可以从三个阶段来回签:

  1. 在 RAG 索引阶段，首先对原始文档进行解析，并将其拆分成多个较小的文本块。随后，这些文本块会通过嵌入模型进行向量化处理，生成的向量将被存储在向量数据库中，供后续检索使用
  2. 在 RAG 检索阶段，RAG 系统会将用户的查询同样进行向量化，并在向量数据库中执行语义相似度匹配，筛选出与查询最相关的一组文本块。
  3. 最后在生成阶段，系统将用户查询与检索到的相关文本块进行组合，通过提示工程(PromptEngimneering)设计适当的输入格式，然后交由大语言模型生成最终的回答，至此完成整个 RAG的流程。

什么是 RAG 中的 Rerank？具体需要怎么做？

在RAG中，Rerank是个对初步检索返回的候选文档列表进行再次排序的过程

因为初步检索需要快速地在海量的文档中找出大致相关的文档，其需要考虑效率，所以查找出的文档不会非常准确，这步是粗排。在已经筛选的相关的文档中再进行精筛，找出匹配度更高的文档让其排在前面，选其中的Top-K然后扔给大模型，提高答案的准确性，这就是 Rerank，也是精排。

Rerank 需要怎么做?

  1. 初步检索生成候选文档：使用速度较快的传统检索方法获得一组候选文档。
  2. 根据Rerank模型重新排序：根据Rerank模型匹配得分对候选文档进行排序，选出最相关的 Top-K 文档.
  3. 交给生成模块：Top-K候选文档传递给大模型，帮助生成更精准、更富信息量的回答。

为什么需要 Rerank？如果没有 Rerank 会怎么样？

初步检索方法通常为了速度牺牲了一些精度，可能包含许多噪音文档。

而 Rerank 能够利用更高级的模型深入捕捉查询与文档之间的细微语义关系，从而筛除无关文档，确保生成模块获得高质量上下文信息。

如果没有 Rerank，生成模块可能基于噪音或不相关的文档生成回答，这会影响回答的准确性，甚至还可能引发误解。

在 RAG 应用中为了优化检索精度，其中的数据清洗和预处理怎么做？

什么查询扩展？为什么在 RAG 应用中需要查询扩展？

查询扩展是指对用户原始查询进行优化和补充，通过添加同义词、相关术语、隐含意图等信息，让查询更精准、覆盖范围更广，从而提升信息检索的效果。比如用户输入“减肥”，扩展后可能变成“健康减肥方法 饮食运动 避免反弹”

RAG(检索增强生成)的核心是“先检索、后生成”，如果原始查询不够准确或覆盖范围不足，会导致检索到的文档不相关或信息不全，最终生成的回答质量会受影响。查询扩展能解决两个关键问题:

  1. 词汇匹配问题：用户用词和知识库中的术语可能不一致(如“新冠”vs“COVID-19”)，扩展后能匹配更多相关内容。
  2. 语义补全问题：用户查询可能简短模糊(如“怎么理财”)，扩展后能明确需求(如“新手理财入门 低风险投资 基金股票区别”)，让检索更精准。

什么自查询？为什么在 RAG 中需要自查询？

自查询(Self-Query)是指当用户输入 模糊表述或隐含需求时，RAG 系统通过内部处理让模型自动解析用户査询中的隐含条件(如时间、作者、标签等元数据)，生成结构化查询语句的过程。

比如用户说“2025年SevenCoding的用户报告”，自查询会解析出两个条件：

  1. 语义匹配：用户报告
  2. 元数据过滤：作者=SevenCoding、时间=2025

为什么在RAG中需要自查询？因为用户提问往往包含模规表述或隐含需求，传统向量检索可能忽略元数据导致结果偏差。自查询通过解析+过滤两步走，让检索同时满足语义相关性和元数据条件，解决“检索不准”的核心问题。

什么是 RAG 中的分块？为什么需要分块？

分块就是把原始长文本(比如一本书、一篇论文)拆成若干个“小块”(通常几百字到上千字，比如500-1000字)，每个小块包含相对完整的语义单元，比如一个段落、几个段落或一个小节。

为什么需要分块?

  1. 模型处理能力限制：大语言模型(如GPT)一次能处理的文本长度有限，太长的文本塞进去会“消化不良”，分块后每个小块能塞进模型的“肚子”里。
  2. 精准定位信息：用户提问通常针对局部内容(比如“第三章第二部分的案例是什么”)，分块后每个小块像“信息卡片”，检索时能快速找到最相关的卡片，避免在整本大书里“大海捞针”
  3. 平衡上下文与效率：小块既能保留足够上下文(比如前后句子的逻辑)，又能让计算机高效存储和检索(小块的向量计算更快)。

所以分块就是将输入文档或大段文本切分成多个较小的、可控粒度的“块”，以便后续的向量化检索和生成模块高效调用与组合。

在 RAG 中，常见的分块策略有哪些？分别有什么区别？

常见的分块策略包括自然结构分块、固定大小分块、滑动窗口分块、递归分块、语义分块及混合分块这六个。

  • 自然结构分块：按文档原有格式拆分，比如遇到标题、空行、章节编号、标点符号(如 ###、\n\n、句号) 就分块。
  • 固定大小分块：将文本按固定字符数、词数或 token 数等均匀切分，简单易实现。
  • 滑动窗口分块：在固定大小基础上为相邻 chunk 保留一定重叠，以减少上下文出现断裂
  • 递归分块：先按段落/章节粗分，超长部分再递归细化(按句子或空行)，适合复杂文档
  • 语义分块：用 NLP 模型(如 BERT、GPT)判断文本语义边界，确保每个块是完整的语义单元(比如一个论点、一个案例)
  • 混合分块：同时结合固定、滑动、语义等策略，或依据标题、段落层级自适应切分，实现性能与精度平衡，比如在初始阶段使用固定长度快读分块，在后续阶段画通过语义分块进行更精细的分块。

在 RAG 中的 Embedding 嵌入是什么？

简单说，就是把文本内容、图像、音频、视频等形式的信息映射为高维空间中的密集向量(一串数字)，这个过程叫“嵌入”(Embedding)。

向量就是空间中的坐标，捕捉对象之间的语义关系和隐含的意义、每个向量就像文本的“数字指纹”，包含了文本的语义信息，比加“猫”和“狗”的向量会很接近，“开心”和“悲伤”的向量会远离，即语义相近的对象在向量空间中彼此邻近，而语义相异的对象则相距较远。

然后通过在向量空间中进行数学计算(如余弦相似度)，判断两段话是否相关(比如用户问题和文档块的匹配)

因此，分块后的文本块需要先生成Embeding，存入向量数据库(如 FAISS)，用户提问时，系统通过计算提问的 Embeding 与文本块的 Embeding 相似度，找到最相关的内容，再交给大模型生成回答。

在 RAG 中，你知道有哪些 Embedding Model 嵌入模型？

在 RAG 中，常用的 Embedding Model(嵌入模型)主要分为以下几类:

  • text-embedding-ada-002(2022年12月发布)：OpenAI 的第二代模型，支持多语言，性价比高，适合大多数场景(如文档检索、相似度匹配)
  • text-embedding-3-small(large) : OpenAI 推出的第三代高效模型，性能更强，MIRACL (mutil language retrieval)比上代 31.4%提升到了44.4%，MTEB(Massive Text Embeding Benchmark)从 61.0%提升到了62.3%，且价格更低。
  • Sentence-BERT(SBERT)：基于BERT优化，大幅提升句子嵌入速度和相似度计算效果，开源目免费(如 all-mpnet-base-v2性能最好，而 all-MinLm-L6-v2 速度最快)
  • Gemini Embedding：在 MTEB 基准测试中表现出色，目前排名第一。
  • Cohere Embed：有embed-english-light-v2，embed-english-v3等模型
  • BGE(BAAl GeneralEmbedding)：智源研究院研发，专为中文优化(如bge-large-zh)，在中文MTEB榜单排名前列,。
  • M3E(Moka Massive Mixed Embedding)：开源轻量模型，专为中文优化，适合本地部署

对我们实战而言：中文选BGE/M3E，英文选OpenAl/Cohere，轻量部署选Sentence-BERT。

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？

在 RAG 中选择 Embedding Model 时，核心考虑7大因素，分别是“准、快、专、广、大、活、省”

  1. 准(语义准确性)：模型能否精准捕捉文本语义(比如长句理解、上下文关联、同义词区分)，直接影响向量相似度计算的可靠性
  2. 快(模型效率)：推理速度是否满足业务实时性要求(比如 QPS 高的场景不能用太大的模型)，显存/内存占用是否适配硬件资源。
  3. 专(领域适配)：是否针对垂直领域(如法律、医疗、代码)做过预训练或微调，原生支持特定术语和逻辑(比如金融模型懂“PE 估值”，通用模型可能误解为“体育器材")。
  4. 广(多语言支持)：是否支持业务所需语言(尤其是小语种)，以及跨语言对齐能力(比如中英混合文本能否正确嵌入)。
  5. 大(数据规模匹配)：模型参数量和训练数据规模是否匹配你的语料复杂度(小数据用大模型可能过拟合，大数据用小模型可能语义坍缩)
  6. 活(开放性与生态)：是否开源、是否有活跃社区维护(方便定制化微调)，API 调用是否灵活(比如 OpenAl Embeding 适合快速上线，Hugging face 模型适合自建部署)
  7. 省(成本)：计算成本(训练/推理的硬件投入)和使用成本(比如第三方 API 的 token 费用，商用模型的授权费)

在 RAG 中，索引流程中的文档解析你们怎么做的？

在 RAG 的索引流程中，文档解析主要分 5大核心步骤，分别是“读、洗、拆、标、存”

  1. 读(文档加载)：支持多格式解析 (PDF/Word/Markdow/HTML/图片等)，用工具库(如 PyPDF2 读PDF、Docx2Text 读 Word、Unstructured 处理复杂格式)
  2. 洗(文本清洗)：去除噪声(如页眉页脚、乱码、重复内容)，标准化文本(统一大小写、替换特殊符号)，处理多语言混合文本(如中英夹杂时保留语义完整性)。
  3. 拆(文本分块)：按 语义单元拆分成合适长度的“知识块”(常见分块策略)。
  4. 标(元数据标注)：给每个知识块附加 来源信息(文档标题/URL/作者/上传时间)、结构信息(章节标题/段落位置)、领域标签(如“产品手册”“用户协议”)，方便后续检索时过滤和排序
  5. 存(结构化输出)：将分块后的文本和元数据整合成 索引系统能识别的格式(如JSON/CSV)，输出给向量数据库(如 FAISS/Easticsearch)或传统搜索引擎建立索引。

在 RAG 应用的过程中，关于提示工程的设计有什么心得和技巧吗？

在 RAG 应用中，提示工程的核心设计技巧主要有以下几点：

  1. 明确角色和任务：提示中要清楚说明 AI 的身份、能力边界和目标任务
  2. 结构化提示：用明确的格式指导 AI 输出，比如：“背景 + 问题 + 输出格式”。
  3. 加上下文约束：明确告知 AI 只能基于检索到的资料回答，避免“幻觉”
  4. 模板化设计：将提示设计成模板，方便大规模复用和动态填充检索内容
  5. 加入冗余兜底机制：如没检索到相关内容，就让 AI 显式回复 “未找到相关资料”
  6. 给几个示例：给 1-2 个优质问答范例，让模型模仿输出风格和逻辑。

什么是 Advanced RAG？

Advranced RAG(高级检索增理生成)是传统 RAG (native 检索增强生成)的升级版，核心是通过检索前、检索中、以及检索后的优化解决传统 RAG 的痛点(如检索不精准、上下文断裂、生成质量不稳定等)

  1. 检索前：通过滑动窗口分块、元数据添加、分层索引、查询重写、查询扩展以及向量化等技术进行优化
  2. 检索中：通过动态嵌入、混合检索、文档嵌入、递归块合并等手段进行优化
  3. 检索后的优化：通过重排序、提示压缩、上下文重构、内容过滤等手段进行优化

什么是 Modular RAG？

Modular RAG(模块化检索增强生成)是将传统的 RAG 系统拆分成一系列松耦合、可重组的功能模块，每个模块各司其职(如检索、检索前处理、检索、检索后处理、生成等环节进行模块化设计)，
并由一个统一的负责调度与“编排器”路由，让整体系统更灵活、可插拔、易维护。

几个核心模块

  1. Indexing(索引)：对文档进行块优化(如拆分小句、合并大段保留上下文)、结构组织(分层处理 PDF 等文档)，并构建知识图谱，让知识存储更有序，便于快速检索
  2. Pre-Retrieval(检索前)：通过查询转换(如将口语化提问转为精准指令)、查询扩展(补充相关关键词)等，让检索目标更清晰
  3. Retrieval(检索)：采用混合检索(向量+ 关键词)、选择不同检索源(句子、文档块、结构化数据)，精准召回相关内容。
  4. Post- Retrieval(检索后)：对检索结果重排序(筛选最相关内容)、压缩(剔除冗余信息)，提升输入质量。
  5. Generation(生成)：利用大模型生成回答，并通过外部知识验证回答准确性，避免“幻觉”。

如何优化 RAG 的检索效果？

这个问题必然要从 RAG 的流程入手，看我们能干预的步骤有哪些，总结来说 RAG 检索效果的优化主要可以分为以下几个方面：

  1. 文档预处理与切片优化
    • 高质量文档：原始文档内容不行一切都白搭，所以要保证知识库中的原始文档内容准确、结构清晰、格式规范，尽量减少噪音(水印、不相关图片)。
    • 智能切片：采用合适的文档切片策略。切片过小可能导致语义不完整，过大则可能引入过多无关信息。可以考虑基于语义边界或智能分块算法，避免固定长度切分导致语义断裂，SpingAl 的 TokeTextspliter 就提供了基于 Token 的文本分割，也考虑了语义边界。
    • 元数据标注：为文档切片添加合话的元数据(来源，日期、类别，标签)，后续进行更精确的过滤和检索都能使用到。
  2. 查询增强
    • 查询重写：使用大模型把用户的原始查询改写的更清晰、更详细、更规范，提高后续检索的准确性。
    • 查询扩展：将用户的单个查询扩展为多个语义相近的查询，然后合并检索结果，提高召回率。例如，将“Seven是谁”扩展为“程序员Seven介绍”、“Seven的技能”等。
    • 查询翻译：如果知识库和用户查询的语言不一致，可以把查询翻译成知识库的语言。
  3. 检索器配置与策略
    • 相似度调值：合理设置检索时返回文档的相似度阈值和数量，阈值过高可能漏掉相关文档，过低则可能引入噪音；返回文档过多会增加后续处理成本和模型幻觉风险，这些参数都需要根据具体场景进行调试。
    • 元数据过滤：用预先标注的元数据对检索范围进行精确过滤，只在特定子集文档中搜索，提升检索的相关性和效率。
    • 混合检索策略：结合不同检索方法的优势，像关键词检索、向量检索、知识图谱检索等。比如先用向量检索召回语义相关的文档，再用关键词过滤精确匹配,。
  4. 嵌入模型的选择与优化：选择高质量的嵌入模型对文本进行向量化，这会直接影响语义相似度计算的准确性。
  5. 重排：在召回多个文档后，可以用更复杂的排序模型对初步检索到的结果进行重新排序，把更相关、质量更高的文档排在前面。

什么混合检索？在基于大模型的应用开发中，混合检索主要解决什么问题？

混合检索 是指在基于大模型的 RAG(检索增强生成)应用中，结合向量检索和关键词检索等检索技术的互补优势，提升检索结果的全面性和准确性。

它主要为了提升大模型的上下文理解和回答准确性，因为向量检索擅长语义理解(如“省南猎老鼠”与“猫追逐老鼠”的关联)，但准以精准匹配专有名词(“iphone 15”)或缩写(如“RAG”)；关键词检索则反之。

所以在大模型 RAG 应用中，混合检索主要通过并行两种检索方式实现:

  • 向量检索：将文本转化为高维向量，计算语义相似度
  • 关键词检索：基于倒排索引、BM25等算法，精确匹配关键词(例如“GPT-4”必须完全命中)。

两种结果通过权重融合或重排序模型(如RRF)合并，最终输出最优答案。

在工程上例如 ElasticSearch 就同时支持关键词检索和向量检索，可以使用工具链例如 Llamaindex+ ElasticSearch 实现混合检索

什么提示压缩？为什么 RAG 中需要提示压缩？

在RAG(检索增强生成)中，提示压缩主要指对检索出的文档内容进行精简处理通过提取核心信息、过滤无关文本、压缩冗长内容、使最终输入大模型的"提示"(包含用户问题+文档片段)既完整保留关键信息，又符合模型输入长度限制。

例如：检索到一篇10页的技术白皮书，压缩后仅保留与用户问题相关的2个核心章节和关键数据，避免无关段落占用模型上下文空间。

为什么在RAG中需要提示压缩？RAG的生成效果高度依赖“输入给模型的文档质量”，而检索出的文档通常存在三大问题，必须通过压缩解决：

  1. 控制输入长度: 大语言模型都存在输入长度限制，直接拼接大量检索内容可能会超出模型的上下文窗口，通过压缩可以将关键信息浓缩进有限的 token 内。
  2. 提高知识相关性：检索出的文档中可能有大量无关内容(重复描述、背量知识、与问题无关的案例)会稀释关键信息，导致模型聚焦困难(例如用户问"如何优化代码"。文档中80%是算法原理，仅20%的优化技巧，未压缩时模型可能错误引用原理部分生成回答)，甚至引发“幻觉”。
  3. 降低计算资源消耗:：减少不必要的内容可以降低模型处理和推理的计算负担，如果调用的是商业大模型，还涉及到金额问题(都是通过 token 来计费的)。

当发现RAG系统召回结果与用户query意图不匹配时，有哪些可能的改进方向？

当 RAG 系统的召回结果与用户查询意图不匹配时，我们可以从以下三个主要环节进行优化：

  • 预处理阶段优化
    • 数据清洗：删除无关文本、特殊字符和噪声数据,纠正拼写和语法错误。
    • 元数据增强：为文档添加概念标签、层级信息等元数据,提升检索效率。
    • 分块策略：根据具体任务调整chunk大小,确保信息完整性和相关性。
  • 检索阶段优化
    • 混合检索：结合关键词检索(BM25)和语义检索(向量检索)的优势。
    • 查询重写：使用 LLM 从不同角度重写用户查询,生成多个查询变体。
    • 重排序：对检索结果进行二次排序,提升最相关文档的排名。
  • 后处理阶段优化
    • 上下文压缩：压缩和过滤不相关的上下文内容,
    • RAG Fusion：结合多查询检索和文档重排序,提高检索准确性。

如何进行 RAG 调优后的效果评估？请给出真实应用场景中采用的效果评估标准与方法

RAG调优后的效果评估可以围绕这三个维度来看：检索质量、生成质量、系统性能。

检索质量评估:

  1. 客观指标
    • Precision@k(前k个结果的相关性比例)
    • MRR(首个相关结果的排名倒数均值)
    • NDCG(文档相关性等级和排名折扣，区分不同相关度的重要性)
    • Recall@k(覆盖所有相关文档的比例)
  2. 主观评测：通过人工审核检索结果是否满足业务需求。

生成的质量评估

  1. CR检索相关性(Context Relevancy)(答案是否基于检索内容)
  2. AR 答案相关性(Answer Relevancy)(回答是否解决用户问题)
  3. F可信度(Faithfulness)(评估生成的答案中是否存在幻觉)

评测方法：

  • 大模型打分(利用大模型评估答案质量)
  • 人工打分(对CR、AR、F评分)。

系统性能评估
除了功能性需要外，我们作为应用开发，也要关注下非功能性需求

  • 延迟(响应时间)
  • 吞吐量(单位时间处理请求量)
  • 错误率(生成错误答案的比例)

在真实的企业场景流程中，我们先:

  1. 分层测试：先测检索质量，再测生成质量，最后压测系统性能。
  2. 持续监控：上线后实时跟踪用户满意度(这也是现在大模型回复都有点评功能)、业务指标(如问题解决率)

协议

A2A 协议有哪五大设计原则

A2A 是一种开放协议，为代理之间的协作提供了一种标准方式，与底层框架或供应商无关。协议遵循以下几个核心原则:

  • 拥抱 Agentic 能力。A2A专注于使 agent 能多以自然、非结构化的方式进行协作，即使它们不共享内存、工具和上下文，我们正在实现真正的 multi-agent场景，而不会将 agent限制为“工具”。谷歌正在启用真正的多 agent场景，而不是限制 Agent 成为一个工具。
  • 建立在现有标准之上。该协议建立在现有的流行标准之上，包括 HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有 IT 栈集成。
  • 默认安全。A2A 旨在支持企业级身份验证和授权，在发布时与 OpenAPI的身份验证方案具有同等效力。
  • 支持长时间运行的任务，我们设计了A2A，使其具有灵活性，并支持从快速任务到保度研究的各种场景，当人类处于循环中时，这些场最可能需要数小时甚至数天才能完成，在整个过程中，A2A可以向用户慢供实时反馈、通知和状态更新
  • 模态无关。代理世界不仅限于文本，这就是为什么我们设计了 A2A 来支持各种模态，包括音频和视频流。

什么是 A2A 协议，它的核心架构及主要组件有哪些？

A2A(Agent-t0-Agent)协议是由 Goodle 主导开发的开放协议，旨在实现不同 AI 智能体之间的互操作性，使它们能够跨平台、跨框架地协作。其核心架构包括以下主要组件：

  • AgentCard(代理卡片)：一个公开的JSON 文件，描述代理的能力、技能、端点 URL 和身份验证要求，用于客户端发现代理。
  • A2A Server(A2A 服务器)：实现 A2A 协议方法的 HTTP 端点，接收请求并管理任务执行。
  • A2A Client(A2A 客户端)：发送请求(如 tasks/send )到 A2A 服务器的应用程序或其他代理。
  • Task(任务)：客户端发起的工作单元，具有唯一的ID，并通过状态(如 submitted、working)进行跟踪。
  • Message(消息)：客户端与代理之间的通信回合，包含Parts。
  • Part(部分)：消息或工件中的基本内容单元，可以是文本、文件或结构化 JSON。
  • Artifact(工件)：代理在任务中生成的输出(如生成的文件、最终的结构化数据
  • Streaming(流式传输)：对于长时间运行的任务，支持使用 tasks/sendsubscribe，客户端通过服务器发送事件(SSE)接收任务状态更新。
  • Push Notifications(推送通知)：支持的服务器可以主动将仟务更新发送到客户端提供的 webhook URL

A2A 协议采用 JSON-RPC 2.0 通过 HTTP 进行消息交换，对于流式传输，使用 SSE 协议。

A2A 协议的工作原理是怎样的？

A2A协议的核心作用是让“客户端代理”和“远程代理”之间顺利沟通，客户端代理负责创建并下发任务，而远程代理则根据这些任务提供信息或执行操作，整个过程中，A2A 提供了几个关键功能。

  • 能力发现：每个代理都有一张“Agent 卡”，以 JSON 格式描述它能做什么，客户端Agent可以通过这些卡片，找到最适合执行当前任务的远程Agent，并通过 A2A 协议与之建立通信。
  • 任务管理：客户端与远程代理的交互围绕任务展开，每个任务都有一个由协议定义的“任务对象”，并且具有生命同期，有些任务可以立刻完成，而对于运行时间较长的任务，代理之间可以将续沟通，保持状态同步，确保任务按预期推进。任务完成后会产生一个“工件”，也就是最终的执行结果。
  • 协作能力：代理之间可以直接通信，发送包含上下文、回复、工件或用户指令的消息，便于协同完成更复杂的任务。
  • 用户体验协商：每条消息可以包含多个“部分”，每部分代表一个完整的内容片段，比如生成图像，每个部分都有明晚的内容类型，客户端和远程代理可以据此协商最合适的展示格式，同时也可以决定是否支持如iframe、视频、网页表单等用户界面功能，从而根据用户需求和设备能力，提供更好的使用体验。

A2A 协议的工作流程是怎样的？

  1. 发现：客户端向/.well-know/agent.json 发起HTP GET 请求，获取远端智能体的 AgentCard，其中包含智能体的唯一标识、能力清单、回调URL、认证方式等元数据，帮助客户端快速了解并筛选合适的智能体来执行任务
  2. 启动：客户端根据业务需求生成准一的Task ID，然后通过 JSON-RPC 调用tasks/send(用于一次性请求，同步返回最终 Task对象) 或 tasks/sendSubscribe (用于订阅式清求，服务端通过 Server-Sent Events 推送状态更新) 向目标智能体发送任务请求。
  3. 处理：远端智能体接收请求后，将任务状态从submitted 切换到 working，在内部执行模型推理或外部工具调用；对于订阅式任务，会持续性推送 TasksStatusUpdateEvent 和可选的 TaskArtifactUpdateEvent，让客户端实时获取讲度或中间成果。
  4. 交互：当智能体在处理过程中需要额外输入时，会发出 input-required 状态更新，并携带一条 Message 请求;客户端收到后可使用相同 TaskID 通过(tasks/send 或 tasks/sendSubscribe 补充用户输入。保持会话的连续性和上下文一致。
  5. 完成：任务进入终态(completed、failed或 canceled)，客户端可以选择主动拉取最终的 Task对象，也可以继续通过SSE或 Webhook机制订阅 TaskStatusUpdateEvent，并获取以 JSON Artifact J形式封装的最终结果

A2A 协议 与 MCP 协议的关系是怎样的？

标准化协议：在智能体与外部系统之间实现互操作，标准化协议至关重要。它主要聚焦两个密切关联的领域：工具与智能体

  • 工具是具有结构化输入输出、预定义行为的基本单元;
  • 智能体则是能够调用工具、进行逻辑推理并与用户互动，从而完成新任务的自主应用。要真正满足用户需求，必须让智能体与工具协同工作，既发挥工具的专长，又利用智能体的灵活性

互补性协议：在这种背景下，A2A和 Anthroptc发布的 Model context protocol (MCP)正好形成互补，可以把A2A想象成智能体之间的“电活薄”，负责发现、呼叫和协作；而 MCP则像工具的“使用说明书”，为智能本接入外部数据源和服务提供统一接口。两者结合，才能构建既能高效联动工具，又能自由组织多方智能体的完整生态。

下面具体介绍下:

A2A 协议与 MCP 协议是两个在 AI 生态系统中扮演不同角色但又互补的标准协议。

  1. MCP (ModelContext protocoa):由 Anhropic 于2024年发布，旨在为 模型提供与外部数据源和工具的标准化连接方式。它允许模型通过统一的接口访问文件、数据库、API等资源，实现“函数调用”功能的标准化。MCP采用JSON-RPC2.0 协议，支持多种传输方式。如 STDIO和 HITP+SSE，它的核心在于提供一个“工具说明书”、让 AI模型能够安全，高效地与外部系统交豆
  2. A2A Aent20:Aen) 协议：这是一个应用层物议，旨在实现 AI 智能体之间的自然语言协作，A2A允许不同的 AI 智能体之以" 智能体之”或“用户”的身份进行交流，而非仅仅作为工具被调用，它更关注 智能体之之间的沟通和协作，促进多智能体系统的协同工作。

两者的关系可以通过以下比喻来理解:

  • MCP 就像是一个“工具说明书”，告诉 AI 模型如何使用外部工具和数据。
  • A2A 就像是一个“电话簿”，让不同的 AI 智能体能够相互联系和协作。

因此，A2A 和 MCP 是互补的协议，共同推动了智能体生态的发展。

什么是 MCP 协议，它在 AI 大模型系统中的作用是什么？

MCP (Model Context Protocol,模型上下文协议)起源于2024年11月25 日 Anthropic 发布的文章：Introducing the Model context Protocol。旨在为大型语言模型(LLMs)和 AI助手提供一个统一、标准化的接口，使其能够无缝连接并交互各种外部数据源、工具等，让模型不依赖于预则练数据，还能在需要时动态获取最新的上下文信息、调用外部工具、执行特定任务。简单来说，它为 应用架构提供了一种“即插即用”的方式，类似于 USB-C让不同设备能够通过相同的接口连接一样。

MCP的目标是创建一个通用标准，使AI 应用程序的开发和集成变得更加简单和统一

可以将 MCP(模型上下文协议)比作AI 世界中的 USB-C接口。在传统的计算机环境中，只要外设(如盘标、键盘或U盘)符合 US8标准，系统便能只别并使用它们，同样地，MCP为大型语言模型 (LLM) 提供了一个统一的通信协议使得各种数据源和工具只需遵循 MCP的规范，便可与LLM无缝对接，这意味着，无论是数据库、API还是其他服务，只要通过 MCP 接入，LLM 都能理解并利用这些资源，从而扩展其功能和应用范围。

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

  • 标准化数据接入：通过 MCP，我们无需为每个模型编写单独的代码，而是通过统一的协议接口，实现一次集成，随处连接。这大大简化了模型与外部系统的集成过程。
  • 增强模型能力：MCP 使得模型能够实时访问最新的数据和工具，例如直接从 GitHub 获取代码库信息，或从 本地访问文件。这不仅提升了模型的实用性，也拓展了其应用场景。
  • 提升系统可维护性：通过标准化的协议，系统的各个组件可以更加模块化地协作，降低了维护成本和出错概率。

MCP 为啥如此重要?

以前，如果想让AI处理我们的数据，基本只能靠预训练数据或者上传数据，既麻烦又低效。而且，就算是很强大的AI 模型，也会有数据隔离的问题，无法直接访问新数据，每次有新的数据进来，都要重新训练或上传，扩展起来化较困难

现在，MCP 解决了这个问题，它突破了模型对静态知识库的依赖，使其具备更强的动态交互能力，能够像人类一样调用搜索引擎、访问本地文件、连接 API 服务，甚至直接操作第三方库，所以 MCP相当于在 AI 和数据之间架起了一座桥。不管是获取最新的天气和新闻，还是进行数据分析、自动化办公，都能轻松搞定，更重要的是，只要大家都遵循MCP这套协议，AI 就能无缝连接本地教据、互联网资源、开发工具、生产力软件，甚至整个社区生态，实现真正的 “万物互联”，这将极大提升 Al的协作和工作能力，价值不可估量。

MCP 架构包含哪些核心组件？

MCP 的核心是客户端-服务器架构，其中主机应用程序可以连接到多个服务器

  • MCP 主机：希望通过 MCP 访问数据的程序，例如 Claude Desktop、IDE 或 AI 工具。
  • MCP 客户端：与服务器保持 1:1连接的协议客户端
  • MCP 服务器：轻量级程序，通过标准化的 MCP 协议向客户端提供特定功能，如数据源、工具和API接口等
  • 本地数据源：MCP 服务器可以安全访问用户的计算机文件、数据库和服务。
  • 远程服务：MCP 服务器可通过互联网(例如通过 API)连接到的外部系统。

MCP 协议支持哪两种模式？

MCP 协议支持两种主要的通信模式，即标准输入输出(Stdio)模式和 服务器发送事件(SSE)模式:

  • 标准输入输出(Stdio)模式：基于 Stdio 的实现是最常见的 MCP客户端方案，它通过标准输入输出流与 MCP 服务器进行通信，这种方式简单直观，能够直接通过进程自通信实现数据交互，避免了额外的网络通信开销，特别适用于本地部署的MCP服务器，可以在同一台机器上启动 MCP 服务器进程，与客户端无缝对接。
  • 服务器发送事件(SSE)模式：这个方案相较于Stdio 方式，SSEE 更适用于远程部署的MCP服务器，比如分布式系统或需要网络实对推送的场景。客户端可以通过标准HTTP 协议与服务器建立连接，实现单向的实时数据推送送。基于 SSE的 MCP服务器支持被多个客产端的远程调用。

MCP 与 Function Calling 的区别是什么？

MCP是一个抽象层面的协议标准，它规定了上下文与请求的结构化传递方式，并要求通信格式符合JSON-RPC2.0 标准，它提供了标准化的通信机制，确保不同模型之间的兼容性，我们只需按照协议开发一次接口，即可被多个模型调用，避免了为每个模型单独适配的繁琐工作。

Function calling则是某些大模型(如 OenpenAI的GPT-4)提供的特有接口特性，它以特定的格式让 LLM 能产出一个函数调用清求，然后应用可以读取这个结构化的请求去执行对应的操作并返回结果。但这个特性本身并不要求消息一定是JSON-RPC格式，也不一定遵守 MCP的上下文管理方式。它是由大模型服务提供商定义的一种调用机制，与MCP 所定义的协议与标准没有内在依赖或直接关联。

其实MCP和Function calling两者是完全不同层面的东西，MCP是一个更底层、更通用的抽象标准，相当于一个基础设施。而 Function calling 则是大模型一个特定的服务，更偏向于具体实现，以支付系统来举例子，以前的 Function calling 相当于请求各个支付系统，微信，支付宝，银联，每个系统都需要单独对接，而 MCP相当于支付网关，只需要对接支付网关，后面对接各种支付系统都是支付网关做，我们不用管。因此 MCP协议通过统一 通信规范和资源定义标准，实现了“一次开发，全平台通用”的目标。借助 MCP，我们只需按照协议开发一次接口，便可无缝适配 ChatGPT、DeepseeK等不同模型，显著降低了集成成本和复杂性。

MCP 的工作流程是什么？

  1. 初始化连接：主机应用程序(如 Claude Desktop 或 IDE 插件)启动并初始化 MCP 客户端，每个客户端与一个 MCP 服务器建立连接
  2. 获取工具列表：在系统初始化阶段，MCP ient 首先从 MCPserver获取可用的工具清单和能力描述，这些工具可以是 API、脚本、数据库查询方法等。这个步骤相当于“能力注册”，让模型知道有哪些可以用的“"外部技能”
  3. 构造 Function Calling 请求：当用户输入一个问题后，MCP Cient会将这些工具描述(包括参数、用途、返回值等)一并传给 LLM，传输方式采用Function Calling，即结构化地把“能用的函数长什么样”告诉模型，让它来决定是否要使用。
  4. 模型智能判断是否调用工具：LLM 根据当前对话上下文以及工具信息判新是否要使用某个工具，并决定调用哪一个、传入什么参数。这个阶段完全由模型推理完成，比如它可以判断“这题需要查天气，那我就调用 getWeather工具”
  5. 工具调用执行阶段：如果模型发起调用请求，MCP Cient 会根据模型的选择，通过 MCPServer发起工具调用。这一步是真正的“执行动作”。MCP Server 去实际跑工具的逻辑，并把结果返回给客户端,
  6. 结果返回与模型整合：工具执行结果(比如调用 API得到的数据)被传回 LLM，由模型将这个结果与原始用户问题、已有上下文等信息整合，生成最终的自然语言回应。
  7. 用户响应输出：最后，MCP Client 将模型生成的回答展示给用户，完成一次完整的“智能+工具”协作流程。

MCP 协议安全性设计包含哪些层面？

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

  • 用户同意和控制：所有模型对工具、资源和是示的访问请求都必须经过用户的授权，主机负责管理权限、提示用户批准，并在必要时阻止未经授权的访问，用户必须知道哪些数据是需要提供给大模型的，用户在授权使用之前了解每个工具的功能
  • 隔离与沙箱机制：MCP的设计将实际工具调用封装在MCP Server内部，模型本身无法直接访问敏感数据、这种“中间层”设计有效地降低了直接暴露内部业务系统的风险。同时，沙箱加制可以限制工具调用的执行环境，防止任意代码执行或恶意操作对系统造成破坏。
  • 加密传输与来源验证：MCP 内置了安全机制，确保只有经过验证的请求才能访问特定资源，相当于在数据安全又加上了一道防线，同时，MCP协议还支持多种加密算法，以确保数据在传输过程中的安全性。

如何将已有的应用转换成 MCP 服务？

要将现有应用转换为 MCP服务，需将其功能封装为标准化的 MCP工具(Tools)、资源(Resources)或提示(Prompts)，并通过MCP Senver 对外暴露，这一过程涉及以下关键步骤：

  • 梳理功能模块：识别应用中要提供给外部调用的功能，如 API 接口、数据查询、文件处理等
  • 创建单独的MCP 服务：创建一个新的MCP 服务，与已有的业务服务隔离开，通过单独的 API或者 SDK 和业务服务通信。
  • 定义工具：定义 MCP 服务需要包含的工具功能描述、方法入参字段和描述、方法返回的字段和描述。
  • 实现 MCP Server：根据 MCP 协议规范，构建一个 MCP Server，负责接收 MCP 客户端请求、调用相应功能模块，并返回结果。

SpringAI

什么是 Spring AI 框架？它有哪些核心特性？

Spring AI 是一个基于 Sprng生态系统的 AI 应用开发框架，主要目标是简化AI功能与Spring应用的集成，它通过提供统一的 API 和抽象，让 Java 开发者可以更便捷地接入和使用各种 AI 大模型及相关技术，忽路底层实现的差异。通过官网，我们可以了解到 Spring Al 框架有以下核心特性：

  • 跨 AI 供应商的可移植 API 支持：为聊天、文本转图像和嵌入模型提供了统一的 API，支持同步和流式调用，支持访问特定模型的功能
  • 广泛的 AI 模型供应商支持：支持包括 OpenAI、微软 Azure、Anthropic、Google、Ollama 在内的主流 AI 模型供应商。
  • 结构化输出：能够将 AI模型的输出自动映射到 POJO，方便在 Java 应用中处理。
  • 向量数据库集成：支持与多种主流向量数据库的集成，还提供了跨向量存储的可移植 API
  • 工具/函数调用 (Tool/Function Calling)：支持模型请求执行客户端定义的工具和函数，扩展模型的能力
  • ETL框架：提供了文档抽取、转换和加载(ETL)的组件，用于数据工程和 RAG 知识库的构建。
  • Spring Boot 自动配置与启动器：为 AI 模型和向量存储提供了自动配置和 Starter 依赖，简化项目配置
  • ChatClient API：提供了类似于 WebClient 和 RestClient 的流式AP|，提高与 AI 模型交互的便捷性。
  • Advisors API： 一种拦截器机制，封装了常见的 AI 功能，如对话记忆、RAG 等，还支持自定义，可以在调用 AI 前后执行额外操作

这些特性共同构成了 Spring Al 框架的基础,提升 AI 应用的开发效率和可维护性

你在 AI 智能体项目中如何利用 Spring AI 开发应用？用到了哪些特性？

  • 大模型接入与调用：使用 spring-ai-alibaba-starter 和 spring-ai-ollama-spring-boot-starter 简化大模型的配置和集成。通过 Spring Al 的 chatmodel 和更高级的 chatclient API 与 Al 大模型交互，实现对话功能。
  • Advisors：
    • 利用 MessagechatMemoryAdvisor 实现了多轮对话中的上下文记忆功能。
    • 为了增强应用的可观测性，我还自定义了Advisor，例如用于记录 AI 请求和响应日志的MyLoggerAdvisor，以及用于尝试提高模型推理能力的 ReReadingAdvisor。
  • 对话记忆：
    • 项目初期使用了基于内存的 InMemorychatMemory
    • 为了实现对话记忆的持久化，我自定义了 FileBasedChatmemory，并使用 Kryo 序列化库解决了 message 对象层级复杂难以直接序列化的问题
  • 结构化输出：通过 Spring Al 的结构化输出转换器，我把 AI 模型的文本输出直接转换为Java 对象，方便后端处理和使用。
  • Prompt 模板：利用promptTemplate 管理和动态生成提示词，比如使用占位符替换变量、从外部文件加载复杂的提示词模板，提高了提示词的可维护性和灵活性。
  • RAG (检索增强生成):
    • 文档EL：使用了 SpningAl 的 ETL Pipeine 组件，如 MarkdownDocumentReader 加载本地Markdowm知识库文档、TokenTextspliter 进行文本分割、keywordMetadatatEnricher 自动为文档添加关键词元数据。
    • 向量存储：集成 simplevectorstore 和 pgvectorstore 用于存储和检索文档向量，在集成pgvectorstore 时，我还解决了多个Embedingpodel Bean 冲突的问题。
    • 检索与增强：使用 QuestionAnswernAdvisor 和更灵活的 RetrievalAugmentationAdvisor 实现 RAG 流程，后者还结合了 VectorstoreDocumentRetriever 和 ContextualQuenyAugmenter 等组件进行查询优化和空上下文处理，还实践了查询重写(RewriteQueryTransformer)等预检索优化技术。
  • 工具调用(Tool Calling)：
    • 通过 @Rool 和 @Toolparam 注解定义了多种外部工具，如文件操作、联网搜索、PDF生成等，并使用 chatclient 的 too1s()方法将这些工具注册给 AI 模型，让AI 能够调用这些工具完成特定任务。
    • 在构建智能体时，我手动控制了工具的执行流程(ReAct模式)，通过 DashScopeChatOptions 禁用 Sping Al 内部的自动工具执行，更方便、更精细地管理思考-行动循环。
  • MCP(模型上下文协议)集成：
    • MCP客户端：使用spring-ai-mcp-client-spring-boot-starter，配置 stdio 和 SSE 连接方式来调用外部MCP服务，通过 Toolcallbackprovider 将 MCP服务提供的工具无缝集成到chatclient的工具调用机制中。
    • MCP服务端：基于 spring-ai-mcp-server-webmvc-spring-boot-starter 开发了自定义的图片搜索 MCP 服务，使用 @Tolls 注解暴露工具，然后通过 Toolcallbackprovider Bean 进行注册。

我综合使用了 Spring Al 的这些特性，大大简化了开发过程。

如何实现程序和 AI 大模型的集成？有哪些方式？

最终，在项目中我主要使用的是 Spring Al框架接入:

  • 它属于 Spring 生态，更主流
  • 利用官方提供的 Spring Boot Starter 可以轻松整合各种第三方依赖(比如向量数据库和 MCP)
  • 简单易用，满足大多数 AI项目的开发需求

如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？

多轮对话功能的关键在于让AI具备“记亿能力”，即能够记住与用户之前的对话内容并保持上下文连贯。

在我做的AI项目中，我使用了 Sping AI 框架提供的对话记忆(Chat Memory) 和 Advisor 特性来实现这个功能。

具体实现操作上来说，我主要通过构造 chatclient 来实现功能更丰富、更灵活的AI对话。chatclient支持使用Advisors，可以理解为一系列可插拔的拦载器，在调用 Al 前后执行额外操作，其中MessageChatMemoryAdvisor 就是实现多轮对话的关键Advisor，它的作用是从对话记忆中检索历史对话，并将对话历史作为消息集合添加到当前的提示词中，实现让 AI 模型能够“记住”之前的交流。

MessageChatMemoryAdvisor 依赖于 chatmemory 接口的实现来存取对话历史。 chatmemory 接口中定义了保存消息、查询消息和清空历史的方法。默认情况下会使用 InMemoryChatMemory 实现，从这个类名可以看出对话记忆仅存在于内存中，一旦服务重启，记忆就会丢失。为了解决这个问题，需要将对话记忆持久化。Sping AI 提供了多种特久化方案，例如 JdbChatMemory 可以将对话保存在关系型数据库中，但是在本项目中，考虑到 spring-ai-starter-model-chat-memory-jdbc 依赖版本较少且缺乏相关介绍，我选择了自定义实现chatMemory 接口的方式：

  1. 开发一个 FileBasedchatMemory类，它实现了 chatMemory 接囗。
  2. 使用高性能的 Kyro 序列化库将对话消息(Message 对象及其子类)序列化后保存到本地文件中，读取时再进行反序列化。选择 Kyro 是因为 Message 接口有多种实现，结构不一，且没有无参构造和 Serializable 接口，普通的JSON 序列化难以处理。

通过这种方式，我将对话的上下文信息持久化到了指定的文件目录，解决了内存记忆丢失的问题.

什么是结构化输出？Spring AI 是怎么实现结构化输出的？

结构化翰出是指将大语言模型返回的自由文本输出转换为预定义的数据格式，像JSON、XML 或特定的 Java 类(POJO)，对于需要可靠解析 AI 输出值并进行后续处理的需求来说非常重要Spring Al 通过 StructuredOutputConverter 机制实现结构化输出，其工作流程可以分为调用前和调用后两个阶段：

  • 调用前：StructuredOutputConverter 实现了 FormatProvider 接口。FormatProvider 的作用是提供特定的格式指令给 AI 模型，这些指令会附加到用户的提示词后面，明确告诉模型应该生成何种结构的输出。举个例子。它可能会包含类例"Your esponse should be in JSON format. The data structure for the JSON should match this Java claas:com.example.Mybean” 这样的描述，并可能带一个 JSON Schema 定义，引导模型生成符合指定格式的响应。
  • 调用后：StructuredOutputConverter 同时也实现了 Converter<string, T> 接口。这个Converter 负责将大模型返回的文本输出(通常是JSON 字符串)转换为开发者指定的目标类型T(比如一个Java Bean 对象、Map 或 List)。Spring Al提供了多种内置的转换器实现，如Beanoutputconverter(用于转换为JavaBean，内部基于ObjectMapper)、MapOutputconverter和ListOutputconverter 。

也就是说，Sping Al 的结构化输出转换器首先通过修改提示词来规定模型按特定格式生成文本，然后将该文本转换为Java对象。使用chatclient的.entity(Myclass.class)方法时，框架会自动处理这个过程，将模型的 JSON 输出映射到 Myclass 的实例。但是，这只是“尽最大努力” 的转换，模型并不保证一定能严格按要求返回结构化数据！

什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？

Re-Reading(重读,，也称为 Re2，是种通过让大语言模型重新阅读问题来提高其推理能力的技术，核心思想是，对于复杂问题，重复阅读和审视问题有助于模型更好地理解题意和约束，从而生成更准确、更深入的回答，有文献研究证明这是有一定效果的。不过，这种方法会因为重复处理输入导致成本加倍，所以在面向C端开放的应用中需要谨慎使用。

在 Spring Al 中，可以通过自定义 Advisor 来实现 Re-Reading 功能：

  • 创建自定义 Advisor 类：该类需要同时实现 CallAroundAdvisor(用于同步请求)和 StreamAroundAdvisor(用于流式请求)接口，让该类更通用(在 Spring Al 1.0 版本中，上述两个接口需要更改为 CallAdvisor 和 StreamAdvisor )
  • 修改用户提示词：在Advisor的前置处理逻辑中(例如 aroundCall或aroundStream 方法调用之前)，对用户的原始输入文本进行改写，改写的格式通常是将原始输入重复一遍，并用明确的指令引导模型重新阅读，通过看源码能够看到提示词，其中，{Input_query} 是用户原始的提问内容
{Input_Query}
Read the question again: {Input_Query}
  • 传递给模型：将改写后的提示词传递给大语言模型进行处理。

什么是查询重写？它有什么作用？如何基于 Spring AI 实现查询重写？

查询重写是 RAG 预检索阶段的优化手段。它利用 AI 大模型对用户原始输入的查询进行改写润色，然后生成一个对后续文档检索更有效、更精确的新查询。

查询重写可以提高检索的准确性和相关性，尤其是当用户查询较为模糊、口语化、不完整，或者和知识库语言风格不一致时，通过重写可以将查询变得更规范、更详细，更容易在向量数据库中匹配到最相关的文档,。

Sping AI 主要通过 QueryTransformer 接口及其实现类来支持查询重写，比如 RewriteQueryTransformer，可以将简单查询改写得更具体更专业；而CompressionQueryTransformer 则专注于处理多轮对话场景，将对话历史和当前问题压缩成一个独立的、包含完整上下文的新查询，使用时，需要为这些转换器配置一个 chatclient 或 chatrodel，然后调用其 transform 方法传入原始查询即可得到重写后的查询。

什么是上下文查询增强？它有什么作用？如何基于 Spring AI 实现上下文查询增强来处理无关问题？

上下文查询增湿是 RAG流程中的一个核心环节，指的是把用户的原始查询与从知识库中检索到的相关文档进行结合，形成一个信息更丰富的增强提示，然后将这个增强提示提供给AI，让模型能基于这些特定知识生成回答。主要作用是为大模型提供必要的、实时的外部知识，这样 AI 的回答就不仅仅依赖于其预训练的通用知识，提高答案的准确性、相关性和时效性。

Spring Al 的 RetrievalAugmentationAdvisor 内部使用 ContextualQueryAugmenter 来实现上下文查询增强，当处理用户提出的无关问题时，ContextualQueryAugmenter 提供了空上下文处理机制。

我们可以配置 ContextualQueryAugmenter 的 allowEmptycontext(false)，检索不到相关文档时，系统会使用这个自定义模板来指示大模型如何回应。

什么是 Spring AI 提出的模块化 RAG 架构？预检索、检索和后检索阶段各自负责什么？

Spring AI 提出的模块化 RAG架构是将整个检索增强生成过程分解为 预检索、检索、检索后 三个核心阶段，每个阶段包含可配置的组件，以提升大模型响应的准确件和灵活件。

  1. 预检索阶段(Pre-Retrieval)：
    • 职责：接收用户的原始查询，并对其进行优化和转换，生成更适合后续检索的查询版本。
    • 组件：包括各种 QueryTransformer，如 RewriteQueryTransformer(改写查询使其更清晰)、TranslationQueryTransformer(翻译查询)、CompressionQueryTransformer(在多轮对话中压缩历史和当前问题)、以及MultiQueryTransformer(将单查询扩展为多查询，提高召回)。
  2. 检索阶段(Retrieval)：
    • 职责：使用预检索阶段优化后的查询，从知识库中搜索并召回最相关的文档片段。
    • 组件：核心是 DocumentRetriever(如 VectorStoreDocumentRetriever)，它负责执行相似件搜索并根据元数据过滤结果、如果涉及多源检索，还可能用到 DocumentJoiner 来合并结果
  3. 检索后阶段(Post-Retrieval)：
    • 职责：对检索到的文档集进行进一步处理和优化，筛选出最适合提供给大模型的上下文，可以解决上下文丢失问题、上下文长度限制，并减少冗余内容。
    • 组件：可能包括文档重排序、无关文档移除、文档内容压缩或摘要等。Spring Al提供了 DocumentProcessor API 来支持自定义的后处理逻辑，但目前并不成熟。

什么是工具调用 Tool Calling？如何利用 Spring AI 实现工具调用？

工具调用 (Tool Caling)，也常被称为 Function Calling，是一种允许 AI 大模型在对话过程中，根据需要请求执行外部工具来完成特定任务的机制，AI 模型本身可能不具备实时查询天气、操作数据库或访问特定 API 的能力，通过工具调用，它可以识别出什么时候需要这些外部能力，并生成一个包含工具名称和所需参数的请求。应用程序接收到这个请求后，实际执行相应的工具，并将执行结果返回给 AI 模型，模型再基于这个结果继续对话或生成最终答案。

注意，真正执行工具的是我们的应用程序，而非 AI服务器本身。Spring Al极大地简化了工具调用的实现：

  1. 定义工具：通常使用注解方式，在一个Java 类中，将希望作为工具的方法标记上 @Tool 注解。方法的参数可以使用 @ToolParam 注解来提供描述和指定是否必需。Spring Al 支持多种 Java 类型作为参数和返回值，但返回值需要可序列化。
  2. 注册与使用工具：
    • 按需使用：在构建 chatclient 请求时，通过 .tools() 方法直接传入工具类的实例。
    • 全局使用：在构建chatclient 时，通过 .defaultTools() 注册默认工具，这些工具对该 chatclient 发起的所有对话都可用。
    • 集中注册：可以创建一个配置类，使用@Bean方法将所有工具实例化并通过 ToolCallbacks.from() 统一注册为一个 ToolCallback[] 数组，方便管理和注入。
  3. 调用流程：当使用配置了工具的 chatclient 进行对话时，如果 AI 模型判断需要使用某个工具，Spring Al 框架会自动执行以下步骤，无需开发者关心：
    • 解析 AI 模型返回的工具调用请求(包含工具名和参数)。
    • 根据工具名找到对应的 Java 方法并执行。
    • 将工具执行的结果转换并返回给 AI模型。
    • AI模型根据工具结果生成最终回复

微调/预训练

什么是大模型微调？与预训练的核心区别是什么？

大模型微调(Fine-tuning of Large Models)是指在预训练模型的基础上，使用特定任务的数据对模型进行再训练，以适应特定应用场景的需求。与预训练(Pre-training)相比，微调的核心区别在于目标、数据来源和训练方式

目标不同：

  • 预训练：旨在让模型学习通用的语言或知识表示，通常在大规模通用数据集上进行训练。
  • 微调：旨在让模型适应特定任务，如情感分析、问答系统等，通常在特定任务的数据集上进行训练

数据来源不同：

  • 预训练：使用大规模的通用数据集，如维基百科、书籍语料等。
  • 微调：使用与特定任务相关的标注数据集。

训练方式不同：

  • 预训练：通常采用无监督或自监督学习方式。
  • 微调：通常采用监督学习方式，利用标注数据进行训练。

常见的微调任务有哪些？

大模型微调(fine-tuning)是指在预训练模型的基础上，使用特定任务的数据对模型进行再训练，以适应特定应用场景的需求。常见的微调任务主要包括以下几类：

  • 文本分类：将文本分为不同的类别，如垃圾邮件识别、情感分析等。
  • 命名实体识别(NER)：识别文本中的实体，如人名、地名、组织机构等
  • 问答系统(QA)：根据给定的问题，从文本中找出答案。
  • 文本生成：生成与输入相关的文本，如摘要生成、对话生成等
  • 机器翻译：将一种语言的文本翻译成另一种语言
  • 多模态任务：处理多种类型的数据，如图文匹配、图像描述生成等，

常见的微调方法有哪些？

大模型微调(fine-tuning)是指在预训练模型的基础上，使用特定任务的数据对模型进行再训练，以适应特定应用场景的需求，常见的微调方法主要包括以下几类：

  • 全量微调(Supervised Fine-Tuning/Instruction Tuning)：是直接对预训练模型的所有参数进行再训练，以使模型适应特定任务或领域需求，这种方式能获得最佳的任务性能，但计算与存储开销极大。
  • 参数高效微调(PEFT)： 仅更新少量参数，冻结其余权重，从而大幅降低训练和存储成本，同时在许多场景下能达到接近全量微调的效果。
    • Adapter Tuning：在每层 Transformer 中插入小型适配器模块，只训练这些新加参数即可快速适配任务
    • LoRA(Low-Rank Adaptation)：为每层添加低秩分解矩阵，并仅训练这些矩阵，实现参数量级的极大压缩。
    • Prefix Tuning：在输入前加入可训练的前缀向量，模型本体权重完全冻结，用于指令或上下文效果微调。
    • Prompt Tuning：只训练用于任务提示的嵌入向量，不改变模型内部结构，以“提示”形式引导模型行为。
    • P-Tuning：将提示设计为可微分的模板，通过梯度优化找到最优提示模板，效果优于人工提示。
    • BitFit：仅对偏置项(bias)进行微调，训练参数极少，但在一些分类任务中可保持合理性能
  • 量化与混合微调方案：
    • QLORA：结合4-bit 权重量化与 LORA，利用低精度存储与低秩适配，单卡即可微调百亿级模型，性能接近全量微调
    • IR-QLORA：在 QLORA 基础上加入信息保留量化与弹性连结技术，进一步提升量化后微调模型的准确性。
    • 增强检索式微调：在 RAG 系统中集成 LORA/QLORA，并引入 AI Judge 反馈机制，实现对检索增强生成模型的持续优化。

PEFT 是什么？为什么需要 PEFT？

PEFT (Parameter-Efficient Fine-Tuning) 一种在微调预训练大模型时，仅训练少量新增参数(如适配器模块、低秩增量矩阵、可微前缀或提示嵌入等)，冻结原始模型大部分权重的策略，从而在计算和存储成本大幅降低的前提下，仍能保持与全量微调相近的性能。

全量微调对显存、算力和存体的需求极高，读代速度慢，不利于多任务和在线更新，并且在小样本场景下易出现过投合；PEFT 通过仅更新数百万级别域更少的参数，实现高效微调和快速铁代，因此PEFT 能够显著节省计算资源和存储空间，加快训练收敛速度并减少过拟合风险，同时也能够大幅降低模型版本管理和分发成本。

我们通过一个生动形象的比输来理解下：在厨房里，如果想给蛋糕增添一丝风味，完全重做配方既费时又浪费食材，更聪明的做法是只加点甜品或果酱，就能马上尝出新滋味。PEFT 正是这样的策路:，在不动大模型“主体结构”的前提下，只调味 —— 即训练极少量的新增参数，便能让模型适应下游任务，而无须全量重训整个网络。

参数高效微调（PEFT）的核心思路是什么？列举 3 种典型方法

参数高效微调(PEFT)是一种迁移学习策略，通过冻结大部分预训练模型权重，仅训练极少量附加参数或模块，以显著降低算力和存储开销，同时保持与全量微调相近的性能。

相较于直接调整全部参数，这种方法能在数百万或更少的参数级别完成任务适应，极大提升了在资源受限环境中的可用性。

  • Adapter：在每个Tansformer 层的中间插入一个小型瓶颈层，只微调这些瓶颈层的参数，其它参数全量冻结，既能灵活适应下游任务，又能大幅减少可训练参数
  • LoRA(Low-Rank Adaptation)：将预训练模型中关键权重矩阵(如 Query、value)拆分成低秩短阵的形式，仅训练这部分低秩矩阵，极大地降低了微调时的参数量和计算成本
  • Prefix-Tuning：在模型的输入序列前端添加一段可训练的连续“前缀”向量，仅微调这些前缀，保留主体模型参数不变，既适用于生成任务，也能灵活迁移到多种场景

PEFT 和全量微调的区别？

  • PEFT(参数高效微调)：只微调预训练模型中极少量参数(如新增的 Adapter 模块、前缀向量等)，其余参数保持冻结。这种方法显著降低了计算资源和存储需求，适用于资源受限或小样本场景。
  • 全量微调(Fl Fine·Turing)：对预训练模型的所有参数进行调整，以适应新任务，这种方法通常需要更多的计算资源和数据，但在任务与预训练模型差异较大时，可能获得更好的性能。

在进行 Fine-Tuning 时，如何选择适合的预训练模型？

在进行 fine-Tuning 时，选择合适的预训练模型需要綜合考虑任务类型、模型规模、数据域匹配、性能基准、生态支持和许可部署等多方面因素

  • 任务类型和架构匹配：选择预训练模型时，首先需确定任务是文本分类、生成、问答还是图像识别等，并选择与任务需求相符的模型架构，比如 Transfomer 系列、CNN 或者多模态模型
  • 模型规模与资源平衡：更大规模的模型通常具备更强表示能力，但会占用更多显存与计算资源，需根据实际硬件条件和延迟要求在模型大小与性能之间权衡。
  • 预训练数据域相似度：优先选用在与目标任务数据域相近的语料或图像上预训练的模型，以提高迁移效果，例如在医学文本上预训练的 BiBERT 适用于生物医药领域任务
  • 性能基准与评测结果：参考公开基准测试和论文报告，对比各模型在类似任务上的表现，选择在关键指标(如准确率、F1、BLEU、鲁棒性)上表现优异的模型。
  • 生态系统和社区支持：优先使用社区活跃、文档完善、工具链支持良好的模型，如 Hugging face Transformers 提供的模型列表和 Trainer API，可降低集成和微调难度,

微调中常用的优化器有哪些？

在微调大模型的过程中，选择合适的优化器对于模型性能的提升是很重要的。以下是一些常用的优化器：

  • Adam(Adaptive Moment Estimation)：Adam是当前最常用的优化器之一，结合了动量(Momentum)和自适应学习率(Adaptive Learning Rate)的优点。它对不同参数采用不同的学习率，适用于大多数任务，尤其在参数较多或数据稀疏的场景中表现良好。
  • SGD(Stochastic Gradient Descent)及其变体：SGD 是最基础的优化器，具有良好的泛化能力，其变体，如 SGD with Momentum 和 Nesterov Accelerated Gradient，通过引入动量项加速收敛，常用于需要精细控制学习率的任务
  • RMSProp(Root Mean Square Propagation)：RMSProp 通过对每个参数的梯度平方的指数加权平均来调整学习率，适用于处理非平稳目标的任务，如循环神经网络(RNN)训
  • Adagrad(Adaptive Gradient Algorithm)：Adagrad 为每个参数分配不同的学习率，对稀疏数据表现良好，但学习率会随着训练进行而不断减小，可能导致训练提前停止。
  • Adadelta：Adadelta 是对 Adagrad 的改进，限制了累积梯度的窗口大小，避免了学习率过早下降的问题,
  • AdamW：AdamW 是对 Adam 的改进版本，引入了权重衰减 (Weight Decay)机制，适用于需要正则化的任务，如 BERT 等预训练模型的微调。

如何判断微调效果是否达到预期？

在微调完成后，我们需要从多维度综合判断模型效果是否达标，首先，通过在验证集和测试集上计算各种量化指标，可以客观评估模型对下游任务的掌握程度。其次，定性评估(人工评审和用户反馈)能揭示自动指标难以捕获的语义和体验层面问题，同时，监控训练过程中的损失和指标曲线，并结合早停策略，可及时发现过拟合或欠拟合现象。最后，A/B 测试及在线监控将真实生产环境的业务指标的纳入考量，实现从研发到生产的闭环评估与持续法代。

  • 明确任务目标井对齐评价指标:根据微调任务(如分类、生成、序列标注等)选定对应的准确率、F1、BLEU、ROUGE、Perplexity 等核心指标，以确保评估目标与业务需求一致
  • 在验证集和测试集上进行量化评估：使用独立的验证集进行超参数与早停调优，最终在测试集上报告模型的最终性能，保证结果的客观公正。
  • 分析训练曲线与早停：监控训练验证损失及指标随epoch的变化，运用早停(Early Stopping)策略防止过拟合，并分析两者差距以判断欠拟合或过拟合程度。
  • 定性评估与用户反馈：组织人工评审或小规模用户调研，对模型输出的可读性、准确性、连贯性等方面进行主观打分，捕捉量化指标难以反映的问题。
  • 模型稳定性与鲁捧性测试：通过对抗样本或不同分布的数据集检验模型对输入扰动和领域迁移的适应性，评估模型的泛化与抗噪声能力。

什么是低秩适配（LoRA）技术？如何结合 LoRA 技术进行微调？

LORA(Low-Rank Adaptation，低秩适配)是一种高效微调大模型的技术。它的核心思想是：在不修改原始模型参数的前提下，添加两个小矩阵来模拟模型参数的变化，只训练这两个小矩阵，从而实现模型的快速活应。这种方法大大减少了需要训练的参数数量，降低了计算资源的需求，同时保持了模型的性能,

如何结合 LORA 进行微调?

  1. 选择适配层：通常选择模型中的注意力机制部分，如 Query 和 Value 层。
  2. 设置超参数：确定低秩矩阵的秩(r 值)，以及缩放因子等。
  3. 注入 LORA 模块：使用相关工县或库，将 LORA 模块集成到原始模型中。
  4. 训练：在下游任务的数据上，仅训练 LORA 模块的参数，原始模型参数保持不变。
  5. 推理：训练完成后，可以将 LORA 模块合并到原始模型中，或者在推理时动态加载

通过以上步骤，LORA 实现了在保持模型性能的同时，显著降低了微调的成本和复杂度

微调的过拟合风险如何通过正则化缓解？

微调的时候，过拟合是个非常常见的问题，尤其是当我们用的数据集比较小或者任务特别窄的时候，模型很容易“死记硬背”训练数据，导致泛化能力变差，最直接的办法，就是引入正则化手段，给训练过程加点“限制”。让模型别太自由发挥，从而降低过拟合风险。通过正则化技术，我们可以在损失盈数中增加惩罚项或在训练过程中引入随机性，从而约束模型的表达能力，提升泛化性，常见方法包括L2权重衰减、Dropout、Early stoping、数据增强等，这些技术各有侧重，但都能有效缓解过拟合风险。

  • L2 权重衰减：在损失函数里加上所有可训练参数平方和的惩罚项，让权重大幅更新时“要付出代价”，防止模型对训练噪声过度敏感，从而提升泛化能力,。
  • Dropout：训练时以一定概率随机“丢掉”部分神经元，相当于在不同子网络之间切换训练，发挥集成效应，减少单一网络对特定特征的过度依赖。
  • Early Stopping：实时监控验证集表现，一旦验证损失不再下降就果断停训，避免模型在训练集上继续“打磨”而丧失对新样本的适应性。
  • 数据增强：对原始样本做同义替换、回译、随机遮蔽、噪声注入等操作，扩充训练集、引入多样性，让模型学到更鲁棒的特征。

请详细讨论微调时如何防止灾难性遗忘问题？

在预训练模型微调过程中，由于下游任务数据通常有限，模型容易遗忘在预训练阶段学到的通用知识，这一现象称为灾难性遗忘。打个比方，如果一个人学会了骑自行车，然后突然去学滑板，如果不注意方式方法，就很容易忘了骑车的感觉。同理，大模型要如果微调得太猛，就容易把原来在预训练中学会的通用能力给“冲掉”了，因此，需要采用多种策路在学习新任务的同时保持旧知识，主要包括正则化方法、重放机制、知识蒸馏和架构化策略等几大类，每种方法各有特点和适用场景。合理地选用或组合这些手段，既能让模型快速适应新任务，又能有效保留已有能力，从而在微调中实现最优的性能权衡。

  • L2 正则化与 EWC：在损失函数中引入参数变化惩罚，EWC 更进一步使用 Fisher 信息矩阵来加权惩罚，防止关键参数大幅偏移
  • 经验重放(Experience Replay)与黑暗重放(Dark Experience Replay)：保留旧任务样本或其特征，再与新数据一起训练，保持模型对旧任务数据的记忆.
  • 知识蒸馏(Learning without Forgeting,LwF)：在微调时，蒸馏原模型对旧任务的软目标，使新模型既学习新任务，又“记住”旧模型输出行为。
  • 参数隔离与进阶网络：如 Progressive Networks、PackNet，将不同任务的权重分离或动态扩展网络结构，避免参数互相干扰,
  • 混合低秩微调(I-LORA)：结合 LORA 和经验重放，通过参数插值与双重记忆提升稳定性和平衡新旧任务能力。

在多模态微调（如图文生成）中，如何确保文本和图像数据的对齐质量？

  • 高质量数据：利用 CLIP 等模型打分过滤或 Filter & Align 算法清洗大规模图文对齐数据，确保输入质量不含噪声
  • 对齐损失：加权对比学习与元素级匹配损失相结合，强化跨模态语义对应，如使用 ITC Loss 及 iMatch 的 QAlign 策略
  • 评估反馈：引入自动化评估(iMatch、VQA 评估)与人工打分，形成闭环反馈，及时调整微调目标。
  • 微调策略：采用 Adapter/LORA 模块化微调，冻结核心权重并在新增低秩矩阵上约束对齐正则，减少对原模型对齐性的破坏.
  • 增强与回放：结合图像光照等数据增强、文本同义替换、及锚点样本回放或混合样本生成(如 Geodesic Mixup)，提高对齐稳健性
  • 语义闭环：使用 RECAP 重标注技术，对原始 Caption 进行自动化重写，提升语义精准度并增强微调对齐效果。

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

大模型微调是在预训练模型基础上，使用特定领域的数据集进行二次训练的过程。它的主要目的是让通用大模型能够更好地适应特定领域或任务的需求。以下场景需要考虑使用微调而不是直接使用基础模型:

  • 专业领域应用：比如医疗领域，基础模型可能对骨科专业知识掌握不足，需要用专业的骨科数据集进行微调，使模型具备该领域的专业能力。
  • 数据安全要求高：涉及企业内部敏感数据时，直接使用第三方大模型服务可能存在数据泄露风险，此时需要对开源大模型进行私有化微调部署。
  • 特定任务优化：当需要模型完成特定任务(如客服对话、代码生成等)时，通过微调可以显著提升模型在该任务上的表现。

什么是大模型的"涌现能力"？列举三种典型表现并解释其可能成因

大模型的涌现能力(Emergent Abilities)是指在模型规模达到某个临果值后突然出现的、在小规模模型中不存在的能力，这种能力的出现往往是不可预测的，天法通过简单外推小模型的性能来预测

  • 思维链推理(Chain-of-thought)：这是一种在解决复杂问题时能够像人类一样展示推理过程的能力。当模型规模达到一定程度(约10^22 FLOPS)后，模型能够生成中间推理步骤，大幅提升在数学应用题等多步骤推理任务上的表现。
  • 指令跟随能力：模型能够准确理解和执行自然语言指令，无需像小模型那样依赖大量示例。这种能力在大规模模型中表现得更为突出，能够理解更复杂的指令并产生符合要求的输出。
  • 多任务理解与迁移：大模型展现出了强大的跨任务泛化能力，能够在没有专门训练的情况下完成新的任务，比如在 MMLU (Masive Multi-task language Understanding)测试中，大模型可以回答涉及数学、历史、法律等多个领域的问题

参数高效微调（PEFT）如何减少计算成本？

PEFT通过只微调少量额外参数，冻结大多数预训练模型权重，大幅减少梯度计算和存储需求，从而节省算力和显存

典型方法如LoRA、Adapter、prefix Tuning、IA3等，仅在原模型中注入轻量级模块或向量，新增参数量通常只占原模型的千分之一到百分之几，计算复杂度显著降低。

微调后生成的小型权重文件仅几MB级别，远小于全量微调产生的几十GB模型，便于在消费级GPU或Colab上快速训练与分发。

冻结层在微调中的作用是什么？

冻结层在微调中的作用主要是减少计算资源的消耗、避免过拟合，并加速训练过程。具体来说，冻结层的做法是将预训练模型中的某些层的参数固定，不参与梯度更新。这样做有以下几个好处。

  • 减少计算量：冻结部分层后，模型在训练时只需要计算和更新未冻结层的梯度，节省了计算资源。
  • 降低内存占用：冻结层减少了需要存储梯度和优化器状态的参数数量，降低了内存需求。
  • 加速训练：由于更新的参数较少，训练过程可以更快收敛。
  • 避免过拟合：冻结层可以防止模型在小样本数据上过度拟合，保持预训练模型的泛化能力。

为什么需要混合精度训练？

混合精度训练 (Mxed precision Training)是深度学习中一种提高训练效率的技术，核心目的是在保持模型精度的同时，减少计算资源的消耗。具体来说，它通过在训练过程中同时使用不同精度的数据类型 ( 如 FP16和FP32)，实现以下目标：

  • 加速训练过程：FP16 运算在现代 GPU 上的处理速度比 FP32 快，尤其是在 NVIDIA的 Tensor Cores上，FP16 的矩阵乘法和卷积的峰值性能比 FP32 快约 16 倍。
  • 减少内存占用：FP16数据占用的内存空间是 FP32 的一半，这意味着可以训练更大的模型或使用更大的批量，从而提高训练效率和潜在的模型泛化能力。
  • 提高吞吐量：更快的计算速度和更少的内存使用量共同作用的结果是更高的吞吐量，这意味着在相同的时间内可以处理更多的数据,
  • 节省能源：低精度计算通常更节能，这对于数据中心的大规模训练和在电力有限的边缘设备上部署尤为重要。

模型输出重复和幻觉如何微调解决？

在大模型输出中，出现重复和幻常是两个常见的问题，重复指的是模型在生成文本时出现内容重复的现象，而幻觉则是指模型生成了看以合理但实际上不真实或不准确的信息。为了解决这两个问题，可以通过微调(fine-tuning)的方法进行优化。

具体来说，微调可以通过以下方式来减少重复和幻觉：

  • 数据质量控制：确保用于微调的数据是高质量的，包含准确、真实的信息，避免模型学习到错误或重复的模式.
  • 引入惩罚机制：在训练过程中，对模型生成重复或不真实内容的行为进行惩罚，引导模型生成多样且准确的内容。
  • 领域特定微调：针对特定领域(如医疗、法律、金融等)进行微调，使模型在该领域内生成更准确的内容，降低幻觉发生的概率
  • 参数高效微调(PEFT)：采用低秩适配(LORA)等方法，在不改变模型主体结构的情况下，进行小范围的参数调整，提高微调效率，减少幻觉的产生。
  • 增强训练策略：引入合成任务(如SynTra)或噪声增强微调(NoiseFiT)，通过设计特定任务或在训练中加入噪声，增强模型的鲁棒性，减少幻觉的生成
  • 强化学习与人类反馈(RLHF)：结合人类反馈进行强化学习，使模型在生成内容时更加符合真实世界的知识和逻辑，降低幻觉的风险。
  • 检索增强生成(RAG)：结合外部知识库，在生成过程中引入相关的真实信息，帮助模型生成更准确的内容。

SFT 指令微调数据如何构建？

SFT(Supervised Fine-Tuning，监督微调)指令微调数据集的构建过程，主要是为特定任务提供高质量的数据支持。简单来说它是通过收集和标注数据来帮助模型更好地理解和执行特定指令或任务

构建过程一般包括以下步骤：

  1. 收集原始数据：首先，需要收集与任务相关的基础数据。比如，如果任务是生成文本，那么可以收集各类文本;如果是分类任务，可以收集标注好的类别数据。数据需要多样化、代表性强，以确保模型可以泛化到更多场景
  2. 标注数据：对收集到的原始数据进行标注，指明每个数据样本的目标输出。比如，对于对话任务，标注数据就是问题和正确的回答;对于分类任务，标注数据就是每个样本的类别标益，这里的准确性和一致性至关重要。
  3. 划分数据集：把标好的数据分为训练集、验证集和测试集。一般来说，80%用于训练，10%用于验证，10%用于测试。通过这种划分，可以在不同的阶段对模型进行训练和调优，确保模型不会过拟合。
  4. 数据预处理：为了让数据更适合模型，需要做一些预处理工作。比如，对于文本数据，可能需要做文本清洗、分词、去除停用词等处理步骤。这样有助于提升模型的训练效率和效果。
  5. 格式转换：将预处理后的数据转换成适合模型的格式。常见的格式包括文本文件、JSON格式等，这样模型才能正确地读取和训练。
  6. 模型微调：最后，使用这些数据对预训练模型进行微调，微调过程中，需要选择适当的训练超参数(如学习率、batch size等)，以及微调方法(如冻结部分层或全层微调)。这个过程会让模型逐渐适应特定任务。
  7. 模型评估：训练完成后，使用测试集对模型进行评估，查看模型在任务上的表现，如准确率、召回率等指标。如果效果不理想，可以继续优化数据集或者调整模型参数。

指令微调的好处？

指令微调(Instruction Tuning)是对大型语言模型(LLM)进行微调的一种技术，旨在使模型更好地理解和执行自然语言指令。其主要好处包括：

  • 提升指令跟随能力：指令微调通过在多样化的“指令一响应”对上微调，使模型接到新指令时能更精准地执行任务，减少对冗长提示的依赖。
  • 增强零样本与少样本泛化：在未见过的任务或领域上，微调后的模型也能给出合理输出，大幅提升新场景下的适应性
  • 行为可控、风险降低：通过引入约束性指令或安全策略微调，生成结果更加可预测，可有效降低有害或偏离目标的输出概率
  • 多任务统一能力：指令微调让单一模型兼顾翻译、摘要、问答等多种场景，避免为每个子任务都单独训练多个模型的资源浪费,。
  • 节省算力与数据成本：相比从头训练，指令微调所需数据量适中、训练速度更快，算力消耗更低，能在资源受限情况下迅速部署

实战

什么是护栏技术？

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

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

  1. 内容安全过滤(如识别有害文本/图像)
  2. 伦理规则引擎((预设禁止行为的逻辑判断)
  3. 错误处理机制(当AI无法处理问题时，拒绝回答或引导人工介入)

什么是 GPTCache？

GPTCache 是专为大语言模型设计的语义缓存工具，通过存储和复用模型响应，从而降低 API 调用成本并提升响应速度.。

它的核心价值在于：

  1. 降本增效：通过缓存相似查询的结果，减少重复调用LLM的次数，例如将ChatGPT的API成本降低10倍，响应速度提升100倍。
  2. 语义匹配：区别于传统精准匹配的缓存，GPTCache 使用向量嵌入技术 (如OpenAl Embedings、SentenceTransformers)将用户问题转换为向量，通过向量数据库 (Milvus、FAISS)进行相似性搜索，实现“语义级”缓存命中
  3. 灵活扩展：支持模块化设计，用户可自定义嵌入模型、缓存存储(如SQLite、MySQL)、逐出策略(LRU/FHIFO)等组件，适配不同场景需求。

我们在大模型应用开发的很多场景都能用上它，例如聊天机器人、客服系统中重复问题的快速响应。测试场景，模拟LLM响应，减少对真实API的依赖，加速开发迭代。

大模型的结构化输出指的是什么？

结构化输出是指让模型生成特合特定格式(如ISON、XML、表格、SQL语句等)的数据，而非自由文本。这种输出能被计算机程序直接解析和处理，比如存入数据库、生成API接口参数、驱动自动化流程等

常见形式如下：

  • 数据格式：JSON(最常用)、YAML、CSV、XML
  • 结构化文本：表格(Markdown表格)、键值对、固定字段的段落
  • 领域特定格式：SQL语句(用于数据库查询)、HTML(用于网页生成)、LaTeX(用于学术公式)

技术实现核心是通过提示工程、JSON Schema定义或约束性解码(Constrained Decoding)强制模型遵循格式规则

实现方法：

  • 提示工程：在输入提示中明确要求输出格式(例：“请以SON格式返回用户姓名、年龄、邮箱，字段名分别为name、age、email”)。
  • 后处理：用代码解析模型生成的文本，转换为标准结构(例如用正则表达式提取表格数据)。
  • 工具辅助：使用库或框架(如LangChain的 StructuredOutputParser )自动验证和解析输出格式。

什么是 GPT Structured Outputs？

GPT Structured Outputs 是一种通过技术手段强制大语言模型(如GPT-4o)生成符合特定格式要求的结构化数据的能力，例如JSON、XML或自定义格式的表格。

以前用的是“提示生成JSON"的模糊要求，现在GPTStructured Outputs 能保输出严格待合预定义的字段、类型和层级结构，例加，通过JS0N scdhema定义“必须包含 name(字符串)、age(整数)字段”，模型将自动拒绝生成无效内容。

按照 openAl 官网介绍，结构化输出的一些优点包括：

  • 可靠的类型安全：无需验证或重试格式不正确的响应
  • 明确拒绝：基于安全的模型拒绝现在可以通过编程检测
  • 更简单的提示：无需使用措辞强烈的提示来实现格式一致

简单来说以前的返回格式容易出错，且不容易判断，现在 GPT Structure Output 能让输出的格式保证正确，假使不正确也有明显的提示。

实现方式:

  • OpenAl APl：通过 response_format 参数指定JSON Schema或Pydantic模型(如 {"type": "json_schema","json_schema": {...})。
  • 开源工具：如 instructor 库(适配API调用)或 outlines 库(适配本地模型部署)，通过代码定义输出结构。

在大模型应用中，通常如何实现长短期记忆机制

  1. 短期记忆：利用上下文窗口(如Claude的100k tokens)缓存最近的对话或输入，或通过滑动窗口(Bufer Window)保留固定轮次的历史,。
  2. 长期记忆：结合摘要压缩(Summarization)、向量数据库(如RAG检索增强)持久化存储关键信息。

从目前的大模型实现来看，短期记忆依赖模型原生能力，长期记忆通过外部存储(如知识图谱、数据库)实现检索

本地部署大模型和调用云端大模型各有什么优缺点？

个人的选择建议:

  • 个人开发者和初创企业：初期更适合调用云端大模型，可以快速验证想法，成本低。
  • 对数据隐私有极高要求的企业或特定行业应用：本地部署是更安全的选择。
  • 需要深度定制模型以适应特定业务场景：本地部署开源模型 +微调更合适
  • 对响应延迟有严格要求的边缘计算场景：本地部署有优势。

提示词优化考虑哪些维度?你们提示词模板有哪些字段?

关于提示词优化的核心维度主要有以下几个点

  1. 目标明确性：让模型清楚知道要解决什么问题。
  2. 结构清晰性：用分点、格式(如JSON/Markdown)或分隔符(###)拆解任务，避免信息混乱
  3. 少量样本：通过输入输出样例告诉模型期望的结果长什么样，减少理解偏差。
  4. 角色设定：给模型定义身份(如“你是资深程序员”)，让输出风格更符合场景，比如专业、口语化等。
  5. 增加约束条件：限制输出范围，如字数、格式、禁止内容，避免模型幻觉或偏离主题

还有一个也很关键就是持续反馈迭代，我们需要根据模型输出调整提示词，比如补充细节、优化示例，通过A/B测试找到最优解。提示词模板的常见字段：

  1. 角色定义：指定模型身份(如你是程序员，擅长代码生成)。
  2. 任务描述：用具体指令拆解目标(如请根据以下数据生成趋势分析，需包含3个核心结论)
  3. 输入内容：提供原始数据或问题案例。
  4. 输出格式：规定结果结构(如输出JSON格式)。
  5. 约束规则：说明限制条件(如回答不超过200字)
  6. 评估标准：引导模型自检(如语言需口语化)。

要让AI生成一个带表单验证的Vue3组件，请写出包含以下要素的Prompt

首先，我们需要明确编写一个好的 Prompt 需要以下几个关键要素:

  • 技术栈和版本：需要明确指定使用 Vue3 的 Composition API，这样可以确保生成的代码符合最新的开发规范
  • 功能需求：表单验证的具体要求
    • 邮箱格式校验
    • 错误提示的展示位置和方式
    • 提交按钮的状态控制
  • 代码规范和最佳实践：生成的代码需要遵循 Vue3 的开发规范和最佳实践。

基于以上要素，一个完整的 Prompt 示例如下:

请使用 Vue3 的 Composition API 创建一个表单组件，要求如下：

1）组件结构：

- 包含一个邮箱输入框和提交按钮
- 使用 Element Plus 作为 UI 组件库
- 代码需要包含必要的类型声明

2）表单验证：

- 实现邮箱格式的合法性校验
- 错误提示信息需要显示在输入框下方
- 使用 vuelidate 或 VeeValidate 进行表单验证

3）交互优化：

- 提交按钮在表单验证未通过时禁用
- 提交过程中按钮显示 loading 状态
- 防止重复提交

4）代码要求：

- 使用 TypeScript
- 遵循 Vue3 组件命名规范
- 添加必要的代码注释
- 确保代码的可维护性和可测试性

假设需要让大模型生成一个React表单组件代码，请设计一个包含上下文约束的Prompt（需包含数据验证、错误提示等要求）

设计一个面向大模型的 React 表单组件生成 Prompt，需要包含以下关键要素

  • 组件功能需求：表单组件需要包含：
    • 用户名(必填，2-10个字符
    • 邮箱(必填，符合邮箱格式)
    • 密码(必填，8-20位，包含大小写字母和数字)
    • 确认密码(必填，与密码一致)
    • 手机号(选填，符合手机号格式)
    • 提交按钮
  • 技术要求：
    • 使用 React Hook Form 进行表单管理和验证
    • 使用TypeScript 编写组件
    • 使用 Tailwind CSS 进行样式设计
    • 遵循 React 最佳实践和设计模式

完整的 Prompt 内容：

请生成一个 React 表单组件，要求如下:

1. 组件功能:
   - 实现用户注册表单
   - 包含用户名、邮箱、密码、确认密码、手机号等字段
   - 提供表单提交功能

2. 数据验证要求:
   - 用户名: 必填，2-10个字符
   - 邮箱: 必填，符合邮箱格式
   - 密码: 必填，8-20位，包含大小写字母和数字
   - 确认密码: 必填，与密码一致
   - 手机号: 选填，符合手机号格式

3. 交互体验要求:
   - 实时字段验证
   - 清晰的错误提示信息
   - 表单提交时的加载状态
   - 成功/失败的反馈提示

4. 代码规范要求:
   - 使用 TypeScript
   - 使用 React Hook Form
   - 使用 Tailwind CSS
   - 代码注释完整
   - 组件和类型定义分离
   - 错误信息统一管理

5. 性能优化要求:
   - 避免不必要的重渲染
   - 合理使用 memo 和 useCallback
   - 表单验证去抖动处理

请生成符合以上要求的完整代码，包括:

- 组件主文件
- 类型定义文件
- 错误信息配置
- 使用示例

请描述使用LangChain构建一个文档问答系统的关键技术组件及实现步骤

使用 LangChain 构建文档问答系统主要包含两个核心阶段：

  1. 文档索引阶段(Indexing)：数据准备过程包含三个主要步骤:
    1. 文档加载：使用 Document Loader 加载各种格式的文档。
    2. 文档分块：使用 Text Splitter 将文档切分成合适大小的块。
    3. 向量化存储：为文本块创建向量嵌入(embeddings)并存储到向量数据库中。
  2. 问答检索阶段(Retrieval & Generation)：问签生成过程包含两个主要步骤
    1. 相关文档检索：根据用户问题从向量库中检索最相关的文档片段。
    2. 答案生成：将检索到的文档和用户问题一起传给 LLM 生成最终答案。

假设要开发一个智能工单分类系统，请拆解AI可参与的环节并说明技术选型思路

智能工单分类系统主要涉及工单文本理解、分类决策和自动化处理三个核心环节。我们可以将 AI 技术应用在以下几个关键环节：

  • 工单内容理解
    • 文本预处理：使用 NLP 技术对工单内容进行分词、去除停用词等基础处理。
    • 实体识别：使用命名实体识别(NER)技术提取工单中的关键信息，如产品名称、问题类型等
    • 意图识别：使用 BERT或 GPT等预训练模型理解用户的真实诉求。
  • 智能分类决策
    • 多级分类：基于机器学习模型(如 XGBoost)构建多级分类体系，将工单分发到对应部门。
    • 优先级评估：结合历史数据，使用深度学习模型预测工单紧急程度
    • 相似工单匹配：使用向量数据库(如 Milvus)存储历史工单，快速检索相似案例。
  • 自动化处理
    • 知识库对接：使用 RAG 技术从企业知识库中检索解决方案。
    • 自动回复：使用 LLM 生成个性化回复内容。
    • 工作流联动：通过 API触发后续自动化处理流程

当需要处理超长大模型上下文窗口限制时，有哪些可行的工程解决方案？

处理超长上下文主要有以下几种工程解决方案

  • 文本压缩与分段处理
    • 文本预处理：使用中间截断法(middle truncation)对过长文本进行压缩。
    • 智能分段：将长文本按语义完整性分成多个片段，保持上下文连贯性。
    • 动态窗口：根据查询需求动态调整上下文窗口大小，实现查询感知的上下文化处理。
  • 检索增强生成(RAG)
    • 向量检索：使用向量数据库存储文档片段，按相关性检索。
    • 混合检索：结合关键词和语义检索，提高检索准确性。
    • 动态更新：支持知识库的实时更新，确保信息时效性。
  • 模型优化方案
    • Ring Attention：通过改进注意力机制提升计算效率。
    • 相对位置编码：采用相对位置编码替代绝对位置编码。
    • 模型微调：针对长文本场景进行特定任务微调。

请举例说明假设在电商系统中，哪些功能适合直接使用大模型完成，哪些需要结合工程化手段？

在电商系统中，大模型的应用需要根据场景特点来区分使用方式：

  • 适合直接使用大模型的场景
    • 用户咨询解答：利用大模型的自然语言理解和生成能力，直接处理用户的开放性问题，
    • 商品描述生成：基于商品基础信息，生成富有营销感的商品文案。
    • 个性化回复：根据用户画像和历史交互，生成有温度的客服回复，
  • 需要结合工程化手段的场景
    • 商品检索和推荐：需要结合数据库查询、规则过滤等工程手段来保证准确性和性能。
    • 商品参数问答：由于商品参数高度结构化，需要先用专门的匹配模型选相关属性。
    • 价格区间筛选：对于数值范围的查询，需要使用数据库的范围查询功能。

假设请你设计一个医疗问诊系统，如何平衡AI幻觉带来的风险与效率提升？需要哪些技术手段？

在医疗问诊系统中平衡 AI 幻觉风险与效率需要多层次防护机制。首先应采用RAG技术，通过检索医学知识库提供可靠信息源；其次实施严格的提示工程和边界控制，明确定义AI可回答范围；再次建立多级人机协作模式，让医生监督和干预AI决策；最后实施持续的模型评估和优化。

技术手段包括知识图谱塔强理解、多模态融合提高准确性、不确定性量化帮助识别风险区域，以及可解释性工具让医生理解 AI 推理过程。

AI幻觉现象与医疗风险：AI幻觉是指大语言模型生成看似正确但实际与事实不传的内容，在医疗场景中，这种风险尤为严重，可能导致错误诊断建议、虚构药物信息或治疗方案，甚至可能因此延误患者治疗时机。

问诊场景中可能比较常见的AI幻觉类型：

  • 症状关联幻觉：将不相关症状错误关联到特定疾病
  • 治疗方案幻觉：生成看似合理但实际不存在的治疗方法
  • 药物信息幻觉：提供错误的药物剂量、禁忌或副作用信息
  • 疾病进展幻觉：对疾病发展过程做出不准确预测

设计智能客服系统时，如何通过知识库构建解决长尾问题？

智能客服系统中的长尾问题指的是那些出现领率较低但数量众多的用户咨询，通过构建完善的知识库系统，我们可以有效解决这类问题，具体实现需要从知识获取、知识组织和知识应用三个维度展开。

当大模型API响应延迟超过1秒时，前端可以采取哪些优化策略保证用户体验？

当大模型 API 响应延迟较高时，前端主要可以从以下几个方面进行优化：

  • 立即反馈策略：采用乐观 UI模式，在发送请求的同时立即给用户反馈，不要等待 API 响应后才更新界面。比如：在对话输入框下方立即显示用户发送的消息、显示输入框的 loading 状态、显示骨架屏(Skeleton)预加载效果
  • 流式响应处理：使用 SSE 或 WebSocket 建立长连接、通过 ReadableStream 逐步接收并显示文本内容添加打字机效果增强体验
  • 请求状态管理：设置合理的请求超时时间、添加请求重试机制、优雅降级显示出错提示

使用LangChain时，如何实现多路召回结果的动态权重分配？

在 LangChain.js 中实现多路召回的动态权重分配主要有以下几种方式：

  • 使用EnsembleRetriever：EnsembleRetriever 是 LangChain 提供的一个组合检索器，可以将多个检索器的结果进行组合。它支持不同的权重分配策略。
  • 自定义权重分配逻辑：可以通过实现自定义的权重分配逻辑，根据查询内容或其他因素动态调整不同检索器的权重
  • 查询分析路由：通过查询分析来选择最合适的检索器或调整权重分配。

当大模型上下文窗口扩展到100万token时，哪些现有业务场景可能发生质变？

当大模型上下文窗口扩展至100万token时，以下业务场景可能发生根本性变革：

  • 长文本分析与生成(如法律合同、小说创作);
  • 复杂代码库维护与跨模块开发
  • 多模态长内容处理(如长视频理解)
  • 全流程客服与销售自动化:
  • 金融与医疗的深度决策支持。

如何保证 AI 应用的性能和稳定性？

为了保证 AI 应用的性能和稳定性，需要综合考虑很多方面，从应用设计、外部依赖管理到部署策略都需要考虑。一般来说有以下措施：

  • 异步处理：对于耗时的AI操作，要采用异步处理，避免阻塞服务器主工作线程，提高并发处理能力和系统响应速度，还可以利用 SSE (Server-SentEvent)和 SseEmitter 实现流式输出，提高用户体验
  • 合理的模型选择：选择跟场景、需求相匹配的AI模型，不是所有场景都需要最大、最先进的模型，有时候针对特定任务优化的轻量级模型在成本和延迟上更有优势。比以如计算向量 Embeding 时，就不必选择深度推理能力强的模型。
  • RAG 系统优化：选择高质量的原始文档和合理的切片策略。以及选择合适的向量数据库，比如使用 PGVector 方案，可以对索引和查询参数调优
  • 外部依赖管理：对工具调用、MCP服务及其他外部 API 的调用，实现错误处理和重试机制(比如 Guava Retrying 库)。并且针对所有的外部调用设置合理的超时时间。
  • 对于流量不确定或需要快速迭代的服务，可以考虑 Serverless 部署，按需分配资源、自动伸缩
  • API设计：避免在每个数据块中包含过多冗余信息，只传输核心内容，减少网络负载。
  • 可观测性与监控：集成更全面的监控方案，比如使用 Prometheus + Grafana 追踪关键性能指标、延迟、错误率、资源消耗等

有哪些设计和优化 Prompt 的技巧？请举例说明

设计和优化 Prompt 的核心目标是引导 A1 模型生成符合预期的高质量输出。分享一些技巧：

  • 明确指定任务和角色：清晰地告诉 AI 它需要扮演什么角色以及具体执行什么任务。
系统：你是一位经验丰富的Python教师，擅长向初学者解释编程概念。
用户：请解释 Python 中的列表推导式，包括基本语法和 2-3 个实用示例。
  • 提供详细说明和具体示例：给出足够的上下文信息、期望的输出格式、风格或长度。最好再提供 1-2 个输入输出的范例，帮助型理解任务模式
我将给你一些情感分析的例子，然后请你按照同样的方式分析新句子的情感倾向。

输入: "这家餐厅的服务太差了，等了一个小时才上菜"
输出: 负面，因为描述了长时间等待和差评服务

输入: "新买的手机屏幕清晰，电池也很耐用"
输出: 正面，因为赞扬了产品的多个方面

现在分析这个句子:
"这本书内容还行，但是价格有点贵"
  • 使用结构化格式引导思维：通过列表、表格、JSONSchema或特定分隔符(如XML标签)来组织输入和期望的输出，这些指令更容易被大档型理解、输出也更有条理
分析以下公司的优势和劣势:
公司: Seven

请使用表格格式回答，包含以下列:
- 优势(最少3项)
- 每项优势的简要分析
- 劣势(最少3项)
- 每项劣势的简要分析
- 应对建议
  • 思维链提示法：引导模型展示其推理过程，逐步思考问题，尤其适用于复杂问题，能提高准确性。比如，在解决一个数学应用题时，可以要求 A1: “请一步步思考解决这个问题:首先...然后...最后.."
问题：一个商店售卖T恤，每件15元。如果购买5件以上可以享受8折优惠。小明买了7件T恤，他需要支付多少钱？

请一步步思考解决这个问题:
1. 首先计算7件T恤的原价
2. 确定是否符合折扣条件
3. 如果符合，计算折扣后的价格
4. 得出最终支付金额
  • 分解任务：把复杂的任务分解为一系列更小、更易于管理的步骤，并指导模型按顺序完成每个步骤。例如，要求 AI “第一步:分析用户需求，第二步:草拟解决方案，第三步:评估方案风险。
请帮我创建一个简单的网站落地页设计方案，按照以下步骤:

步骤1: 分析目标受众(考虑年龄、职业、需求等因素)
步骤2: 确定页面核心信息(主标题、副标题、价值主张)
步骤3: 设计页面结构(至少包含哪些区块)
步骤4: 制定视觉引导策略(颜色、图像建议)
步骤5: 设计行动召唤(CTA)按钮和文案
  • 迭代式提示优化和错误分析：很少有人能一次就写出完美的 Prompt。而是根据模型的输出进行分析，如果结果不理想，就逐步修改和完善 Prompt
初始提示: 谈谈人工智能的影响。

[收到笼统回答后]
改进提示: 分析人工智能对医疗行业的三大积极影响和两大潜在风险，提供具体应用案例。

[如果回答仍然不够具体]
进一步改进: 详细分析AI在医学影像诊断领域的具体应用，包括:
1. 现有的2-3个成功商业化AI诊断系统及其准确率
2. 这些系统如何辅助放射科医生工作
3. 实施过程中遇到的主要挑战
4. 未来3-5年可能的技术发展方向
  • 控制输出长度和风格:明确要求输出的字数范围、文本风格(正式、友好、专业)等。
撰写一篇关于气候变化的科普文章，要求:
- 使用通俗易懂的语言，适合高中生阅读
- 包含5个小标题，每个标题下2-3段文字
- 总字数控制在800字左右
- 结尾提供3个可行的个人行动建议

如果一个GPU集群的LLM处理能力为1000 tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1token/s吗?怎么分析性能瓶颈

不会平均变成每人1 token/s。

因为 LLM 并非简单线性分配(直接用除法)资源，而是通过批处理与并发调度来提升吞吐。

若每次批处理包含 100 个用户的请求(每用户 10tokens)，则 1000 用户可以分 10 批处理完。单用户性能是 10tokens/s。实际响应速度取决于Token长度、批处理策略和资源排队机制等。