LLM 基础概念
大语言模型(LLM)是基于 Transformer 架构的深度学习模型,通过在海量文本数据上进行自监督学习,掌握了语言的理解与生成能力。它能完成翻译、摘要、代码生成、推理等任务,本质是一个超大规模的概率模型 —— 给定前文,预测下一个最可能的 token。
LLM = 一个读过全网书籍的超级学霸,你提问它从记忆中生成最可能的答案。它不是在"搜索"答案,而是在"生成"看起来最合理的回答。就像一个博览群书的学者,你问他任何问题,他都能侃侃而谈 —— 但有时也会"一本正经地胡说八道"(幻觉问题)。
| 概念 | 解释 | 典型值 |
|---|---|---|
| Token | 模型处理的最小文本单位,约 0.75 个英文单词 / 0.5-1 个汉字 | GPT-4o: 128K tokens |
| Context Window | 模型一次能处理的最大 token 数,即"记忆长度" | GPT-4o: 128K, Claude: 200K |
| Temperature | 控制输出随机性。0=确定性输出,越高越随机/有创意 | 代码: 0, 创意写作: 0.7-1.0 |
| Top_p | 核采样参数,从概率累积前 p 的 token 中采样 | 通常 0.9-1.0 |
| System Prompt | 预设给模型的"角色"和"规则",定义其行为边界 | "你是一个专业的数据分析助手..." |
| 维度 | GPT-4o | Claude 3.5 Sonnet | DeepSeek V3 | Qwen 2.5 | 本地 (Ollama) |
|---|---|---|---|---|---|
| 价格 | $$$ 较贵 | $$ 中等 | $ 极低 | $ 低 | 免费(电费) |
| 上下文 | 128K | 200K | 128K | 128K | 8K-128K |
| 速度 | 快 | 快 | 极快 | 快 | 取决于硬件 |
| 中文能力 | 优秀 | 优秀 | 顶级 | 顶级 | 中等 |
| 代码能力 | 顶级 | 顶级 | 优秀 | 优秀 | 中等 |
| 多模态 | 图文音视频 | 图文 | 图文 | 图文 | 纯文本 |
| API 易用 | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★☆☆ |
| 可自部署 | ✗ | ✗ | ✓ 开源 | ✓ 开源 | ✓ 全部 |
Prompt Engineering
同一个模型,不同的 prompt 可以产生天差地别的结果。Prompt Engineering 是性价比最高的 LLM 优化手段 —— 不需要改模型、不需要加数据,只需要优化你的提问方式。
最简单的方式 —— 直接提出问题,不给任何示例。
请将以下设备故障描述转换为结构化 JSON:
"3号产线注塑机A温度异常报警,当前温度285°C,设定温度260°C"
提供 2-3 个输入/输出示例,让模型理解你想要的格式和风格。
将故障描述转为分类标签。
示例1:
输入:"电机异响伴随振动"
输出:{"category":"机械故障","severity":"中","component":"电机"}
示例2:
输入:"PLC通讯超时,HMI显示断连"
输出:{"category":"通讯故障","severity":"高","component":"PLC"}
现在处理:
输入:"液压系统压力不足,油温偏高"
输出:
在 prompt 中加入"请一步步思考"或给出带推理过程的示例,大幅提升复杂问题的准确性。
分析以下 OEE 数据下降的原因,请一步步思考:
1. 首先列出所有可能的影响因素
2. 逐一排除不可能的因素
3. 找到最可能的根因
4. 给出改进建议
今日 OEE 数据:
- 可用率: 88% (目标 95%)
- 性能率: 75% (目标 85%)
- 质量率: 98% (目标 99%)
- 换线时间: 45min (正常 20min)
- 小停机: 23次 (正常 <10次)
给模型设定一个专业角色,输出质量会显著提升。
你是一个在制造业工作了15年的资深MES系统架构师。
你精通 ISA-95 标准、OEE分析、SPC统计过程控制。
回答时请使用专业术语,必要时引用行业标准。
明确要求 JSON、Markdown 表格等结构化格式,便于程序后续处理。
请严格以以下 JSON 格式输出分析结果:
{
"root_cause": "根因描述",
"confidence": 0.0-1.0,
"evidence": ["证据1", "证据2"],
"recommendations": [
{"action": "建议动作", "priority": "高/中/低", "effort": "时间估计"}
]
}
你是一个有10年经验的设备维护工程师。以下是今早的设备停机日志:
[日志内容]
06:23 注塑机A-03 温度报警 (285°C / 260°C)
06:24 系统自动停机保护
06:45 维护人员到达现场
07:10 发现冷却水阀故障,更换后重启
07:30 恢复生产
请分析:
1. 根本原因是什么?
2. 为什么温度会从260°C升到285°C?
3. 如何防止此类故障再次发生?
4. 请用鱼骨图格式列出所有可能因素
输出格式:JSON
根据以下产线数据,生成今日 OEE 日报:
产线数据:
- 计划生产时间: 480 min
- 实际运行时间: 432 min(停机48min)
- 计划节拍: 60 件/min
- 实际产量: 24,192 件
- 理论产量(按实际运行时间): 25,920 件
- 不良品: 363 件
请计算:
1. 可用率 (Availability)
2. 性能率 (Performance)
3. 质量率 (Quality)
4. OEE = A × P × Q
5. 与昨日对比(昨日 OEE = 76.3%)
6. 改进建议
请以 Markdown 表格形式输出,并给出趋势分析。
将以下 SOP 操作规程转换为执行检查清单:
SOP-2024-038: 注塑机开机操作标准流程
(原文内容...)
要求:
1. 每个步骤必须有一个 ☐ 复选框
2. 关键安全步骤用 ⚠️ 标记
3. 标注预计耗时
4. 分为"开机前检查"、"开机操作"、"开机后确认"三个阶段
5. 输出为 Markdown 格式,便于打印
你是一个擅长时间序列分析的数据科学家。以下是过去两周的日产量数据:
日期 | 产量 | 备注
---------|--------|--------
6/1(周一) | 5,230 | 正常
6/2(周二) | 5,180 | 模具更换
6/3(周三) | 5,310 | 正常
6/4(周四) | 5,290 | 正常
6/5(周五) | 5,100 | 原料批次差异
6/6(周六) | 4,200 | 半班生产
6/7(周日) | 0 | 休息
...(更多数据)
请分析:
1. 产量趋势(上升/下降/平稳)
2. 周期性模式
3. 异常值识别
4. 下周产量预测(含置信区间)
5. 改进建议
请给出具体的数值预测,不要模糊表述。
你是一个数据库性能优化专家。请审查以下 SQL 查询:
```sql
SELECT p.product_name, COUNT(*) as total,
AVG(d.defect_rate) as avg_defect
FROM production p
JOIN defect_log d ON p.id = d.product_id
WHERE p.create_time > '2024-01-01'
GROUP BY p.product_name
HAVING COUNT(*) > 100
ORDER BY avg_defect DESC
```
请从以下角度审查:
1. 性能问题(索引使用、全表扫描风险)
2. 数据准确性(JOIN 方式、NULL 处理)
3. SQL 注入风险
4. 改写建议(给出优化后的 SQL)
请按严重程度排序:🔴 严重 🟡 警告 🟢 建议
RAG(检索增强生成)深入
LLM 的训练数据有截止日期,而且它不知道你的私有数据。RAG = 在 LLM 回答之前,先从你的知识库中检索相关内容,把检索结果作为上下文一起喂给 LLM。这样它就能基于你的真实数据来回答。
RAG = 开卷考试。LLM 是一个聪明的考生,但考试内容涉及你公司的内部资料。RAG 就是让它在答题前先翻阅你的"内部文档",然后基于文档内容作答。
Excel, 数据库
递归分割
OpenAI ada-002, BGE, M3E
Pinecone, pgvector
混合检索 + 重排序
→ 带引用的回答
| 策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 固定大小 | 按固定 token 数切分,可重叠 | 简单、稳定 | 可能截断语义 | 通用场景 |
| 语义分割 | 按语义相似度断句 | 语义完整性好 | 块大小不均 | 长文档问答 |
| 递归分割 | 按分隔符层级递归切分 | 保留文档结构 | 需要调参 | 结构化文档 |
| 文档级 | 每个文档/章节作为一个块 | 完整上下文 | 块太大 | 短文档集 |
| 模型 | 维度 | 最大长度 | 中文 | 价格 | 推荐场景 |
|---|---|---|---|---|---|
| text-embedding-3-large | 3072 | 8191 | 优秀 | $0.13/1M tokens | 高质量英文 |
| text-embedding-ada-002 | 1536 | 8191 | 良好 | $0.10/1M tokens | OpenAI 生态 |
| BGE-large-zh | 1024 | 512 | 顶级 | 免费开源 | 中文场景首选 |
| M3E-large | 1024 | 512 | 顶级 | 免费开源 | 中文混合场景 |
| 产品 | 类型 | 性能 | 易用性 | 规模 | 过滤 | 混合检索 | 部署 |
|---|---|---|---|---|---|---|---|
| Chroma | 轻量级 | ★★★☆ | ★★★★★ | 中小 | 基础 | 有限 | pip install |
| Milvus | 分布式 | ★★★★★ | ★★★★☆ | 亿级 | 丰富 | 支持 | Docker/K8s |
| Pinecone | 全托管 | ★★★★★ | ★★★★★ | 亿级 | 丰富 | 支持 | SaaS only |
| pgvector | PG 扩展 | ★★★★☆ | ★★★★☆ | 中 | SQL 全能力 | 支持 | PG 插件 |
| Weaviate | 全功能 | ★★★★☆ | ★★★★☆ | 大 | 丰富 | 支持 | Docker |
# ===== 制造业知识库 RAG 系统 =====
from langchain.document_loaders import (
PyPDFLoader, Docx2txtLoader, TextLoader
)
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate
# 1. 加载文档
documents = []
for pdf_path in ["docs/SOP-注塑机操作.pdf", "docs/设备维护手册.pdf"]:
loader = PyPDFLoader(pdf_path)
documents.extend(loader.load())
# 2. 分块 (递归分割,保留结构)
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", "。", ",", " "]
)
chunks = splitter.split_documents(documents)
print(f"共分割成 {len(chunks)} 个块")
# 3. 向量化 (使用 BGE 中文模型)
embeddings = HuggingFaceEmbeddings(
model_name="BAAI/bge-large-zh-v1.5"
)
# 4. 存入 Chroma 向量数据库
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embeddings,
persist_directory="./chroma_db"
)
vectorstore.persist()
# 5. 构建检索链
llm = ChatOpenAI(
model="gpt-4o",
temperature=0
)
# 自定义 Prompt 模板
prompt_template = """你是制造业设备维护专家。
请基于以下参考资料回答问题。如果资料中没有相关信息,请明确说明。
参考资料:
{context}
问题:{question}
请按以下格式回答:
1. 答案:[直接回答]
2. 依据:[引用来源]
3. 置信度:[高/中/低]
"""
prompt = PromptTemplate(
template=prompt_template,
input_variables=["context", "question"]
)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=vectorstore.as_retriever(
search_type="mmr",
search_kwargs={"k": 5}
),
return_source_documents=True,
chain_type_kwargs={"prompt": prompt}
)
# 6. 提问
result = qa_chain.invoke({
"query": "注塑机A-03温度报警的标准处理流程是什么?"
})
print(result["result"])
print("来源文档:", result["source_documents"])
背景:某工厂部署了设备故障知识库问答系统,初期准确率仅 60%。
- 第1轮优化(60% → 75%):改进分块策略 —— 从固定 1000 字符改为递归分割 500 字符,重叠 50,确保语义完整
- 第2轮优化(75% → 85%):改进检索 —— 从纯向量检索改为混合检索(向量 + BM25 关键词),并用 MMR 去重
- 第3轮优化(85% → 90%):改进 Prompt —— 添加角色设定 + 结构化输出要求 + 引用来源
- 第4轮优化(90% → 95%):添加重排序(Reranker)—— 先检索 top-20,再用 bge-reranker 重排取 top-5,大幅提升相关性
关键经验:不要一上来就换模型或微调。RAG 优化的 ROI 排序:分块策略 > 检索策略 > Prompt > Reranker > 换模型
Agent 开发
Agent = LLM + 工具调用 + 自主规划。普通 LLM 只能回答问题,而 Agent 能执行操作 —— 查数据库、调 API、画图表、发通知。它能根据目标自主规划步骤,调用合适的工具,观察结果,再决定下一步。
Agent = 一个有工具箱的智能助手。LLM 只能"动嘴",Agent 还能"动手"。你说"分析今天产量下降的原因",它会自己去查数据库、拉数据、做图表、写报告 —— 不需要你手动指定每一步。
"分析今天产量下降的原因"
理解意图 · 规划步骤
查询数据库
数据分析
生成图表
发送通知
"产量下降12%,主因是3号线换模时间超标..."
| 组件 | 作用 | 类比 |
|---|---|---|
| Chains | 将多个操作串联成流水线 | 工厂的装配线 |
| Tools | 定义 Agent 可调用的工具(函数) | 工人的工具箱 |
| Memory | 维护对话历史和状态 | 工人的笔记本 |
| Agents | 根据输入自主选择工具和步骤 | 有自主决策能力的工人 |
# ===== 制造业数据分析 Agent =====
from langchain.agents import initialize_agent, AgentType
from langchain.tools import Tool
from langchain.chat_models import ChatOpenAI
from langchain.memory import ConversationBufferMemory
import pandas as pd
# 定义工具
def query_production_db(sql: str) -> str:
"""查询生产数据库"""
import psycopg2
conn = psycopg2.connect("postgresql://...")
df = pd.read_sql(sql, conn)
return df.to_string()
def analyze_data(data_description: str) -> str:
"""用 LLM 分析数据"""
return llm.predict(f"分析以下生产数据并找出异常:\n{data_description}")
def generate_chart(chart_spec: str) -> str:
"""生成数据图表"""
import matplotlib.pyplot as plt
# 根据规格生成图表并保存
return "图表已生成: /charts/output.png"
def send_alert(message: str) -> str:
"""发送告警通知"""
# 调用企业微信/钉钉 API
return f"告警已发送: {message}"
tools = [
Tool(name="query_db", func=query_production_db,
description="查询生产数据库,输入SQL语句"),
Tool(name="analyze", func=analyze_data,
description="分析生产数据,输入数据描述"),
Tool(name="chart", func=generate_chart,
description="生成图表,输入图表配置"),
Tool(name="alert", func=send_alert,
description="发送告警,输入告警内容"),
]
# 初始化 Agent
llm = ChatOpenAI(model="gpt-4o", temperature=0)
memory = ConversationBufferMemory(memory_key="chat_history")
agent = initialize_agent(
tools=tools,
llm=llm,
agent=AgentType.STRUCTURED_CHAT_ZERO_SHOT_REACT,
memory=memory,
verbose=True,
max_iterations=5
)
# 用户提问 → Agent 自主执行
result = agent.run("分析今天产量下降的原因,如果下降超过10%就发告警")
# Agent 执行过程:
# 1. [Thought] 需要先查今天和昨天的产量数据
# 2. [Action] query_db("SELECT date, SUM(qty) FROM ...")
# 3. [Observation] 今天 4200, 昨天 5100, 下降 17.6%
# 4. [Action] analyze("今天4200 vs 昨天5100, 下降17.6%...")
# 5. [Observation] 主要原因: 3号线换模超时, 5号线设备故障
# 6. [Action] alert("⚠️ 今日产量下降17.6%...")
# 7. [Final Answer] 综合分析报告
背景:某工厂每天需要 3 名工程师花 2 小时手动收集各产线数据、编制巡检报表。
- 方案:部署数据分析 Agent,自动完成:定时查询 MES/SCADA 数据 → 异常检测 → 生成报表 → 推送到企业微信
- 工具链:SQL 查询工具 + Pandas 分析 + Matplotlib 画图 + 企业微信 API
- 效果:报表生成时间从 2 小时降到 3 分钟,异常发现速度提升 10 倍
- 成本:每天约 500 次 API 调用,月费用约 300 元(使用 DeepSeek API)
Fine-tuning(微调)
当 API + RAG + Prompt Engineering 都无法满足需求时,考虑微调。微调是在已有模型基础上用你的领域数据继续训练,让模型"学会"你的专业术语、输出格式和行为风格。
高质量对话数据
权衡效果与成本
数小时至数天
对比基线效果
持续监控
| 方式 | 原理 | 显存需求 | 效果 | 成本 | 适用 |
|---|---|---|---|---|---|
| Full Fine-tuning | 更新所有参数 | 极高 (80GB+) | 最好 | 最高 | 大厂、充足资源 |
| LoRA | 只训练低秩矩阵 | 中等 (24-48GB) | 好 | 中等 | 大多数场景 |
| QLoRA | 4bit量化 + LoRA | 低 (8-24GB) | 接近 LoRA | 低 | 消费级 GPU |
检索增强生成
内部文档/数据
微调模型行为
输出风格和术语
优化提示词
成本最低见效最快
| 工具 | 特点 | 适合 |
|---|---|---|
| OpenAI Fine-tuning API | 上传数据即可,无需 GPU | GPT-3.5/4o 微调,快速验证 |
| LlamaFactory | 开源,Web UI,支持 50+ 模型 | 开源模型微调,低门槛 |
| Unsloth | 2x 更快,省 80% 显存 | QLoRA 微调,消费级 GPU |
背景:通用 LLM 不了解工厂的设备编号规则、工艺参数标准、质量判定术语,导致回答经常"外行"。
- 数据准备:收集了 2000 条工程师标注的问答对,涵盖设备故障描述、工艺参数解读、质量判定等
- 微调方式:使用 QLoRA 在 Llama-3-8B 上微调,仅用一张 RTX 4090 (24GB)
- 效果:专业术语准确率从 45% 提升到 92%,回答符合工艺规范的比例从 30% 提升到 88%
- 成本:训练时间 4 小时,电费约 10 元;推理使用本地部署,无持续 API 费用
本地部署(私有化)
- 数据隐私:生产数据、工艺参数等敏感信息不能外传到第三方 API
- 离线运行:工厂网络环境可能受限,无法稳定访问外网 API
- 成本控制:高频率调用场景下,本地部署比 API 更划算
- 响应速度:消除网络延迟,推理响应更快
# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 一行命令运行模型
ollama run qwen2.5:7b # 通义千问 7B (中文优秀)
ollama run deepseek-r1:7b # DeepSeek R1 7B (推理强)
ollama run llama3.1:8b # Llama 3.1 8B (综合好)
# 通过 API 调用(兼容 OpenAI 格式)
curl http://localhost:11434/v1/chat/completions \
-d '{
"model": "qwen2.5:7b",
"messages": [{"role": "user", "content": "你好"}]
}'
# Python 调用
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
response = client.chat.completions.create(
model="qwen2.5:7b",
messages=[{"role": "user", "content": "分析这段日志"}]
)
# 安装
pip install vllm
# 启动推理服务器 (兼容 OpenAI API)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--served-model-name qwen2.5 \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 1
# vLLM 优势:PagedAttention, 连续批处理
# 吞吐量可达 Ollama 的 3-5 倍
背景:某汽车零部件工厂需要 AI 辅助质量分析,但产品参数、缺陷数据属于核心机密,不能通过 API 发送到外部。
- 方案:使用 Ollama + Qwen2.5-14B 部署在内网服务器(RTX 4090 24GB)
- 架构:FastAPI 后端 → Ollama 推理 → pgvector 向量检索 → 企业微信推送
- 效果:延迟 <3s,完全离线运行,数据不出内网
- 成本:一次性硬件投入约 2 万,后续无 API 费用
AI 项目完整架构
| 指标 | 说明 | 告警阈值 |
|---|---|---|
| Token 用量 | 每次请求消耗的 token 数,直接影响成本 | 单次 > 10K tokens |
| 响应延迟 | 从请求到首字响应时间 (TTFT) + 总时间 | TTFT > 5s |
| 回答准确率 | 定期抽样人工评估 RAG 回答质量 | < 85% |
| 错误率 | API 调用失败、超时、token 超限的比例 | > 1% |
| 并发数 | 同时进行的 AI 请求量 | > 配额 80% |
初始方案:所有请求走 GPT-4o API,简单/复杂问题都用最强模型。
- 优化 1 —— 路由策略:简单问题(FAQ 类)用 DeepSeek V3,复杂推理用 GPT-4o。成本降至 1800 元/月
- 优化 2 —— 缓存层:相似问题命中缓存直接返回(Redis + 语义相似度),减少 30% 调用。成本降至 1200 元/月
- 优化 3 —— 本地兜底:FAQ 场景完全走本地 Ollama + Qwen2.5-7B,零 API 成本。最终成本 800 元/月
关键经验:不是所有请求都需要最强模型。路由 + 缓存 + 本地,三者组合是成本优化的黄金法则。
面试高频 15 题
工作原理:LLM 基于 Transformer 架构,通过自注意力机制(Self-Attention)处理输入文本,逐 token 预测下一个最可能的输出。训练目标是最大化 P(next_token | previous_tokens)。
幻觉原因:
- LLM 是概率模型,生成的是"最可能"的文本,而非"最正确"的文本
- 训练数据可能包含错误信息,模型也会学到这些错误
- 模型没有真正的"知识验证"能力,无法区分自己知道和不知道的内容
缓解方案:RAG 提供事实依据、降低 temperature、要求标注置信度、添加事实核查链。
Token 是 LLM 处理文本的最小单位,介于字符和单词之间。常用的 BPE(Byte Pair Encoding)算法根据频率将常见字符合并成 token。
为什么用 Token:
- 纯字符级 → 序列太长,计算量爆炸
- 纯单词级 → 词表太大(尤其中文),OOV 问题严重
- Token 是在效率和覆盖率之间的最优平衡点
实际影响:1 个中文字 ≈ 1-2 tokens,1 个英文单词 ≈ 1-1.5 tokens。直接关系到 API 计费和上下文窗口占用。
RAG(Retrieval-Augmented Generation)流程:
- 离线索引阶段:文档加载 → 文本分块 → Embedding 向量化 → 存入向量数据库
- 在线查询阶段:用户提问 → 问题向量化 → 相似度检索 top-K → 拼接上下文 → LLM 生成回答
关键优化点:
- 分块策略(chunk size、overlap、语义分割)
- Embedding 模型选择(中文场景推荐 BGE/M3E)
- 检索策略(向量检索 + BM25 混合、MMR 去重)
- Reranker 重排序提升精度
- Prompt 模板优化(角色设定 + 引用要求)
评估 RAG 需要分两个维度:
- 检索质量:召回率(Recall)、精确率(Precision)、MRR、nDCG —— 衡量是否能找到相关文档
- 生成质量:忠实度(Faithfulness,回答是否基于检索内容)、答案相关性、上下文利用率
实用方法:
- 构建评估数据集:50-100 个标准问答对
- 使用 RAGAS 框架自动评估
- 定期人工抽检 + 用户反馈收集
- A/B 测试对比不同配置的效果
核心技巧:Zero-shot、Few-shot、Chain-of-Thought、Role-playing、Structured Output(详见第 2 节)。
生产中 Prompt 管理最佳实践:
- 将 Prompt 从代码中分离,存为独立模板文件(YAML/JSON)
- 使用 Prompt 版本管理,支持 A/B 测试和回滚
- 建立 Prompt 评估数据集,修改后自动回归测试
- 变量化设计:用 {{variable}} 占位,动态填充
- 添加 few-shot 示例库,按场景动态选择
普通 LLM 调用:输入 Prompt → 输出文本。只能"说",不能"做"。
AI Agent:LLM + 工具调用 + 自主规划。能根据目标自主决定调用哪些工具、按什么顺序执行、如何组合结果。
Agent 核心循环(ReAct 模式):
- Reasoning:分析当前状态,决定下一步
- Acting:调用工具执行操作
- Observation:观察工具返回结果
- 循环直到得出最终答案
典型工具:数据库查询、API 调用、代码执行、文件操作、Web 搜索。
决策优先级(由低到高):Prompt → RAG → Fine-tuning
- Prompt Engineering:先试这个!成本最低,见效最快。适合调整输出格式、风格、推理方式
- RAG:模型需要知道你的私有数据(文档、知识库)。适合知识问答、文档检索、内部知识库
- Fine-tuning:需要模型"内化"特定行为模式。适合专业术语、固定输出格式、特定领域推理风格
常见误区:不要因为回答不好就立刻微调。90% 的问题可以通过优化 Prompt + RAG 解决。
LoRA(Low-Rank Adaptation):冻结原始模型参数,只训练注入的低秩矩阵(A×B),参数量仅为原模型的 0.1%-1%。
QLoRA:在 LoRA 基础上,先将模型量化到 4-bit,再进行 LoRA 训练。进一步降低显存需求。
受欢迎的原因:
- 显存需求降低 70-90%(70B 模型从 320GB → 48GB)
- 训练速度快 2-3 倍
- 效果接近全量微调(差距 < 2%)
- 可插拔:一个基座模型 + 多个 LoRA 权重 = 多个场景
- 消费级 GPU(RTX 4090 24GB)也能微调 14B 模型
成本控制策略:
- 模型路由:简单问题用便宜模型(DeepSeek/GPT-4o-mini),复杂问题用强模型(GPT-4o)
- 语义缓存:相似问题命中缓存直接返回,减少 30%+ 调用
- Prompt 精简:减少不必要的上下文,压缩 system prompt
- 本地兜底:FAQ 等高频简单场景走本地 Ollama
- Token 监控:设置每用户/每日配额,异常调用告警
- 批量处理:非实时场景用 Batch API(价格低 50%)
选型维度:数据规模、查询延迟、是否需要标量过滤、运维复杂度、是否需要混合检索。
- 开发/原型:Chroma(pip install 即用,零配置)
- 已有 PG 的项目:pgvector(复用 PostgreSQL 生态,SQL 全能力)
- 大规模生产:Milvus(分布式、亿级、GPU 加速)
- 不想运维:Pinecone(全托管 SaaS,开箱即用)
实际建议:先用 Chroma 原型验证,确认效果后根据规模迁移到 pgvector(中等)或 Milvus(大规模)。
Ollama:面向开发者和个人使用,一行命令运行模型,内置模型管理。适合开发测试、低并发场景。
vLLM:面向生产环境的高性能推理引擎,支持 PagedAttention、连续批处理、分布式推理。吞吐量是 Ollama 的 3-5 倍。
选择建议:
- 开发/测试/低并发(<10 QPS):Ollama,简单易用
- 生产环境/高并发(>10 QPS):vLLM,性能优先
- 两者都兼容 OpenAI API 格式,切换成本低
主要安全风险和应对:
- Prompt 注入:用户输入恶意指令试图覆盖 system prompt。→ 输入/输出分离、Prompt 沙箱、输入过滤
- 数据泄露:模型输出中包含训练数据中的敏感信息。→ 输出过滤、PII 检测
- 越权操作:Agent 工具调用权限过大。→ 最小权限原则、操作审批、审计日志
- 供应链攻击:恶意模型权重、被污染的 RAG 文档。→ 模型来源验证、文档审核
Context Window 是模型一次能处理的最大 token 数(包括输入+输出)。例如 GPT-4o 是 128K tokens。
超出时的处理策略:
- RAG:只检索相关片段,而非塞入全部文档
- 摘要压缩:先用 LLM 压缩长文本,再输入给主模型
- 滑动窗口:分段处理,再合并结果
- MapReduce:并行处理各段,再汇总(LangChain 内置)
- 选大窗口模型:Claude 200K、Gemini 1M tokens
流式输出让用户逐字看到 LLM 的回复,大幅改善体感延迟。
- 后端:使用 OpenAI SDK 的 stream=True,通过 SSE(Server-Sent Events)推送到前端
- 前端:使用 EventSource 或 fetch + ReadableStream 接收,逐字渲染 Markdown
- FastAPI 示例:使用 StreamingResponse + async generator
注意事项:流式模式下 token 计数需要自行累积;错误处理需要在流中传递;前端需要处理 Markdown 的部分渲染。
架构设计:
- 前端:Vue 3 + Chat UI 组件,支持流式输出、Markdown 渲染、文件上传
- 后端:FastAPI,SSE 流式接口,Redis 缓存 + 对话历史
- AI 服务:LangChain 编排,RAG pipeline(文档加载→分块→向量化→检索→生成)
- 模型:路由策略 —— FAQ 用本地 Qwen2.5-7B,复杂问题用 DeepSeek API
- 存储:pgvector 向量检索 + PostgreSQL 业务数据 + MinIO 文档存储
- 监控:Prometheus + Grafana 监控 token 用量、延迟、准确率
关键设计决策:
- 文档更新后自动重新索引(增量更新)
- 多轮对话记忆(滑动窗口保留最近 10 轮)
- 答案引用来源(每条回答标注参考文档和段落)
- 权限隔离(不同部门只能检索自己的知识库)