LLM大模型-术语解释-增强技术类

一、什么是 Prompt 工程Prompt 工程 通过设计输入提示词引导 LLM 输出你想要的结果。模型参数不变变的是你给它的前文。前文不同预测方向就不同。1、Prompt 的核心组成2、创建流程① 明确目标 → 到底要模型做什么 ② 拆解任务 → 分几个步骤 ③ 写初版 → 按7要素写 ④ 测试 → 用真实case跑 ⑤ 迭代 → 根据问题改 ⑥ 固化 → 变成模板3、Prompt 应用场景RAG 问答你是一个企业知识库助手。请仅根据下面提供的资料回答问题。 规则1. 只使用资料中的信息不要编造2. 如果资料中没有答案回答资料中未提及3. 回答要简洁不超过200字4. 在结尾标注引用的资料编号 资料[1]{doc_1}[2]{doc_2}[3]{doc_3}问题{user_question}回答4、Prompt 应用场景Agent 工具调用你是一个能调用工具的助手。可用工具1. get_weather(city: string)功能查询城市天气 示例get_weather(北京)2. get_exchange_rate(from: string, to: string)功能查询汇率 示例get_exchange_rate(USD,CNY)3. calculator(expression: string)功能计算数学表达式 示例calculator(36 * 24)请以 JSON 输出你的行动{tool:工具名,args:{...}}如果不需要工具输出{tool:none,answer:你的回答}用户问题{user_question}5、评估方法二、什么是 RAGRAGRetrieval-Augmented Generation检索增强生成 先查资料再让 LLM 基于资料回答。它解决了 LLM 的两个核心痛点知识过时和幻觉。1、为什么需要 RAG问题说明知识截止训练数据有截止日期之后的事不知道幻觉不知道就编一本正经胡说私有知识缺失你公司的文档、内部规范它没学过无法溯源说了答案你不知道它从哪来的传统解法 vs RAG方案做法问题微调把新知识训进模型贵、慢、更新难RAG把资料检索出来拼进 Prompt便宜、快、可更新2、RAG 的核心流程阶段一离线索引提前做好这一步是建库一次做好后续复用。 ① 文档收集 → 企业文档、PDF、网页、数据库 ② 文档切分 → 切成小块chunk ③ 向量化 → 每块用 Embedding 模型变成向量 ④ 存入向量库 → 向量 原文一起存阶段二在线检索生成每次提问核心先找再答。 ① 用户提问 →公司年假怎么算② 问题向量化 → 用同一个 Embedding 模型变成向量 ③ 向量检索 → 在向量库里找最相似的 Top-K 文档块 ④ 拼进 Prompt → 把检索到的资料 问题拼成 Prompt ⑤ LLM 生成 → 模型基于资料回答 ⑥ 返回答案 → 可带引用来源【离线索引】 文档 → 切分 → Embedding → 向量库 ↑ │ 存起来 │ 【在线检索生成】 │ │ 用户提问 → Embedding → 向量检索 ┘ ↓ Top-K 相关文档 ↓ ┌───────────────────────┐ │ Prompt: │ │ 资料[检索到的文档]│ │ 问题{用户问题}│ │ 请仅根据资料回答 │ └───────────────────────┘ ↓ LLM ↓ 回答 引用3、RAG 的关键组件4、RAG 的关键技术点4.1、切分策略Chunking切得好不好直接决定检索质量。策略说明固定长度按 token 数切简单但可能切断语义递归切分按段落→句子→词逐级切语义切分按语义边界切效果最好重叠切分chunk 之间留重叠避免断章4.2、检索策略策略说明向量检索语义相似能搜近义词关键词检索BM25精确匹配混合检索两者结合效果最好多路召回多种方式召回再合并4.3、重排Rerank向量检索快但粗Rerank 精但慢。加 Rerank 通常能显著提升效果向量检索 → Top50候选 ↓ Reranker 精排 → Top5最相关 ↓ 喂给 LLM4.4、查询改写Query Rewriting用户问题可能表述不好先改写再检索用户问题 → 【你加的查询改写】→ 向量检索 → 喂 LLM → 回答向量检索也好BM25 关键词检索也好它们匹配的是文本之间的相似度。但用户提问和文档表述之间经常有巨大鸿沟原问题这个咋弄改写XX 功能怎么配置用户用的是口语、省略、指代、上下文依赖的表达文档用的是规范、完整、术语化的表达。 直接把“这个咋弄”扔进向量库检索出来的大概率是垃圾。LangChain4j 实现方案LangChain4j 将所有改写策略统一抽象为 QueryTransformer 接口核心方法是 transform(Query query)返回一个或多个改写后的 Query 集合。5、RAG 的常见问题问题原因解决检索不到切分差、Embedding 差优化切分、换模型检索不准只有向量检索加关键词、加 Rerank答非所问Prompt 没约束加仅根据资料幻觉资料里没有模型硬编 要求没有就说不知道上下文超长召回太多控制 Top-K、压缩多跳问题需要多步推理多轮检索、Agentic RAG三、什么是向量数据库向量数据库 专门用来存向量、并按相似度快速查找的数据库。它是 RAG 检索的核心组件。1、为什么需要它传统数据库MySQL擅长精确匹配SELECT * FROM docs WHERE title年假规定但 RAG 要的是语义相似怎么休假应该能匹配到年假申请流程这两个句子没有一个字相同但语义相近。 传统数据库做不到。向量数据库就是为找相似而生的。2、它存什么存的是向量 原文或元数据┌─────────────────────────────────────────┐ │id│ vector │ content │ ├─────────────────────────────────────────┤ │1│[0.2, -0.5,0.8...]│年假规定...│ │2│[0.1,0.3, -0.2...]│请假流程...│ │3│[-0.4,0.9,0.1...]│报销制度...│ └─────────────────────────────────────────┘ vector文档块经 Embedding 模型算出的向量 content原始文本检索到后要喂给 LLM metadata可选如来源、时间、权限3、相似度计算给定查询向量和库里每个向量比距离余弦相似度越接近 1越相似。度量含义常用余弦相似度看方向是否一致最常用内积方向和长度都看常见欧氏距离看直线距离较少4、向量索引加速检索不精确比对所有向量而是用近似最近邻ANN算法快速找。问题要对太多向量算余弦导致速度太慢。向量数据库用了专门的索引算法加速 朴素做法100万向量 → 逐个算余弦 → 排序 → Top-K ANN 近似最近邻做法不追求对每个向量都算只对“可能最近”的一小部分算。100万向量 → 索引快速筛选 →1000候选 → 算余弦 → 排序 → Top-K5、和传统数据库对比项目传统数据库向量数据库查询方式精确匹配、like相似度查找数据类型数字、字符串向量索引B 树HNSW、IVF典型场景事务、CRUD语义检索代表MySQL、PGMilvus、Qdrant、PgVector6、主流向量数据库产品类型特点Milvus专业向量库功能全大规模Qdrant专业向量库易用Rust 写的Weaviate专业向量库自带模块Chroma轻量适合原型PgVectorPG 插件已有 PG 就直接用Redis内存库快适合缓存Elasticsearch搜索引擎支持混合检索Faiss库非库Meta 出的常被集成7、在 RAG 里的位置向量数据库负责存和找是 RAG 的记忆中枢。【离线索引】 文档 → 切分 → Embedding → 存入向量数据库 ↑ 【在线检索】 │ │ 问题 → Embedding → 向量数据库查询 ┘ ↓ Top-K 相似文档 ↓ 拼进 Prompt ↓ LLM8、应用示例LangChain4j// 用 PgVector EmbeddingStoreTextSegmentstorePgVectorEmbeddingStore.builder().host(localhost).port(5432).database(mydb).user(user).password(pass).table(embeddings).dimension(1536).build();// 存 store.add(embedding, textSegment);// 查 Embedding queryEmbeddingembeddingModel.embed(怎么休假).content();ListEmbeddingMatchTextSegmentmatchesstore.findRelevant(queryEmbedding,5);// matches 就是 Top-5 相关文档四、什么是 AgentAgent智能体 能自己感知、规划、调用工具、执行任务最终达成目标的 AI 系统。1、普通 LLM如 ChatGPT Agent区别角色问答机器执行者交互你问一句它答一句你给目标它自己拆解步骤能力生成文本生成文本 调用工具 操作环境例子“帮我写个请假邮件”“帮我请下周三的假” → 它自己查日历、填表单、发邮普通 LLM 是“嘴”Agent 是“嘴 手 脚 记忆”。2、Agent 的四大核心模块┌─────────────────────────────────────┐ │ Agent │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 感知 │───→│ 规划 │ │ │ │Perception│ │ Planning │ │ │ └──────────┘ └────┬─────┘ │ │ │ │ │ ↓ │ │ ┌──────────┐ ┌──────────┐ │ │ │ 记忆 │←──→│ 行动 │ │ │ │ Memory │ │ Action │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘模块作用技术实现感知接收用户指令、环境信息文本输入、API、传感器规划理解目标、拆解任务、制定计划LLMGPT、Claude、Qwen 等记忆存历史交互、中间结果、知识向量数据库、KV 存储行动调用工具、执行操作Function Calling、MCP、API3、Agent 的常见形态类型说明例子对话 Agent多轮对话 工具调用ChatGPT with tools工作流 Agent按固定流程执行Coze、Dify 工作流自主 Agent自己规划、自己反思AutoGPT、BabyAGI多 Agent 系统多个 Agent 协作MetaGPT、CrewAI编码 Agent专做编程任务Cursor、Claude Code五、什么是工具调用工具调用 让 LLM 能够调用外部函数/API 来获取信息或执行操作的能力。LLM 本身只会生成文本。你问它“今天天气怎么样”它只能根据训练数据瞎猜。但如果你给它一个 getWeather(city) 工具它就能先判断“我需要调用这个工具”然后框架去执行把真实结果拿回来再生成回答。1、为什么需要工具调用LLM 有三个天生短板短板说明工具调用如何解决知识过时训练数据有截止日期调用搜索、数据库不会算数概率模型不擅长精确计算调用计算器、代码执行不能操作无法发邮件、下单、改文件调用 API、写文件工具调用就是给 LLM 装上“手和脚”。2、完整流程关键点LLM 不直接执行工具它只输出“我要调用哪个工具、参数是什么”真正执行的是框架。用户帮我查下周三成都天气如果不下雨就订机票 ┌─────────────────────────────────────────────────────┐ │1. LLM 分析意图 │ │ → 需要调用 getWeather(city成都,date下周三)│ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │2. 框架执行工具 │ │ → getWeather(成都,2026-10-01)│ │ → 返回{weather:晴,temp:25}│ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │3. 结果回传给 LLM │ │ → LLM 判断晴天满足条件 │ │ → 需要调用 bookFlight(from成都,to上海)│ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │4. 框架执行工具 │ │ → bookFlight 返回{status:success,...}│ └──────────────────────┬──────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────┐ │5. LLM 生成最终回答 │ │ → “下周三成都晴25°C已为您订好机票...” │ └─────────────────────────────────────────────────────┘3、技术实现三个核心要素工具定义Schema每个工具需要用 JSON Schema 描述清楚叫什么、干什么、参数有哪些、参数类型和含义。{name:getWeather,description:查询指定城市指定日期的天气,parameters:{type:object,properties:{city:{type:string,description:城市名},date:{type:string,description:日期 YYYY-MM-DD}},required:[city,date]}}LLM 的决策LLM 收到用户问题和工具列表后输出一个结构化的调用意图{tool_calls:[{name:getWeather,arguments:{city:成都,date:2026-10-01}}]}框架的执行与回传框架解析这个意图调用对应的 Java 方法/API把结果作为 tool 角色的消息回传给 LLMLLM 继续推理Java 中的实现LangChain4j 示例//1. 定义工具 public class WeatherTools{Tool(查询指定城市指定日期的天气)public String getWeather(P(城市名)String city, P(日期格式 YYYY-MM-DD)Stringdate){// 实际调用天气 APIreturn{\weather\:\晴\,\temp\: 25};}}//2. 注册工具并构建 Agent interface TravelAssistant{String chat(String message);}TravelAssistant assistantAiServices.builder(TravelAssistant.class).chatModel(model).tools(new WeatherTools()).build();//3. 调用 String replyassistant.chat(下周三成都天气怎么样);// LLM 自动决定调用 getWeather框架执行后返回结果六、什么是记忆机制记忆机制 Agent 存储、检索、更新信息的能力让它能记住过去、利用经验、保持上下文连贯。没有记忆的 Agent就像失忆症患者每次对话都是第一次见面。1、为什么需要记忆场景没有记忆会怎样有记忆会怎样多轮对话你说“他呢”它不知道“他”是谁记得上一轮聊的是谁长期任务做到第三步忘了第一步的结论全程保持任务状态个性化每次都问你的偏好记得你爱靠窗座位经验积累同样的错误反复犯从失败中学习2、记忆的分类┌─────────────────────────────────────────────────┐ │ Agent 记忆 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────┐ │ │ │ 短期记忆 │ │ 长期记忆 │ │ 程序记忆 │ │ │ │ Working │ │ Long-term │ │Procedural│ │ │ │ Memory │ │ Memory │ │ Memory │ │ │ └─────────────┘ └─────────────┘ └─────────┘ │ │ │ │ │ │ │ 当前对话上下文 历史对话/知识 学到的技能 │ │ 任务中间状态 用户偏好/事实 操作流程 │ └─────────────────────────────────────────────────┘类型存什么存储方式生命周期短期记忆当前对话、任务中间结果内存、上下文窗口会话级长期记忆历史对话、用户偏好、事实知识向量数据库、KV 存储持久程序记忆学到的操作流程、技能Prompt 模板、代码持久3、短期记忆上下文窗口管理短期记忆最直接的做法就是把对话历史塞进 Prompt[System]你是一个助手[User]帮我订机票[Assistant]好的去哪[User]上海[Assistant]什么时候[User]下周三但上下文窗口有限比如 128K token对话长了就装不下。常见策略策略做法优缺点全量保留所有历史都塞进去简单但很快超限滑动窗口只保留最近 N 轮省 token但丢早期信息摘要压缩把早期对话总结成一段话平衡但摘要可能丢细节分层记忆近期全量 远期摘要效果最好实现复杂4、长期记忆向量数据库的核心作用存储流程对话/文档 → Embedding → 向量 原文 → 存入向量数据库检索流程当前问题 → Embedding → 向量数据库查询 → Top-K 相关记忆 ↓ 拼进 Prompt5、记忆的完整生命周期记忆不是“存进去就完了”它有自己的生命周期从信息进入系统到被使用再到被淘汰或升华。完整流程分为 四个基础阶段 和一个 独立加工层。┌─────────────────────────────────────────────────────────────┐ │ 记忆的完整生命周期 │ │ │ │ 新信息 │ │ │ │ │ ↓ │ │ ┌────────┐ │ │ │ 编码 │ Embedding、摘要、结构化提取、重要性评分 │ │ └───┬────┘ │ │ ↓ │ │ ┌────────┐ │ │ │ 存储 │ 短期/长期/程序/结构化写入对应介质 │ │ └───┬────┘ │ │ ↓ │ │ ┌────────┐ │ │ │ 检索 │ 语义搜索 关键词 时间衰减 重要性加权 │ │ └───┬────┘ │ │ ↓ │ │ ┌────────┐ │ │ │ 更新 │ 修改冲突检测、合并相似聚类、遗忘衰减│ │ └───┬────┘ │ │ ↓ │ │ ┌─────────────────────────────────────┐ │ │ │ 反思与巩固定期触发 │ │ │ │ 反思提炼高层洞察 │ │ │ │ 巩固短期转长期、碎片转结构 │ │ │ └─────────────────────────────────────┘ │ │ │ │ │ ↓ │ │ 记忆库越来越精炼检索越来越准 │ └─────────────────────────────────────────────────────────────┘这四个阶段是每次记忆操作都会走的流程是“增删改查”级别的。阶段做什么技术手段编码把信息转成可存储形式Embedding、摘要、结构化提取存储写入记忆库向量数据库、KV、图数据库检索按需召回语义搜索、关键词混合检索更新新记忆入库时对已有记忆做修改、合并、遗忘冲突检测、时间衰减、重要性评分修改Update新信息与旧记忆冲突时调整旧记忆。旧记忆用户偏好靠窗 新对话用户说“这次帮我订过道” ↓ 冲突检测 操作更新为“用户偏好靠窗但近期可能选过道” 或直接覆盖并记录时间戳合并Merge多条相似记忆归并成一条高层记忆。记忆1用户周一订了靠窗 记忆2用户周三订了靠窗 记忆3用户周五订了靠窗 ↓ 相似聚类 LLM 摘要 合并用户偏好靠窗置信度高 ↓ 删除原始碎片减少噪声遗忘Forget按策略淘汰低价值记忆。更新触发时机每次新记忆入库时。策略做法时间衰减越久远权重越低重要性评分低分记忆优先淘汰访问频率长期不被检索的淡化容量上限超过 N 条淘汰最旧反思与巩固独立加工层不在基础流水线上是定期触发的、对记忆库整体的高层加工。反思Reflection从零散记忆中提炼高层洞察。触发时机积累 N 条新记忆后、任务失败后、每日结束时。原始记忆情景记忆 - 周一用户订了靠窗 - 周三用户订了靠窗 - 周五用户订了靠窗 ↓ LLM 反思 高层记忆语义记忆 - 用户偏好靠窗座位 - 订票时应主动询问座位偏好巩固Consolidation短期转长期碎片转结构情景转语义。操作说明短期 → 长期会话重要结论写入向量数据库碎片 → 结构多条记忆组织成知识图谱情景 → 语义从具体事件提取通用规律程序化重复成功流程固化为技能类比人脑睡眠时海马体把短期记忆转移到皮层形成长期记忆。各阶段对比阶段触发时机作用范围核心操作编码新信息进入时单条信息转成可存储形式存储编码完成后单条记忆写入介质检索需要时按查询召回相似度搜索 过滤更新新记忆入库时单条或局部修改、合并、遗忘反思巩固定期触发记忆库整体提炼、总结、固化七、什么是思维链CoT思维链Chain of ThoughtCoT是让大模型在给出答案前先展示推理过程的一种技术。它解决了 LLM 的一个核心问题直接给答案容易错一步步想反而更准。1、落地方式手动实现你在 Prompt 里写这是最原始的方式完全由你控制String promptuserQuestion \n让我们一步步思考。;String responsechatModel.generate(prompt);框架自动实现LangChain4j 本身没有专门的 CoT 注解但它的 AiServices 支持通过 SystemMessage 注入推理指令 interface HrAssistant{SystemMessage(回答前请一步步推理再给结论。)String chat(String message);}Spring AI 通过 Advisor 机制实现类似效果 ChatClient clientChatClient.builder(chatModel).defaultAdvisors(new SimpleLoggerAdvisor()).build();String responseclient.prompt().system(回答前请一步步推理。).user(question).call().content();模型内置什么都不用做推理模型o1、o3、DeepSeek-R1自带 CoT模型内部会自动展开推理你甚至看不到完整过程只能看到摘要。// 用推理模型时不需要加任何 CoT 指令 String responsereasoningModel.generate(userQuestion);// 模型内部自动做 CoT返回最终答案2、实现方式1、Zero-shot CoT零样本做法Prompt 里加一句“让我们一步步思考”。用户问题 \nLets think step by step.优点缺点零成本改一行Prompt推理质量不稳定2、Few-shot CoT少样本做法给几个带推理过程的示例让模型模仿。Q: 餐厅有23个苹果用了20个做午餐又买了6个现在有几个 A: 开始23个 → 用了20个剩3个 → 又买6个369→ 答案9。 Q: 小明有5个苹果吃了2个又买了3个现在有几个 A:优点缺点推理格式可控效果稳定需要精心设计示例占 token3、结构化 CoTStructured CoT做法把推理拆成固定阶段用模板约束输出。请按以下格式推理 【理解问题】... 【已知条件】... 【推理过程】... 【结论】...优点缺点输出可解析适合 Agent模板设计需要经验4、多路径推理Self-Consistency / ToT做法采样多条推理路径投票或搜索选最优。方法做法Self-Consistency生成多条 CoT对最终答案投票Tree of Thoughts (ToT)树状展开允许回溯和剪枝Graph of Thoughts (GoT)图状结构支持合并、循环优点缺点准确率最高token 消耗成倍增加延迟高3、落地方式和实现方式区别“四种实现方式”是 CoT 的形态分类Zero-shot、Few-shot、结构化、多路径“手动/半自动/全自动”是落地方式分类。两者是不同维度交叉使用不是一回事。八、向量检索九、重排序九、工作流九、提示注入九、越狱九、内容过滤九、多模态增强九、长上下文增强