LLM应用开发核心架构:从Prompt到RAG到Agent Level 1: 基础Prompt 用户提问 → LLM → 回答 简单但容易"幻觉" ⚠️ 无法获取实时信息 Level 2: 提示工程 System Prompt + Few-shot 角色设定 + 示例引导 提升回答质量但仍有幻觉 Level 3: RAG检索增强 检索知识库 → 注入Prompt = 开卷考试 ✅ 大幅减少幻觉 Level 4: 函数调用 LLM决定调用哪个函数 查天气/查库存/下订单 LLM = 决策中枢 Level 5: Agent智能体 自主规划 + 多步执行 ReAct循环:思考→行动 →观察→调整→输出 Level 6: 多Agent协作 PM Agent + Dev Agent + QA Agent + Reviewer = 虚拟团队 RAG工作流(最常用架构) 1.用户提问 2.Embedding 3.向量检索 (Top-K相关) 4.拼接Prompt (问题+知识) 5.LLM生成 (开卷考试) 6.返回答案
LLM应用开发的6个层级 + RAG工作流详解:从简单Prompt到多Agent协作,难度递增
📘 面试备战 · 大模型专题

大模型 LLM 应用开发

从基础概念到生产实践,覆盖 Prompt Engineering、RAG、Agent、微调、本地部署等核心技术,助你拿下 LLM 相关岗位 Offer

GPT-4o Claude 3.5 DeepSeek LangChain RAG Agent Fine-tuning Ollama
1

LLM 基础概念

什么是 Large Language Model

大语言模型(LLM)是基于 Transformer 架构的深度学习模型,通过在海量文本数据上进行自监督学习,掌握了语言的理解与生成能力。它能完成翻译、摘要、代码生成、推理等任务,本质是一个超大规模的概率模型 —— 给定前文,预测下一个最可能的 token。

💡 类比理解

LLM = 一个读过全网书籍的超级学霸,你提问它从记忆中生成最可能的答案。它不是在"搜索"答案,而是在"生成"看起来最合理的回答。就像一个博览群书的学者,你问他任何问题,他都能侃侃而谈 —— 但有时也会"一本正经地胡说八道"(幻觉问题)。

📈 LLM 进化时间线
2018
GPT-1
1.17亿参数
证明预训练+微调范式
2019
GPT-2
15亿参数
Zero-shot 能力涌现
2020
GPT-3
1750亿参数
Few-shot 惊艳世界
2022
ChatGPT
RLHF 对齐
全球引爆 AI 热潮
2023
GPT-4
多模态
多模态+强推理
2023-24
Claude
长上下文
200K 上下文窗口
2023-24
Llama
开源标杆
Meta 开源推动社区
2024-25
DeepSeek
国产之光
开源 MoE 高性能
核心概念速查
概念解释典型值
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 易用 ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ ★★★☆☆
可自部署 ✓ 开源 ✓ 开源 ✓ 全部
2

Prompt Engineering

为什么 Prompt 如此重要

同一个模型,不同的 prompt 可以产生天差地别的结果。Prompt Engineering 是性价比最高的 LLM 优化手段 —— 不需要改模型、不需要加数据,只需要优化你的提问方式。

📊 Prompt 效果对比
糟糕 Prompt
"帮我看看"
~20%
基础 Prompt
"分析这段日志的问题"
~45%
优化 Prompt
角色+背景+格式要求
~75%
专家 Prompt
角色+Few-shot+CoT+结构化
~95%
五大核心技巧
Zero-shot 直接问

最简单的方式 —— 直接提出问题,不给任何示例。

Prompt
请将以下设备故障描述转换为结构化 JSON:
"3号产线注塑机A温度异常报警,当前温度285°C,设定温度260°C"
Few-shot 给几个例子

提供 2-3 个输入/输出示例,让模型理解你想要的格式和风格。

Prompt
将故障描述转为分类标签。

示例1:
输入:"电机异响伴随振动"
输出:{"category":"机械故障","severity":"中","component":"电机"}

示例2:
输入:"PLC通讯超时,HMI显示断连"
输出:{"category":"通讯故障","severity":"高","component":"PLC"}

现在处理:
输入:"液压系统压力不足,油温偏高"
输出:
Chain-of-Thought 让它一步步想

在 prompt 中加入"请一步步思考"或给出带推理过程的示例,大幅提升复杂问题的准确性。

Prompt
分析以下 OEE 数据下降的原因,请一步步思考:

1. 首先列出所有可能的影响因素
2. 逐一排除不可能的因素
3. 找到最可能的根因
4. 给出改进建议

今日 OEE 数据:
- 可用率: 88% (目标 95%)
- 性能率: 75% (目标 85%)  
- 质量率: 98% (目标 99%)
- 换线时间: 45min (正常 20min)
- 小停机: 23次 (正常 <10次)
Role-playing 角色扮演

给模型设定一个专业角色,输出质量会显著提升。

System Prompt
你是一个在制造业工作了15年的资深MES系统架构师。
你精通 ISA-95 标准、OEE分析、SPC统计过程控制。
回答时请使用专业术语,必要时引用行业标准。
Structured Output 结构化输出

明确要求 JSON、Markdown 表格等结构化格式,便于程序后续处理。

Prompt
请严格以以下 JSON 格式输出分析结果:
{
  "root_cause": "根因描述",
  "confidence": 0.0-1.0,
  "evidence": ["证据1", "证据2"],
  "recommendations": [
    {"action": "建议动作", "priority": "高/中/低", "effort": "时间估计"}
  ]
}
五大实战 Prompt
Prompt 1 分析停机日志根因
你是一个有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
Prompt 2 生成 OEE 日报
根据以下产线数据,生成今日 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 表格形式输出,并给出趋势分析。
Prompt 3 SOP 转检查清单
将以下 SOP 操作规程转换为执行检查清单:

SOP-2024-038: 注塑机开机操作标准流程
(原文内容...)

要求:
1. 每个步骤必须有一个 ☐ 复选框
2. 关键安全步骤用 ⚠️ 标记
3. 标注预计耗时
4. 分为"开机前检查"、"开机操作"、"开机后确认"三个阶段
5. 输出为 Markdown 格式,便于打印
Prompt 4 预测产量趋势
你是一个擅长时间序列分析的数据科学家。以下是过去两周的日产量数据:

日期     | 产量   | 备注
---------|--------|--------
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. 改进建议

请给出具体的数值预测,不要模糊表述。
Prompt 5 SQL 代码审查
你是一个数据库性能优化专家。请审查以下 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)

请按严重程度排序:🔴 严重 🟡 警告 🟢 建议
3

RAG(检索增强生成)深入

为什么需要 RAG

LLM 的训练数据有截止日期,而且它不知道你的私有数据。RAG = 在 LLM 回答之前,先从你的知识库中检索相关内容,把检索结果作为上下文一起喂给 LLM。这样它就能基于你的真实数据来回答。

💡 类比理解

RAG = 开卷考试。LLM 是一个聪明的考生,但考试内容涉及你公司的内部资料。RAG 就是让它在答题前先翻阅你的"内部文档",然后基于文档内容作答。

🏗️ RAG 详细架构(6 步流程)
1
📄
文档加载
PDF, Word, HTML, Markdown
Excel, 数据库
2
✂️
分块 Chunking
固定大小 / 语义分割
递归分割
3
🔢
向量化 Embedding
文本 → 高维向量
OpenAI ada-002, BGE, M3E
4
💾
向量存储
Chroma, Milvus
Pinecone, pgvector
5
🔍
检索 Retrieval
相似度搜索
混合检索 + 重排序
6
🤖
生成 Generation
上下文 + 问题 → LLM
→ 带引用的回答
分块策略对比
策略原理优点缺点适用场景
固定大小 按固定 token 数切分,可重叠 简单、稳定 可能截断语义 通用场景
语义分割 按语义相似度断句 语义完整性好 块大小不均 长文档问答
递归分割 按分隔符层级递归切分 保留文档结构 需要调参 结构化文档
文档级 每个文档/章节作为一个块 完整上下文 块太大 短文档集
Embedding 模型对比
模型维度最大长度中文价格推荐场景
text-embedding-3-large30728191优秀$0.13/1M tokens高质量英文
text-embedding-ada-00215368191良好$0.10/1M tokensOpenAI 生态
BGE-large-zh1024512顶级免费开源中文场景首选
M3E-large1024512顶级免费开源中文混合场景
向量数据库对比
产品类型性能易用性规模过滤混合检索部署
Chroma轻量级★★★☆★★★★★中小基础有限pip install
Milvus分布式★★★★★★★★★☆亿级丰富支持Docker/K8s
Pinecone全托管★★★★★★★★★★亿级丰富支持SaaS only
pgvectorPG 扩展★★★★☆★★★★☆SQL 全能力支持PG 插件
Weaviate全功能★★★★☆★★★★☆丰富支持Docker
完整代码示例
Python LangChain + Chroma 制造业知识库
# ===== 制造业知识库 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"])
生产案例
🏭 生产案例:RAG 准确率从 60% 提升到 95%

背景:某工厂部署了设备故障知识库问答系统,初期准确率仅 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 > 换模型

4

Agent 开发

什么是 AI Agent

Agent = LLM + 工具调用 + 自主规划。普通 LLM 只能回答问题,而 Agent 能执行操作 —— 查数据库、调 API、画图表、发通知。它能根据目标自主规划步骤,调用合适的工具,观察结果,再决定下一步。

💡 类比理解

Agent = 一个有工具箱的智能助手。LLM 只能"动嘴",Agent 还能"动手"。你说"分析今天产量下降的原因",它会自己去查数据库、拉数据、做图表、写报告 —— 不需要你手动指定每一步。

🤖 Agent 架构流程
👤 用户
"分析今天产量下降的原因"
🧠 Agent (LLM + ReAct)
理解意图 · 规划步骤
▼ 规划任务
🗄️ Tool 1
查询数据库
📊 Tool 2
数据分析
📈 Tool 3
生成图表
📧 Tool 4
发送通知
▼ 观察结果 + 循环
✅ 最终响应
"产量下降12%,主因是3号线换模时间超标..."
LangChain 核心组件
组件作用类比
Chains将多个操作串联成流水线工厂的装配线
Tools定义 Agent 可调用的工具(函数)工人的工具箱
Memory维护对话历史和状态工人的笔记本
Agents根据输入自主选择工具和步骤有自主决策能力的工人
完整代码示例
Python 制造业数据分析 Agent
# ===== 制造业数据分析 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] 综合分析报告
生产案例
🏭 生产案例:用 Agent 替代人工巡检报表

背景:某工厂每天需要 3 名工程师花 2 小时手动收集各产线数据、编制巡检报表。

  • 方案:部署数据分析 Agent,自动完成:定时查询 MES/SCADA 数据 → 异常检测 → 生成报表 → 推送到企业微信
  • 工具链:SQL 查询工具 + Pandas 分析 + Matplotlib 画图 + 企业微信 API
  • 效果:报表生成时间从 2 小时降到 3 分钟,异常发现速度提升 10 倍
  • 成本:每天约 500 次 API 调用,月费用约 300 元(使用 DeepSeek API)
5

Fine-tuning(微调)

什么时候需要微调

当 API + RAG + Prompt Engineering 都无法满足需求时,考虑微调。微调是在已有模型基础上用你的领域数据继续训练,让模型"学会"你的专业术语、输出格式和行为风格。

🔧 微调流程
📋
准备数据
100-10K 条
高质量对话数据
⚙️
选择方法
Full / LoRA / QLoRA
权衡效果与成本
🏋️
训练
GPU 训练
数小时至数天
评估
验证集测试
对比基线效果
🚀
部署
部署到生产
持续监控
微调方式对比
方式原理显存需求效果成本适用
Full Fine-tuning 更新所有参数 极高 (80GB+) 最好 最高 大厂、充足资源
LoRA 只训练低秩矩阵 中等 (24-48GB) 中等 大多数场景
QLoRA 4bit量化 + LoRA 低 (8-24GB) 接近 LoRA 消费级 GPU
决策流程图:RAG vs 微调 vs Prompt
🎯 你的需求是什么?
需要查询私有知识/事实?
✅ RAG
检索增强生成
模型需要知道你的
内部文档/数据
需要特定风格/格式/术语?
✅ Fine-tuning
微调模型行为
需要一致的专业
输出风格和术语
只是提示效果不好?
✅ Prompt Engineering
优化提示词
先试这个!
成本最低见效最快
💡 实际项目中,三者常组合使用:Prompt 基础优化 + RAG 补充知识 + 微调定制风格
常用微调工具
工具特点适合
OpenAI Fine-tuning API上传数据即可,无需 GPUGPT-3.5/4o 微调,快速验证
LlamaFactory开源,Web UI,支持 50+ 模型开源模型微调,低门槛
Unsloth2x 更快,省 80% 显存QLoRA 微调,消费级 GPU
生产案例
🏭 生产案例:微调后 LLM 准确使用工厂专业术语

背景:通用 LLM 不了解工厂的设备编号规则、工艺参数标准、质量判定术语,导致回答经常"外行"。

  • 数据准备:收集了 2000 条工程师标注的问答对,涵盖设备故障描述、工艺参数解读、质量判定等
  • 微调方式:使用 QLoRA 在 Llama-3-8B 上微调,仅用一张 RTX 4090 (24GB)
  • 效果:专业术语准确率从 45% 提升到 92%,回答符合工艺规范的比例从 30% 提升到 88%
  • 成本:训练时间 4 小时,电费约 10 元;推理使用本地部署,无持续 API 费用
6

本地部署(私有化)

为什么要本地部署
  • 数据隐私:生产数据、工艺参数等敏感信息不能外传到第三方 API
  • 离线运行:工厂网络环境可能受限,无法稳定访问外网 API
  • 成本控制:高频率调用场景下,本地部署比 API 更划算
  • 响应速度:消除网络延迟,推理响应更快
Ollama:一行命令运行本地 LLM
Bash Ollama 快速上手
# 安装 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": "分析这段日志"}]
)
vLLM:高性能推理服务器
Bash vLLM 部署
# 安装
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 倍
🖥️ 本地部署架构
🖥️ 应用服务
FastAPI / Node.js
🔗 API Gateway
OpenAI 兼容接口
🧠 推理引擎
Ollama / vLLM
🎮 GPU
NVIDIA CUDA
💾 向量库
Chroma / Milvus
🗄️ 数据库
PostgreSQL + pgvector
📊 监控
Prometheus + Grafana
GPU 显存需求参考
7B 模型
8 GB VRAM
Qwen2.5-7B, Llama3-8B
14B 模型
16 GB VRAM
Qwen2.5-14B, DeepSeek-14B
32B 模型
24 GB VRAM
Qwen2.5-32B, Mixtral-8x7B
70B+ 模型
80+ GB VRAM
Llama3-70B, Qwen2.5-72B
* 量化后显存需求可降低 50-75%(INT4 量化)
生产案例
🏭 生产案例:数据不能外传所以必须本地部署

背景:某汽车零部件工厂需要 AI 辅助质量分析,但产品参数、缺陷数据属于核心机密,不能通过 API 发送到外部。

  • 方案:使用 Ollama + Qwen2.5-14B 部署在内网服务器(RTX 4090 24GB)
  • 架构:FastAPI 后端 → Ollama 推理 → pgvector 向量检索 → 企业微信推送
  • 效果:延迟 <3s,完全离线运行,数据不出内网
  • 成本:一次性硬件投入约 2 万,后续无 API 费用
7

AI 项目完整架构

🌐 全栈 AI 应用架构
前端层
Vue 3 / React
用户界面
Chat UI 组件
对话交互
Streaming SSE
流式输出
Markdown 渲染
富文本展示
后端层
FastAPI / Node.js
API 服务
Auth 鉴权
用户管理
Rate Limiting
调用限流
Async Queue
异步任务
AI 服务层
LangChain / LlamaIndex
编排框架
RAG Pipeline
检索增强
Agent Tools
工具调用
Prompt 管理
模板版本
模型层
OpenAI API
GPT-4o
DeepSeek API
性价比之选
Ollama 本地
隐私场景
vLLM 高性能
生产推理
存储层
Chroma / Milvus
向量数据库
MySQL / PostgreSQL
业务数据
Redis
缓存 + 对话历史
MinIO / OSS
文档存储
成本估算
💰 月成本对比
GPT-4o API
3000 元/月
DeepSeek API
800 元/月
混合方案
500 元/月
纯本地
电费 ~200 元/月
关键监控指标
指标说明告警阈值
Token 用量每次请求消耗的 token 数,直接影响成本单次 > 10K tokens
响应延迟从请求到首字响应时间 (TTFT) + 总时间TTFT > 5s
回答准确率定期抽样人工评估 RAG 回答质量< 85%
错误率API 调用失败、超时、token 超限的比例> 1%
并发数同时进行的 AI 请求量> 配额 80%
生产案例
🏭 生产案例:每天 1000 次 AI 调用,月成本从 3000 元优化到 800 元

初始方案:所有请求走 GPT-4o API,简单/复杂问题都用最强模型。

  • 优化 1 —— 路由策略:简单问题(FAQ 类)用 DeepSeek V3,复杂推理用 GPT-4o。成本降至 1800 元/月
  • 优化 2 —— 缓存层:相似问题命中缓存直接返回(Redis + 语义相似度),减少 30% 调用。成本降至 1200 元/月
  • 优化 3 —— 本地兜底:FAQ 场景完全走本地 Ollama + Qwen2.5-7B,零 API 成本。最终成本 800 元/月

关键经验:不是所有请求都需要最强模型。路由 + 缓存 + 本地,三者组合是成本优化的黄金法则。

8

面试高频 15 题

1 请解释 LLM 的工作原理,以及它为什么会"幻觉"(hallucination)?

工作原理:LLM 基于 Transformer 架构,通过自注意力机制(Self-Attention)处理输入文本,逐 token 预测下一个最可能的输出。训练目标是最大化 P(next_token | previous_tokens)。

幻觉原因:

  • LLM 是概率模型,生成的是"最可能"的文本,而非"最正确"的文本
  • 训练数据可能包含错误信息,模型也会学到这些错误
  • 模型没有真正的"知识验证"能力,无法区分自己知道和不知道的内容

缓解方案:RAG 提供事实依据、降低 temperature、要求标注置信度、添加事实核查链。

2 什么是 Token?为什么 LLM 用 Token 而不是字符或单词?

Token 是 LLM 处理文本的最小单位,介于字符和单词之间。常用的 BPE(Byte Pair Encoding)算法根据频率将常见字符合并成 token。

为什么用 Token:

  • 纯字符级 → 序列太长,计算量爆炸
  • 纯单词级 → 词表太大(尤其中文),OOV 问题严重
  • Token 是在效率和覆盖率之间的最优平衡点

实际影响:1 个中文字 ≈ 1-2 tokens,1 个英文单词 ≈ 1-1.5 tokens。直接关系到 API 计费和上下文窗口占用。

3 请详细解释 RAG 的架构和工作流程。

RAG(Retrieval-Augmented Generation)流程:

  • 离线索引阶段:文档加载 → 文本分块 → Embedding 向量化 → 存入向量数据库
  • 在线查询阶段:用户提问 → 问题向量化 → 相似度检索 top-K → 拼接上下文 → LLM 生成回答

关键优化点:

  • 分块策略(chunk size、overlap、语义分割)
  • Embedding 模型选择(中文场景推荐 BGE/M3E)
  • 检索策略(向量检索 + BM25 混合、MMR 去重)
  • Reranker 重排序提升精度
  • Prompt 模板优化(角色设定 + 引用要求)
4 如何评估 RAG 系统的效果?有哪些关键指标?

评估 RAG 需要分两个维度:

  • 检索质量:召回率(Recall)、精确率(Precision)、MRR、nDCG —— 衡量是否能找到相关文档
  • 生成质量:忠实度(Faithfulness,回答是否基于检索内容)、答案相关性、上下文利用率

实用方法:

  • 构建评估数据集:50-100 个标准问答对
  • 使用 RAGAS 框架自动评估
  • 定期人工抽检 + 用户反馈收集
  • A/B 测试对比不同配置的效果
5 Prompt Engineering 有哪些核心技巧?在生产中如何管理 Prompt?

核心技巧:Zero-shot、Few-shot、Chain-of-Thought、Role-playing、Structured Output(详见第 2 节)。

生产中 Prompt 管理最佳实践:

  • 将 Prompt 从代码中分离,存为独立模板文件(YAML/JSON)
  • 使用 Prompt 版本管理,支持 A/B 测试和回滚
  • 建立 Prompt 评估数据集,修改后自动回归测试
  • 变量化设计:用 {{variable}} 占位,动态填充
  • 添加 few-shot 示例库,按场景动态选择
6 什么是 AI Agent?和普通 LLM 调用有什么区别?

普通 LLM 调用:输入 Prompt → 输出文本。只能"说",不能"做"。

AI Agent:LLM + 工具调用 + 自主规划。能根据目标自主决定调用哪些工具、按什么顺序执行、如何组合结果。

Agent 核心循环(ReAct 模式):

  • Reasoning:分析当前状态,决定下一步
  • Acting:调用工具执行操作
  • Observation:观察工具返回结果
  • 循环直到得出最终答案

典型工具:数据库查询、API 调用、代码执行、文件操作、Web 搜索。

7 什么时候用 RAG,什么时候用 Fine-tuning,什么时候用 Prompt Engineering?

决策优先级(由低到高):Prompt → RAG → Fine-tuning

  • Prompt Engineering:先试这个!成本最低,见效最快。适合调整输出格式、风格、推理方式
  • RAG:模型需要知道你的私有数据(文档、知识库)。适合知识问答、文档检索、内部知识库
  • Fine-tuning:需要模型"内化"特定行为模式。适合专业术语、固定输出格式、特定领域推理风格

常见误区:不要因为回答不好就立刻微调。90% 的问题可以通过优化 Prompt + RAG 解决。

8 LoRA 和 QLoRA 有什么区别?为什么它们比全量微调更受欢迎?

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 模型
9 如何在生产环境中控制 LLM 调用成本?

成本控制策略:

  • 模型路由:简单问题用便宜模型(DeepSeek/GPT-4o-mini),复杂问题用强模型(GPT-4o)
  • 语义缓存:相似问题命中缓存直接返回,减少 30%+ 调用
  • Prompt 精简:减少不必要的上下文,压缩 system prompt
  • 本地兜底:FAQ 等高频简单场景走本地 Ollama
  • Token 监控:设置每用户/每日配额,异常调用告警
  • 批量处理:非实时场景用 Batch API(价格低 50%)
10 向量数据库的选型标准是什么?生产环境推荐哪个?

选型维度:数据规模、查询延迟、是否需要标量过滤、运维复杂度、是否需要混合检索。

  • 开发/原型:Chroma(pip install 即用,零配置)
  • 已有 PG 的项目:pgvector(复用 PostgreSQL 生态,SQL 全能力)
  • 大规模生产:Milvus(分布式、亿级、GPU 加速)
  • 不想运维:Pinecone(全托管 SaaS,开箱即用)

实际建议:先用 Chroma 原型验证,确认效果后根据规模迁移到 pgvector(中等)或 Milvus(大规模)。

11 Ollama 和 vLLM 有什么区别?分别适合什么场景?

Ollama:面向开发者和个人使用,一行命令运行模型,内置模型管理。适合开发测试、低并发场景。

vLLM:面向生产环境的高性能推理引擎,支持 PagedAttention、连续批处理、分布式推理。吞吐量是 Ollama 的 3-5 倍。

选择建议:

  • 开发/测试/低并发(<10 QPS):Ollama,简单易用
  • 生产环境/高并发(>10 QPS):vLLM,性能优先
  • 两者都兼容 OpenAI API 格式,切换成本低
12 如何处理 LLM 应用的安全性问题?

主要安全风险和应对:

  • Prompt 注入:用户输入恶意指令试图覆盖 system prompt。→ 输入/输出分离、Prompt 沙箱、输入过滤
  • 数据泄露:模型输出中包含训练数据中的敏感信息。→ 输出过滤、PII 检测
  • 越权操作:Agent 工具调用权限过大。→ 最小权限原则、操作审批、审计日志
  • 供应链攻击:恶意模型权重、被污染的 RAG 文档。→ 模型来源验证、文档审核
13 LLM 的 Context Window 是什么?超出上下文窗口怎么办?

Context Window 是模型一次能处理的最大 token 数(包括输入+输出)。例如 GPT-4o 是 128K tokens。

超出时的处理策略:

  • RAG:只检索相关片段,而非塞入全部文档
  • 摘要压缩:先用 LLM 压缩长文本,再输入给主模型
  • 滑动窗口:分段处理,再合并结果
  • MapReduce:并行处理各段,再汇总(LangChain 内置)
  • 选大窗口模型:Claude 200K、Gemini 1M tokens
14 在生产中如何实现 LLM 的流式输出(Streaming)?

流式输出让用户逐字看到 LLM 的回复,大幅改善体感延迟。

  • 后端:使用 OpenAI SDK 的 stream=True,通过 SSE(Server-Sent Events)推送到前端
  • 前端:使用 EventSource 或 fetch + ReadableStream 接收,逐字渲染 Markdown
  • FastAPI 示例:使用 StreamingResponse + async generator

注意事项:流式模式下 token 计数需要自行累积;错误处理需要在流中传递;前端需要处理 Markdown 的部分渲染。

15 如果你要设计一个企业级 AI 知识库系统,请描述你的技术方案。

架构设计:

  • 前端: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 轮)
  • 答案引用来源(每条回答标注参考文档和段落)
  • 权限隔离(不同部门只能检索自己的知识库)

常见问题 FAQ

大模型"幻觉"问题能完全消除吗?

不能完全消除,但可以大幅降低。方法:① RAG:让模型基于检索到的真实文档回答(减少事实性幻觉);② System Prompt约束:"如果不确定,回答'我不知道',不要编造信息";③ 输出校验:用规则引擎或第二个模型验证输出的事实性;④ 置信度阈值:模型logprobs低于阈值时触发人工审核。

RAG的向量检索和传统搜索(如ES)有什么区别?

传统搜索(ES/Lucene)基于关键词匹配 + TF-IDF/BM25打分,只能找包含相同词的文档。向量检索先把文本变成向量(Embedding),再算向量距离(余弦相似度),能找到语义相近但用词不同的文档。比如搜"退货"能匹配到"退款政策"。实践中常混合使用:先ES粗筛→再向量精排。

LLM应用的Token成本怎么控制?

四个技巧:① 缓存:相同或相似的Query缓存结果(Redis),避免重复调用;② 模型分级:简单任务用小模型(GPT-3.5/4o-mini),复杂任务才用大模型(GPT-4);③ Prompt精简:去掉冗余的System Prompt,只保留关键指令;④ RAG召回控制:Top-K不要设太大(K=3~5足够),减少注入的上下文长度。

Function Calling 和 Agent 有什么区别?

Function Calling单轮决策:LLM根据用户输入选择调用一个函数(如查天气API),拿到结果直接回答。Agent多轮自主决策:LLM像实习生一样,自己规划步骤、调用多个工具、观察中间结果、根据反馈调整计划。Agent = Function Calling + 规划 + 循环推理(ReAct)。

LLM应用开发三原则

1️⃣ 能RAG就不裸调:事实性问题一定要加知识库检索 → 2️⃣ Prompt是"工作说明书":角色、约束、输出格式、边界case都要写清 → 3️⃣ 始终预留人工审核通道:模型不确定的结果路由到人工,别让AI"自作主张"