开头：为什么技术负责人绕不开大模型架构

去年这个时候，我还在跟团队争论"前端要不要学 Python"。今年，我们组已经在维护一个真正跑在生产环境里的需求拆解 Agent——产品经理丢进来一段自然语言需求，它自动拆成前端任务、后端任务、接口清单和验收标准，输出结构化的技术 Spec；在医疗项目里，我们还基于开源模型做了私有化部署的智能预问诊。

这两件事逼我把大模型应用架构从头捋了一遍。原因很简单：当你只是"用" ChatGPT 写代码时，你不需要懂 Transformer；但当你要对一个 AI 功能的准确率、延迟、成本、数据安全负责时，不懂底层机制，你连问题出在哪一环都判断不了——是 Prompt 写得烂？检索没召回？模型能力不够？还是该上微调了？

这篇文章是我给团队做内部分享的整理版，试图用工程师的语言讲清楚四件事：大模型到底怎么工作、给它灌知识的三种方式怎么选、RAG 全链路的坑在哪、Agent 架构怎么搭。不讲数学推导，只讲工程判断。

一、大模型是怎么工作的：用工程语言理解 Transformer

1.1 Self-Attention：让每个词"开全局视野"

2017 年 Google 那篇《Attention Is All You Need》提出的 Transformer，是今天 GPT、Claude、DeepSeek、GLM 所有大模型的共同底座。它最核心的机制叫 Self-Attention（自注意力）。

一句话理解：模型处理句子里每个词的时候，会动态计算它和句子中所有其他词的关联权重，然后加权聚合上下文信息。

工程类比最直观的是 Q/K/V 三个矩阵——Query（查询）、Key（键）、Value（值），你就理解成一次搜索：

  • Query 是你输入的搜索词（当前这个词想找什么信息）；
  • Key 是每个文档的标题（其他词能提供什么信息）；
  • Value 是文档正文（真正被取走的内容）。

当前词拿自己的 Query 去和所有词的 Key 算相关性，得到一组权重（softmax 归一化），再用这组权重对所有 Value 加权求和，就是这个词融合了全文上下文后的新表示。公式是 Attention(Q,K,V) = softmax(QKᵀ/√dₖ)V，不用背，知道"Q 和 K 算相关度、加权取 V"就够了。多头注意力（Multi-Head Attention） 就是并行跑好几组 Q/K/V，每组关注不同维度的关系——语法搭配、语义关联、指代消解各管一摊。

1.2 为什么 Transformer 干掉了 RNN

上一代文本模型 RNN 的致命问题是必须逐词串行计算——处理第 100 个词时，信息要从第 1 个词一路传递过来，长距离依赖必然衰减。Transformer 带来两个工程上的巨大红利：

  1. 并行计算：整句话所有词两两之间同时算注意力，训练时能把 GPU 吃满，这是模型规模能从亿级参数冲到万亿级的前提；
  2. 全局视野：任意两个词直接交互，信息路径是 O(1)，长文本不再"忘事"。

有个容易忽略的细节：Self-Attention 本身不含语序信息——"狗咬人"和"人咬狗"在它看来词袋是一样的。所以必须额外注入**位置编码（Positional Encoding）**告诉模型词的顺序。

架构上还有两个分支：Encoder（编码器） 用双向注意力，每个词能看到前后文，擅长"理解"，代表是 BERT，适合分类、抽取任务；Decoder（解码器） 用掩码注意力，每个词只能看到已经生成的词，擅长"生成"，GPT 系列都是 Decoder-only 架构，自回归地一个词一个词往外蹦。今天主流 LLM 基本都是 Decoder 路线。

1.3 四个必须建立直觉的概念

概念 工程含义 实战提醒
Token 模型处理文本的最小单位，不等于词或字 英文约 1 token ≈ 0.75 个单词，中文一个字约 1~2 token；计费和上下文长度都按 Token 算
参数量 模型里可训练权重的数量，单位 B（十亿） 7B = 70 亿参数；参数越大"涌现能力"越强，但推理成本越高
上下文窗口 单次能处理的最大 Token 数（输入+输出共享） 128K 约等于一本长篇小说；超窗必须截断或用 RAG 外置知识
Temperature 控制输出随机性的采样参数（0~2） 事实问答/代码生成调到 0 附近求确定性；文案创作调高求多样性

补一句模型是怎么炼成的：预训练（万亿 token 自监督学习，成本千万级，得到基座模型）→ SFT 监督微调（高质量指令数据教它听话）→ RLHF（基于人类反馈的强化学习，让输出有用、无害、诚实）。理解这个链路你就明白：模型的知识截止于预训练数据，它的"性格"来自微调与对齐。

二、给大模型"灌知识、教做事"：Prompt / RAG / 微调怎么选

这是做 AI 应用最核心的一个架构决策。三种手段本质区别在于动不动模型参数：

维度 Prompt Engineering RAG 检索增强 Fine-tuning 微调
原理 不改模型，精心设计输入引导输出 不改模型，外挂知识库，检索内容拼进 Prompt 用领域数据继续训练，修改模型权重
知识更新 靠提示词注入，容量小 更新知识库即可，分钟级生效 需重新训练，天~周级
成本 极低 中等（向量库+检索链路） 高（GPU 训练+数据标注）
技术门槛 低 中 高（需要 ML 工程能力）
解决什么 输出格式、风格、任务引导 知识缺失、幻觉、私有数据问答 领域风格、专用技能、固定口吻
典型技术 Few-shot、CoT、角色设定 Embedding + 向量库 + LangChain 全量微调、LoRA/QLoRA（PEFT）

我的决策建议很简单，按这个顺序试：

先 Prompt → 不够加 RAG → 还不行再微调。

  • 缺知识，用 RAG：模型不知道你们公司的报销制度、不知道上周刚改的接口文档——这是知识问题，微调治不了，RAG 实时更新知识库就行；
  • 改风格/教技能，用微调：你要让模型输出一种特定的医疗文书格式、模仿某种固定语气，或者在垂直任务上稳定提分，这时候微调才值得；
  • 定格式/定流程，用 Prompt：结构化 JSON 输出、思维链引导、角色设定，提示工程能解决的绝不搞重的。

三者不互斥，我们生产系统是"优秀 Prompt + RAG 知识库 + 微调过的领域模型"组合拳。

关于微调多说一句：别上来就想全量微调，那是土豪玩法。企业落地主流是 LoRA（低秩适配）——冻结原模型参数，只训练旁挂的两个小矩阵，参数量是全量微调的 0.1%~1%，一张消费级显卡就能微调 7B 模型；QLoRA 再叠加 4bit 量化进一步省显存。这类技术统称 PEFT（参数高效微调）。

Prompt 侧几个我们天天用的技巧：角色设定（“你是资深架构师”）、Few-shot（给 3 个输入输出范例让它模仿）、CoT 思维链（要求一步步思考，推理类任务准确率明显提升）、结构化输出（强制 JSON 便于程序解析）、以及边界约束（“不知道就回答’未找到相关信息’，禁止编造”——这句话在 RAG 场景里价值千金）。

三、RAG 架构实战：六个环节，全是坑

RAG（Retrieval-Augmented Generation，检索增强生成） 一句话：回答问题前，先从外部知识库检索出相关文档片段，和问题一起塞进 Prompt，让大模型"开卷考试"。

它解决四个痛点：模型知识有时效截止、不懂企业私有数据、幻觉（Hallucination） 一本正经编造、答案无法溯源。

完整链路分两个阶段：

【离线 · 知识库构建】
文档采集(PDF/Word/Confluence) → 解析清洗 → 文档切分Chunking
  → Embedding向量化 → 存入向量数据库(向量+原文+元数据)

【在线 · 检索生成】
用户提问 → 问题向量化(同一个Embedding模型) → 相似度检索Top-K(余弦/ANN)
  → 重排序Rerank → 拼接Prompt(上下文+问题) → LLM生成答案(附引用来源)

核心伪代码长这样：

# ========== 离线阶段：构建知识库 ==========
def build_index(documents):
    for doc in documents:
        text = parse(doc)                              # 1. 解析：PDF/Word → 纯文本
        pieces = split(text, chunk_size=400, overlap=50)  # 2. 切分：400 token/块，重叠50
        for p in pieces:
            vec = embedding_model.encode(p)            # 3. 向量化：文本 → 高维向量
            vector_db.insert(vector=vec, text=p, metadata={"source": doc.name})

# ========== 在线阶段：问答 ==========
def rag_answer(question):
    q_vec = embedding_model.encode(question)           # 4. 问题向量化（必须同一模型！）
    docs  = vector_db.search(q_vec, top_k=5, metric="cosine")  # 5. ANN 相似度检索
    docs  = reranker.rerank(question, docs, top_k=3)   # 6. 重排序，取最相关3段
    context = "\n".join(d.text for d in docs)

    prompt = f"""你是企业知识库助手，请仅根据以下资料回答问题，
资料中没有依据时请明确说"未找到相关信息"，不要编造。
【参考资料】{context}
【问题】{question}"""

    answer = llm.generate(prompt, temperature=0)       # 低温保证事实性
    return answer, citations=[d.metadata["source"] for d in docs]  # 附引用，可溯源

每个环节都有坑，按踩坑频率排：

  1. 文档切分（Chunking）：块太大，检索不精确还浪费 token；块太小，上下文被割裂、语义残缺。我们用"固定长度 + overlap 重叠窗口"兜底，重要文档按标题层级做语义切分。chunk_size 和 overlap 是要拿真实问题集反复调的参数，没有银弹。
  2. Embedding 向量化：语义相近的文本向量距离相近。铁律：入库和查询必须用同一个 Embedding 模型，否则向量空间完全不匹配，检索结果是垃圾。常用模型 OpenAI text-embedding-3、开源 BGE/M3E。
  3. 向量数据库：核心能力是 ANN（近似最近邻）搜索，索引算法 HNSW、IVF。选型后面细说。
  4. 检索：相似度度量余弦相似度最常用。注意纯向量检索会漏掉精确匹配——查订单号、药品名、人名时，语义相似但字面不同就召回不了，生产环境务必上混合检索：向量检索（语义）+ BM25 关键词检索（精确）。
  5. 重排序（Rerank）：向量检索是"粗排求全"（快但糙），用 Cross-Encoder 对 Top-K 再做一次精排（求准），答案质量提升非常明显，这步钱花得值。
  6. 增强生成：Prompt 里一定写死"仅根据资料回答、资料不足就明说"，temperature 调低，答案带上引用来源。

记住一句话：RAG 的效果天花板是检索质量，不是模型能力。 Garbage in, garbage out——相关文档压根没召回，再强的模型也答不对。另外别搞混：RAG 全程不训练、不改模型参数，这是它和微调的本质区别，也是它知识能分钟级更新的原因。

四、Agent 架构：让大模型长出手脚和记忆

4.1 Agent = LLM + 规划 + 记忆 + 工具

Agent（智能体） 是以大模型为大脑，能自主感知环境、规划任务、调用工具、根据反馈迭代直到完成目标的系统。和一问一答的聊天机器人区别在于：多步执行、使用工具、自主决策循环。

经典类比：LLM 是颗聪明的大脑，但没有手也没有笔记本。Agent 给它配齐三样东西：

组件 职责 技术实现
规划 Planning 把复杂目标拆成子任务，边执行边反思调整 任务分解、ReAct、Reflection 自我反思、Plan-and-Execute
记忆 Memory 存历史信息供后续决策 短期记忆 = 上下文窗口里的对话历史；长期记忆 = 外部向量库（RAG 式检索历史经验）
工具调用 Tool Use 突破"只会聊天"，操作外部世界 Function Calling：模型输出结构化调用请求 → 框架执行 → 结果回喂。工具包括搜索、代码解释器、HTTP API、数据库、发邮件

4.2 ReAct：想一想，做一步，看一看

Agent 最主流的执行模式是 ReAct（Reasoning + Acting）：推理和行动交替循环——先 Thought（想下一步干嘛），再 Action（调工具），拿到 Observation（观察结果），接着再想……直到信息足够给出 Final Answer。

# 场景：需求拆解 Agent 评估"这个需求要不要调风控接口"
Thought: 这个需求涉及退款金额校验，我需要先查现有风控服务的能力边界
Action: search_knowledge_base(query="风控服务 退款 限额 接口")
Observation: 风控服务提供 /risk/check 接口，支持金额限额校验，单日上限5万
Thought: 金额超限场景需要走人工审核流，我再确认下审核流的接口
Action: call_api("GET /api/workflow/audit-spec")
Observation: 审核流接口为 /workflow/create，需传 businessType、amount、operator
Thought: 信息齐了，可以输出任务拆解：前端2个任务、后端3个接口、1个人工审核节点
Final Answer: { 任务清单JSON... }

这个循环的价值在于：把模型的推理链和外部工具调用交织起来，让它能获取实时信息、验证假设、出错重试。

顺便厘清几个关系：RAG 是单轮的"检索→生成"，工具固定、流程确定；Agent 是多轮自主循环，模型自己决定调什么工具、调几次、何时停。RAG 完全可以作为 Agent 的一个工具（“知识库检索工具”）被注册进去。而 Function Calling 是 Agent 调工具的底层机制。

4.3 多 Agent 协作：别急着上

单 Agent 能力不够时，可以让多个角色化 Agent 分工，模拟人类团队。三种常见模式：

  • 编排式（Orchestrator）：一个主管 Agent 拆任务、分派给专家 Agent、汇总结果——像项目经理带前端/后端/测试；
  • 流水线式（Pipeline）：固定工序顺序传递，前一个输出是后一个输入——需求分析 → 设计 → 编码 → 评审；
  • 协商式（Debate）：多个 Agent 平等辩论、互相批评，裁判 Agent 收口。

框架层面，AutoGen（微软）、MetaGPT（模拟软件公司角色）、CrewAI、LangGraph（基于图/状态机的有状态编排）是主流。

但我必须泼盆冷水：多 Agent 的代价是真实的——Token 消耗成倍涨、延迟变长、错误会在 Agent 之间传播放大。我们的经验是：简单任务单 Agent + 几个工具就够了，只有复杂、开放、步骤数本来就多的任务才值得上多 Agent。为了架构好看而堆 Agent，是新手最容易犯的错。

五、技术选型与工程现实

5.1 闭源 API vs 开源自部署

维度 闭源 API（GPT/Claude/Gemini） 开源自部署（DeepSeek/Qwen/GLM/LLaMA）
数据安全 数据出域，敏感行业有合规风险 数据不出内网，金融/医疗/政务首选
成本模型 按 Token 计费，量小划算、量大昂贵 一次性 GPU 投入，量大后边际成本低
能力上限 旗舰模型最强 略逊但差距快速缩小，国产模型已相当能打
可定制 不可改权重 可自由微调、量化、改架构
运维 零运维开箱即用 需 GPU 集群、推理框架、运维能力

我们的实践：医疗项目因为数据合规硬要求，走开源模型私有化部署；内部效能工具（需求拆解、代码辅助）非敏感数据，直接调闭源 API 抢速度。这不是技术优劣题，是合规、成本、团队能力的联合约束题。

5.2 向量数据库与框架

  • 向量库：大规模生产自建选 Milvus（开源分布式，国产，支持十亿级向量）；想省事选 Pinecone（全托管 SaaS）；做原型和小规模应用 Chroma（嵌入式轻量）足矣。已有 PostgreSQL 的团队，PGVector 插件也能扛住不小的量。
  • 编排框架：LangChain 生态最全，通用编排（Chain、Agent、工具、记忆抽象）；LlamaIndex 专注数据接入和 RAG，文档问答场景更顺手。低代码平台 Dify/Coze 适合快速验证业务流程。

5.3 推理优化：省钱三板斧

自部署场景下，三个手段立竿见影：

  1. 量化（Quantization）：权重从 FP16 压缩到 INT8/INT4，显存降 2~4 倍、推理提速，精度损失很小（GPTQ、AWQ、GGUF）。训练用浮点，推理可量化；
  2. 知识蒸馏（Distillation）：用大模型（教师）的输出训练小模型（学生），“大模型教小模型”，小模型跑得快成本低，适合边缘部署；
  3. 推理引擎工程优化：KV Cache（缓存已算过的注意力键值）、连续批处理 Continuous Batching（vLLM 的核心）、PagedAttention、投机解码。再加上剪枝、张量并行，目标一致：不掉精度的前提下让模型更小、更快、更便宜。

5.4 幻觉：缓解，不是消灭

幻觉的根源是模型本质在做"概率预测下一个词"，它优化的是语言流畅，不是事实正确。五道防线一起上：

  1. RAG——基于真实资料作答并附引用，是最有效的工程手段；
  2. 提示词约束——“仅根据资料回答、不确定就说不知道”，temperature 调低；
  3. 微调/RLHF——用高质量事实数据强化诚实性；
  4. 核查 Agent——生成后用搜索/工具二次验证，Reflection 自我纠错；
  5. 人在回路（Human-in-the-loop）——医疗、法律、金融场景，AI 只做辅助，关键决策必须人审核。

说句实话：RAG 也只能缓解幻觉，不能消灭。谁跟你说"答案 100% 正确"，谁就是在忽悠。

5.5 成本控制

  • 模型分级路由：简单任务走小模型/便宜模型，复杂任务才调旗舰——像存储的冷热分层，这是降本最大头；
  • Prompt 瘦身：RAG 只传最相关的 Top-K 片段，别把长上下文当垃圾桶；常见问答做语义缓存（Semantic Cache）；
  • 上下文管理：对话历史及时摘要压缩，超窗截断；
  • 流式输出（Streaming）：SSE 逐字返回，首字延迟（TTFT）大幅降低，用户体感好很多——前端同学这块最熟。

六、补上一课：怎么评估一个 AI 功能好不好

做工程的人最终要对指标负责。分类任务的评估体系值得每个 AI 应用负责人搞懂，核心是混淆矩阵四个数：TP（真正例，报对了）、FP（假正例，误报）、FN（假负例，漏报）、TN（真负例，正确放过）。

  • 精确率 Precision = TP/(TP+FP)：报的警里有多少是真警——怕"误报"的场景看它，比如推荐系统、垃圾邮件过滤（别把正常邮件判垃圾）；
  • 召回率 Recall = TP/(TP+FN)：所有坏人里抓到了多少——怕"漏报"的场景看它，比如癌症筛查、金融反欺诈，宁可错查不可漏过；
  • F1 = 2·P·R/(P+R)：精确率和召回率的调和平均，两者要平衡时用；
  • 准确率 Accuracy = (TP+TN)/总数：样本均衡时可用，样本不均衡会严重失真。

举个例子：1000 封邮件里 100 封垃圾邮件，模型判了 120 封垃圾、其中 90 封是真垃圾。那么 TP=90、FP=30、FN=10、TN=870，精确率 = 90/120 = 75%，召回率 = 90/100 = 90%，F1 ≈ 81.8%。

这对 RAG/Agent 场景同样有启发：检索环节"召回率"优先（先保证相关文档别漏，Rerank 再保证精确率）；而内容审核类 Agent 往往"精确率"优先（误杀正常内容代价高）。先想清楚你的业务怕误报还是怕漏报，再定优化方向。

另外两个传统 AI 的东西在今天依然有生命力：专家系统（IF-THEN 规则，可解释性强但不会学习，适合做 Agent 里的确定性校验规则）和知识图谱（主体-关系-客体三元组，GraphRAG 把图谱结构知识接进 RAG，做多跳推理比纯向量检索靠谱）。安全上还要警惕提示词注入（Prompt Injection）——用户输入里夹带"忽略之前规则"类恶意指令劫持模型，RAG 场景甚至可能通过投毒知识库内容实施，输入输出护栏和权限隔离不能少。

结尾：给技术团队落地 AI 的几条建议

带团队做了一年多 AI 落地，最后说几条掏心窝的判断：

  1. 先场景后技术。别问"我们要不要上大模型"，先找"知识密集、重复度高、容错率可接受"的环节——需求拆解、代码审查、知识库问答、客服，都是好起点；
  2. 能用 Prompt 解决的别上 RAG，能 RAG 解决的别碰微调。架构越重，维护成本越高，先用最轻的方案跑通价值闭环；
  3. RAG 的功夫在检索链路外：文档治理、切分策略、混合检索、Rerank、评测集——这些脏活累活决定 80% 的效果，模型只决定 20%；
  4. Agent 要从小处做起。单 Agent + 3~5 个高质量工具，先把 ReAct 循环跑稳、把失败可观测，再谈多 Agent 协作；
  5. 把 AI 当团队里一个"能力强但会犯错的 junior"：给它清晰的上下文、明确的边界、可检查的产出，关键决策人来兜底。人在回路不是过渡方案，是负责任的工程态度；
  6. 对团队来说，最大的红利不是"AI 替代人"，而是能力边界的重画——前端工程师能借 Agent 交付全栈功能，业务工程师能自己搭 RAG 应用。会用 AI 的研发取代不会用的，核心能力正在变成产品思维、架构判断力和人机协作能力。

大模型应用架构还在快速演进，但底层逻辑已经稳定：Transformer 提供了通用推理引擎，RAG 解决知识接入，Agent 解决行动闭环。把这三块的原理和取舍想明白，你就具备了判断任何一个 AI 需求"该怎么做、坑在哪、值不值"的能力——这大概是这个阶段技术负责人最重要的新基本功。

本文是我在团队 AI 转型过程中的架构笔记，欢迎交流指正。