作者:陈大鱼头github:github.com/KRISACHAN邮箱:chenjinwen77@gmail.com
今天看了一篇关于 AI 的文章,里面提到 但是按照大家卷的程度来看,在未来的不久不管你是前端还是后端,大模型底层原理将会是和源码一样成为面试中的热门话题。。
我觉得挺有道理的,所以就给自己也整理了一篇文章来给自己做参考跟知识巩固吧。
其实在 3 个月前,我也基于 LibreChat 整理过一篇 AI驱动的前端革命:10项颠覆性技术如何在LibreChat中融为一体,不过那毕竟是以实体落地技术为切入点整理的,没太涉及底层原理,因此就重新梳理了一份出来。
写在前头的免责声明:我不是专家,只是互联网的缝合怪,如果大家发现文章哪里有不正确的地方,希望能直接指出来,万分感谢!🙏
大模型底层原理概述
Transformer架构的核心机制
现代大型语言模型主要基于 Transformer 架构,其核心在于 自注意力机制(Self-Attention) 。
graph TD A[输入文本] --> B[Token化] B --> C[词嵌入 + 位置编码] C --> D[多头注意力层] D --> E[前馈神经网络] E --> F[层归一化] F --> G[输出层] G --> H[生成下一个Token] H --> I{是否结束?} I -->|否| D I -->|是| J[完整响应]
关键技术点:
- Token化:将文本切分为更小的语义单元,通常1个token约等于0.75个英文单词或1.5个中文字符词嵌入:将token转换为高维向量(通常768-4096维),捕获语义信息位置编码:为每个token添加位置信息,使模型理解序列顺序注意力机制:通过Query、Key、Value矩阵计算,让模型关注到最相关的上下文信息
自回归生成过程
大模型采用自回归方式生成文本,即基于前面的所有 token 预测下一个 token:
sequenceDiagram participant U as 用户输入 participant M as 大模型 participant C as 上下文缓存 U->>M: 输入prompt M->>C: 缓存KV向量 loop 逐token生成 M->>M: 基于上下文预测下一个token M->>C: 更新KV缓存 M->>U: 输出token end
性能优化技术:
- KV缓存:存储键值向量避免重复计算,显著提升推理速度预填充与解码分离:并行处理输入,顺序生成输出
端到端调用流程架构
整体系统架构
graph TB subgraph "前端层" A[用户界面] --> B[HTTP请求] B --> C[SSE流式接收] end subgraph "后端服务层" D[API网关] --> E[请求预处理] E --> F[上下文增强] F --> G[模型调用] G --> H[响应后处理] H --> I[SSE流式推送] end subgraph "AI服务层" J[大模型API] --> K[Token生成] K --> L[流式输出] end subgraph "扩展服务" M[RAG检索] --> F N[Function Calling] --> F O[MCP工具] --> F end B --> D I --> C G --> J L --> H
详细调用时序
sequenceDiagram participant F as 前端 participant B as 后端API participant R as RAG服务 participant T as 工具服务 participant L as 大模型 F->>B: 发送用户请求 B->>B: 请求预处理与验证 alt 需要RAG检索 B->>R: 语义检索相关文档 R-->>B: 返回相关上下文 end B->>B: 构建完整Prompt B->>L: 调用大模型API(stream=true) loop 流式响应 L-->>B: 返回生成token B-->>F: SSE推送token F->>F: 实时渲染 alt 需要工具调用 L-->>B: 返回Function Call B->>T: 执行工具调用 T-->>B: 返回执行结果 B->>L: 继续生成 end end L-->>B: 生成完成 B-->>F: 结束SSE连接
核心技术详解
RAG(检索增强生成)
RAG 通过外部知识库检索增强模型的回答能力,解决知识截止日期和幻觉问题。
RAG 工作流程:
graph LR subgraph "数据准备" A[原始文档] --> B[文档分块] B --> C[向量化] C --> D[向量数据库] end subgraph "检索过程" E[用户查询] --> F[查询向量化] F --> G[相似度搜索] D --> G G --> H[相关文档片段] end subgraph "生成过程" H --> I[构建增强Prompt] I --> J[大模型生成] J --> K[最终回答] end
关键技术点:
- 文档分块:将长文档切分为适合的片段(通常512-1024 tokens)向量化:使用嵌入模型将文本转换为数值向量相似度搜索:通过余弦相似度等算法找到最相关的文档上下文融合:将检索结果与用户查询整合为完整的prompt
Function Calling(函数调用)
Function Calling 让大模型能够调用外部工具和 API,扩展其能力边界。
工作机制:
flowchart TD A[用户请求] --> B{分析是否需要工具} B -->|是| C[识别所需工具] B -->|否| D[直接回答] C --> E[提取参数] E --> F[生成工具调用] F --> G[执行工具] G --> H[处理返回结果] H --> I[生成最终回答]
工具调用示例:
// 工具定义const weatherTool = { name: "get_weather", description: "获取指定城市的天气信息", parameters: { type: "object", properties: { city: { type: "string", description: "城市名称" } }, required: ["city"] }};// 调用流程const response = await llm.invoke({ messages: [...], tools: [weatherTool], tool_choice: "auto"});if (response.tool_calls) { const result = await executeFunction(response.tool_calls[0]); const finalResponse = await llm.invoke({ messages: [..., result] });}
MCP(模型上下文协议)
MCP 是一个开放标准,用于标准化 AI 模型与外部工具和数据源的交互。
MCP 架构:
graph TD subgraph "MCP客户端" A[LLM应用] --> B[MCP客户端] end subgraph "MCP服务端" C[MCP服务器] --> D[工具1:文件系统] C --> E[工具2:数据库] C --> F[工具3:API服务] C --> G[工具4:Web搜索] end B <--> C
MCP 核心组件:
- Resources:提供上下文信息的数据源Tools:可执行的功能函数Prompts:预定义的提示模板Sampling:让服务器请求LLM生成内容
MCP vs 传统API集成:
对比维度 | 传统API | MCP |
---|---|---|
集成复杂度 | 每个API需要单独集成 | 统一协议,一次集成 |
工具发现 | 静态配置 | 动态发现 |
错误处理 | 各自实现 | 标准化处理 |
扩展性 | 线性增长复杂度 | 统一管理 |
关键性能指标
推理性能指标
graph LR A[用户发送请求] --> B[TTFT<br/>首Token时间] B --> C[ITL<br/>Token间延迟] C --> D[总响应时间] subgraph "性能影响因素" E[模型大小] F[上下文长度] G[并发量] H[硬件配置] end
关键指标说明:
- TTFT(Time to First Token):从请求到第一个token生成的时间,影响用户感知的响应速度ITL(Inter-Token Latency):相邻token之间的生成间隔,影响流式输出的流畅度吞吐量:单位时间内处理的token数量并发能力:同时处理的请求数量
成本控制策略
graph TD A[成本优化] --> B[Token使用优化] A --> C[模型选择策略] A --> D[缓存机制] A --> E[批处理优化] B --> B1[精简Prompt] B --> B2[动态截断] B --> B3[智能分块] C --> C1[简单任务用小模型] C --> C2[复杂任务用大模型] C --> C3[多模型组合] D --> D1[语义缓存] D --> D2[结果缓存] D --> D3[上下文缓存]
流式输出实现
SSE(Server-Sent Events)实现
// 后端实现app.post('/chat/stream', async (req, res) => { res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive', 'Access-Control-Allow-Origin': '*' }); try { const stream = await openai.chat.completions.create({ model: 'gpt-4', messages: req.body.messages, stream: true }); for await (const chunk of stream) { const content = chunk.choices[0]?.delta?.content; if (content) { res.write(`data: ${JSON.stringify({ content })}\n\n`); } } } catch (error) { res.write(`data: ${JSON.stringify({ error: error.message })}\n\n`); } finally { res.write('data: [DONE]\n\n'); res.end(); }});// 前端接收const eventSource = new EventSource('/chat/stream');eventSource.onmessage = (event) => { const data = JSON.parse(event.data); if (data.content) { updateUI(data.content); }};
WebSocket 替代方案
// WebSocket实现双向通信const ws = new WebSocket('ws://localhost:8080/chat');ws.onopen = () => { ws.send(JSON.stringify({ type: 'chat', message: '你好,请介绍一下AI技术' }));};ws.onmessage = (event) => { const data = JSON.parse(event.data); switch(data.type) { case 'token': appendToken(data.content); break; case 'function_call': displayFunctionCall(data.function); break; case 'complete': markComplete(); break; }};
错误处理与监控
错误处理策略
graph TD A[API调用] --> B{请求成功?} B -->|否| C[错误类型判断] C --> D[速率限制 429] C --> E[服务器错误 5xx] C --> F[客户端错误 4xx] D --> G[指数退避重试] E --> H[切换备用服务] F --> I[用户友好提示] G --> J[重试成功?] J -->|否| K[降级服务] J -->|是| L[正常响应] B -->|是| L
监控指标
graph LR subgraph "业务指标" A[成功率] B[响应时间] C[用户满意度] end subgraph "技术指标" D[API延迟] E[错误率] F[Token消耗] end subgraph "资源指标" G[CPU使用率] H[内存占用] I[网络带宽] end
安全与合规
安全控制措施
graph TD A[安全框架] --> B[输入验证] A --> C[输出过滤] A --> D[访问控制] A --> E[数据隐私] B --> B1[Prompt注入防护] B --> B2[恶意输入检测] B --> B3[内容安全审查] C --> C1[敏感信息过滤] C --> C2[有害内容检测] C --> C3[版权内容识别] D --> D1[身份认证] D --> D2[权限管理] D --> D3[API密钥管理] E --> E1[数据加密] E --> E2[日志脱敏] E --> E3[合规审计]
最佳实践总结
架构设计原则
- 模块化设计:将RAG、Function Calling、MCP等功能模块化,便于维护和扩展异步处理:使用异步架构处理长时间运行的任务缓存策略:合理使用缓存减少重复计算和API调用监控告警:建立完善的监控体系,及时发现和处理问题
性能优化建议
- Prompt工程:精心设计prompt减少token消耗模型选择:根据任务复杂度选择合适的模型批处理:将多个请求打包处理提高效率连接池:维护API连接池避免频繁建连
成本控制措施
- 智能路由:根据问题复杂度路由到不同规模的模型结果缓存:缓存常见问题的回答用量监控:实时监控API使用量和成本预算控制:设置使用上限防止成本失控
未来发展趋势
技术演进方向
graph LR A[当前状态] --> B[短期发展] B --> C[中期展望] C --> D[长期愿景] A --> A1[基础RAG] A --> A2[简单Function Calling] B --> B1[多模态RAG] B --> B2[Agent工作流] C --> C1[自主学习系统] C --> C2[跨模态推理] D --> D1[通用人工智能] D --> D2[认知计算]
标准化进程
- 协议统一:MCP等开放协议将推动行业标准化工具生态:围绕标准协议构建丰富的工具生态互操作性:不同厂商的AI服务将更容易集成
结语
AI大模型调用技术正在快速演进,从简单的文本生成到复杂的多模态交互,从孤立的模型调用到完整的智能代理系统。理解和掌握 RAG、Function Calling、MCP等核心技术,对于构建下一代 AI 应用至关重要。
当然,在我看来,这些概念对普通人来说,就跟隔壁村三婶家的牛生了三只小鸡一样,只是茶余饭后吹牛的谈资,因为在日常的活动中,我们使用的差不多都是顶层的应用了,不会太涉及底层(虽然这也没有多底的)。