Large Language Model，基于 Transformer 架构的预训练语言模型，能够理解、生成和处理自然语言。
Transformer 是当今所有主流 LLM 的基础架构，核心组件：
输入文本 → Tokenizer → Embedding →
[Encoder × N] → [Decoder × N] →
Linear + Softmax → 输出概率分布
关键创新：
架构演进路线：
| 架构类型 | 代表模型 | 特点 | 适用场景 |
|---|---|---|---|
| Encoder-only | BERT, RoBERTa | 双向注意力，擅长理解 | 文本分类、NER、语义相似度 |
| Decoder-only | GPT 系列, LLaMA | 自回归生成，从左到右 | 文本生成、对话、代码 |
| Encoder-Decoder | T5, BART | 编码器+解码器完整结构 | 翻译、摘要、改写 |
当前主流 LLM（GPT-4, Claude, Kimi, DeepSeek 等）均采用 Decoder-only 架构，原因：
Token 是 LLM 处理文本的最小单位：
| 语言 | Token 估算 |
|---|---|
| 英文 | 1 word ≈ 1.3 tokens |
| 中文 | 1 汉字 ≈ 1–2 tokens |
| 代码 | 因语言而异，符号通常独立成 token |
为什么重要：
Token 化算法对比：
| 算法 | 特点 | 代表 |
|---|---|---|
| BPE | 字节对编码，合并高频子词 | GPT-2, GPT-3 |
| WordPiece | 基于概率的贪心合并 | BERT |
| SentencePiece | 语言无关，直接处理 Unicode | LLaMA, T5 |
| TikToken | OpenAI 优化的高效 BPE | GPT-4 |
Hugo 的踩坑记录：
在处理中文长文档时，Kimi 的 200K 上下文实际能容纳约 10-15 万字中文内容。但需要注意，如果文档包含大量代码块和特殊符号，token 消耗会显著增加。建议在处理长文档前先用 tokenizer 估算实际 token 数，避免超出上下文导致截断。
预训练（Pre-training）：
在大规模无标注文本上通过自监督学习训练模型参数：
微调（Fine-tuning）：
在预训练基础上，用特定领域数据调整模型：
Hugo 的项目经验：
在内部知识库问答项目中，我们尝试过全参数微调和 LoRA 两种方式。对于 7B 参数的模型，全参数微调需要 8×A100 80GB，而 QLoRA 只需单卡 24GB 即可达到 95% 的效果。最终生产环境采用 QLoRA + 合并权重的方式，既保证了效果又降低了部署成本。
Prompt 是给模型的输入指令。有效的 prompt 设计原则：
基本结构：
[角色定义] + [上下文] + [任务指令] + [输出格式] + [示例]
常用技巧：
进阶技巧：
| 技巧 | 说明 | 适用场景 |
|---|---|---|
| ReAct | Reasoning + Acting，让模型交替思考和执行工具 | 复杂任务分解 |
| Self-Consistency | 多次采样取多数投票 | 推理任务提高准确性 |
| Tree of Thoughts | 维护多个思维路径，评估后选择最优 | 探索性问题 |
| Automatic Prompt Engineering | 用 LLM 自动优化 prompt | 批量 prompt 调优 |
Hugo 的内部约定：
团队内部建立了 prompt 模板库，按任务类型分类管理。所有生产环境的 prompt 必须经过 A/B 测试，用结构化评估指标（准确率、幻觉率、格式合规率）量化效果。不要凭感觉调 prompt，要数据驱动。
| 维度 | GPT-5 | Claude 4 | Gemini 2.5 | Kimi k2.6 | GLM-5 | DeepSeek-V4 |
|---|---|---|---|---|---|---|
| 上下文长度 | 128K | 200K | 1M | 200K | 128K | 128K |
| 多模态 | ✅ 文本/图像 | ✅ 文本/图像 | ✅ 原生多模态 | ✅ 文本/图像 | ✅ 文本/图像 | ✅ 文本 |
| 中文能力 | 良好 | 良好 | 良好 | 优秀 | 优秀 | 优秀 |
| 代码能力 | 强 | 强 | 强 | 强 | 强 | 极强 |
| 推理能力 | 强 | 极强 | 强 | 强 | 强 | 极强 |
| 开源 | ❌ | ❌ | ❌ | ❌ | 部分开源 | 开源 |
| API 定价 | 较高 | 较高 | 中等 | 中等 | 低 | 极低 |
| 模型 | 参数规模 | 特点 | 许可 |
|---|---|---|---|
| LLaMA 3 | 8B/70B/405B | Meta 开源，生态最完善 | 商业友好 |
| Qwen 2.5 | 0.5B-72B | 阿里开源，中文优化 | Apache 2.0 |
| DeepSeek-V3 | 671B (MoE) | 推理极强，成本极低 | MIT |
| Mistral | 7B/8×7B/8×22B | 欧洲开源，性能优异 | Apache 2.0 |
| Yi | 6B/34B | 零一万物，中文场景优化 | 商业友好 |
| ChatGLM | 6B/9B | 清华开源，中文对话 | 学术/商业 |
Hugo 的选型经验：
内部部署选型时，我们评估了多个开源模型。最终选择 DeepSeek-V3 作为主力推理模型（成本低、推理强），Kimi 作为长文档处理模型（200K 上下文），Qwen 作为轻量级任务模型（72B 版本在 A100 上单卡可跑）。关键是根据任务类型分配不同模型，而不是用一个模型做所有事。
通用能力基准测试：
实际应用评估：
基准测试分数不等于实际效果。建议建立内部评估集，包含真实业务场景的数据，定期测试模型表现。
大多数 LLM 提供商采用 OpenAI 兼容的 API 格式：
import openai
client = openai.OpenAI(
base_url="https://api.provider.com/v1",
api_key="your-api-key"
)
response = client.chat.completions.create(
model="model-name",
messages=[
{"role": "system", "content": "你是一个技术专家。"},
{"role": "user", "content": "解释什么是 LLM？"}
],
temperature=0.7,
max_tokens=2000
)
print(response.choices[0].message.content)
国内主要 API 提供商：
| 提供商 | 基础 URL | 特点 |
|---|---|---|
| 阿里云百炼 | https://dashscope.aliyuncs.com/compatible-mode/v1 |
Qwen 系列，国内稳定 |
| 智谱 AI | https://open.bigmodel.cn/api/paas/v4 |
GLM 系列，价格适中 |
| 月之暗面 | https://api.moonshot.cn/v1 |
Kimi 系列，长上下文 |
| DeepSeek | https://api.deepseek.com |
推理强，价格极低 |
| 硅基流动 | https://api.siliconflow.cn/v1 |
聚合多模型 |
| OpenRouter | https://openrouter.ai/api/v1 |
国际聚合，模型全 |
| 参数 | 说明 | 常用值 |
|---|---|---|
temperature |
创造性程度，越低越保守 | 0.1–0.7 |
max_tokens |
最大输出 token 数 | 根据任务调整 |
top_p |
核采样概率阈值 | 0.9–1.0 |
frequency_penalty |
惩罚重复内容 | 0–1 |
presence_penalty |
惩罚已出现主题 | 0–1 |
参数调优策略：
| 场景 | Temperature | Top_p | 说明 |
|---|---|---|---|
| 事实问答 | 0.1-0.3 | 0.9 | 低创造性，高确定性 |
| 代码生成 | 0.2-0.4 | 0.95 | 结构化输出，适度灵活 |
| 创意写作 | 0.7-1.0 | 1.0 | 高创造性 |
| 数据分析 | 0.1-0.2 | 0.9 | 精确性优先 |
| 对话/客服 | 0.5-0.7 | 0.9 | 自然与准确平衡 |
# 流式输出示例
response = client.chat.completions.create(
model="gpt-4",
messages=messages,
stream=True # 启用流式
)
for chunk in response:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="")
流式输出的工程价值：
Function Calling 让 LLM 可以调用外部工具：
response = client.chat.completions.create(
model="gpt-4",
messages=messages,
tools=[
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名称"}
},
"required": ["city"]
}
}
}
],
tool_choice="auto"
)
Hugo 的项目案例：
在内部运维助手项目中，我们实现了 20+ 个工具函数（查询日志、重启服务、查看监控、执行 SQL 等）。通过 Function Calling，运维人员可以用自然语言完成复杂操作，如"查看过去一小时订单服务的错误日志并按错误类型汇总"。关键是工具描述要清晰，参数定义要精确，否则模型会频繁选错工具。
| 场景 | 说明 | 关键技术 | 典型 ROI |
|---|---|---|---|
| 智能客服 | 自动回答用户问题 | RAG + Prompt Engineering | 人力成本降低 60-80% |
| 代码辅助 | 代码补全、重构、Debug | Code-specific fine-tuning | 开发效率提升 30-50% |
| 内容生成 | 文章、营销文案、报告 | Temperature 调参 | 内容产出速度提升 5-10x |
| 数据分析 | 从非结构化数据中提取洞察 | Function Calling + 数据解析 | 分析周期缩短 70% |
| 知识问答 | 基于企业知识库回答问题 | RAG + Embedding | 信息检索效率提升 10x |
| 翻译/摘要 | 多语言处理和长文本压缩 | 长上下文窗口 | 翻译成本降低 90% |
RAG 是解决 LLM 知识时效性和幻觉问题的核心技术：
用户提问 → 向量化查询 → 向量数据库检索 →
召回相关文档 → 构建增强 Prompt → LLM 生成回答
RAG 架构演进：
| 阶段 | 名称 | 特点 |
|---|---|---|
| RAG 1.0 | Naive RAG | 简单向量检索 + 直接生成 |
| RAG 2.0 | Advanced RAG | 查询重写、重排序、多路召回 |
| RAG 3.0 | Modular RAG | 模块化设计，路由+自适应 |
| Agentic RAG | 智能体 RAG | LLM 主动决策检索策略 |
关键组件：
Hugo 的踩坑记录：
第一个版本的 RAG 系统直接用了简单的向量相似度检索，结果召回率只有 40%。后来引入了三路召回（向量检索 + 关键词检索 + 结构化查询）+ Cross-encoder 重排序，召回率提升到 85%。另一个坑是 chunk 大小，太大容易包含无关信息，太小会丢失上下文。最终采用 512 token 的 chunk + 128 token 的重叠窗口，效果最佳。
Agent 是让 LLM 具备自主决策和执行能力的架构：
核心组件：
主流 Agent 框架：
| 框架 | 特点 | 适用场景 |
|---|---|---|
| LangChain | 生态最完善，组件丰富 | 快速原型、复杂流程 |
| LlamaIndex | 数据检索和 RAG 专长 | 知识库问答、文档处理 |
| AutoGPT | 自主决策，目标驱动 | 研究、探索性任务 |
| MetaGPT | 多智能体协作，SOP 驱动 | 软件开发、团队协作 |
| Dify | 可视化编排，低代码 | 快速搭建生产应用 |
| Coze/扣子 | 国内生态，插件丰富 | 国内用户、社交场景 |
max_tokens，避免无限生成成本优化策略矩阵：
| 策略 | 实施方式 | 预期节省 |
|---|---|---|
| 模型路由 | 简单任务用小模型，复杂任务用大模型 | 50-70% |
| 响应缓存 | Redis 缓存相同查询结果 | 20-40% |
| Prompt 压缩 | 压缩历史对话，精简上下文 | 15-30% |
| 批量处理 | 非实时任务用 Batch API | 50% |
| 本地部署 | 高频任务用开源模型本地部署 | 80-95% |
Hugo 的内部约定：
生产环境必须实现模型路由层。我们定义了三级模型策略：L1（轻量模型，处理分类/格式化，<100ms），L2（标准模型，处理一般问答，<1s），L3（重型模型，处理复杂推理，<5s）。通过意图识别自动路由，整体 API 成本降低了 65%。
推理加速技术对比：
| 技术 | 加速比 | 适用场景 | 复杂度 |
|---|---|---|---|
| vLLM | 2-4x | 通用服务化部署 | 低 |
| TensorRT-LLM | 3-6x | NVIDIA GPU 生产环境 | 中 |
| Text Generation Inference | 2-3x | HuggingFace 生态 | 低 |
| ONNX Runtime | 1.5-2x | 跨平台部署 | 低 |
| 量化（INT8/INT4） | 2-4x | 资源受限环境 | 中 |
安全防护体系：
输入层 → 处理层 → 输出层
↓ ↓ ↓
输入过滤 沙箱执行 内容审查
敏感检测 权限控制 事实核查
Prompt 工具权限 人工复核
清洗 限制 机制
Hugo 的项目经验：
在金融场景使用 LLM 时，我们建立了三层防护：第一层是输入过滤，检测并拒绝包含敏感指令的 prompt；第二层是输出事实核查，对涉及数字、日期、条款的内容进行规则校验；第三层是人工复核机制，高风险操作必须人工确认。上线半年，拦截了 12 起 prompt injection 尝试，0 起安全事故。
生产环境 LLM 应用必须建立完善的可观测体系：
| 指标类型 | 具体指标 | 监控工具 |
|---|---|---|
| 性能 | 延迟（P50/P95/P99）、吞吐量 | Prometheus + Grafana |
| 成本 | Token 消耗、API 调用次数 | 自定义指标 |
| 质量 | 幻觉率、准确率、用户满意度 | 评估流水线 |
| 安全 | 注入尝试次数、敏感词触发 | 安全审计日志 |
| 业务 | 任务完成率、用户留存 | 业务埋点 |
Hugo 的监控实践：
我们在每次 LLM 调用时记录完整上下文：输入 token 数、输出 token 数、模型版本、延迟、是否命中缓存、用户反馈（👍/👎）。这些数据进入 ClickHouse，通过 Grafana 实时看板监控。每周进行质量复盘，根据幻觉率和准确率调整 prompt 和模型选择。
从纯文本扩展到图像、音频、视频的统一理解：
| 模型 | 能力 | 特点 |
|---|---|---|
| GPT-4o | 文本+图像+音频 | 原生多模态，端到端 |
| Gemini 1.5 Pro | 文本+图像+视频 | 1M 上下文，视频理解 |
| Claude 3.5 Sonnet | 文本+图像 | 视觉推理强 |
| Qwen-VL | 文本+图像 | 开源，中文优化 |
Test-Time Scaling：通过增加推理时的计算量提升效果：
DeepSeek-R1 的启示：
DeepSeek-R1 通过纯强化学习（RL）而非监督微调（SFT）获得强大推理能力，证明：
将大模型部署到手机、PC、边缘设备：
| 技术 | 效果 | 代表 |
|---|---|---|
| 模型压缩 | 4-bit 量化，体积减少 75% | llama.cpp, ollama |
| 知识蒸馏 | 小模型达到大模型 90% 效果 | Phi, Gemma |
| 硬件加速 | NPU/GPU 专用推理 | Apple Neural Engine, Qualcomm |
| 投机采样 | 草稿模型加速生成 | Medusa, Lookahead |
上下文窗口从 4K 扩展到 1M+：
| 模型 | 上下文长度 | 技术特点 |
|---|---|---|
| Gemini 1.5 Pro | 1M tokens | 线性注意力近似 |
| Kimi k2.6 | 200K tokens | 无损长上下文 |
| Claude 3 | 200K tokens | 注意力优化 |
| GLM-4 | 128K tokens | 位置外推 |
长上下文的应用价值：
是否需要中文优化？
├─ 是 → 优先考虑 Kimi / Qwen / DeepSeek
└─ 否 → 继续
是否需要开源/本地部署？
├─ 是 → LLaMA 3 / DeepSeek / Qwen
└─ 否 → 继续
预算是否敏感？
├─ 是 → DeepSeek / GLM / 开源本地部署
└─ 否 → GPT-4 / Claude
是否需要超长上下文？
├─ 是 → Gemini 1.5 Pro / Kimi
└─ 否 → 继续
是否需要最强推理？
├─ 是 → Claude / DeepSeek-R1
└─ 否 → 根据其他因素综合选择
| 部署模式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 第三方 API | 即用即付，无需运维 | 数据外发，成本不可控 | 快速验证、低频任务 |
| 私有云部署 | 数据安全，可控 | 需要 GPU 资源 | 中高频、敏感数据 |
| 混合模式 | 灵活路由，成本优化 | 架构复杂 | 大规模生产环境 |
| 端侧部署 | 零延迟，隐私最佳 | 模型能力受限 | 实时交互、移动场景 |
最后更新：2026-05-02