
"AI 应用定制化"这个词,正在经历一次内涵升级。几年前它可能意味着"用开源模型微调一个自己的版本",但今天,它更多指为特定业务场景设计一整套 AI 能力组合——包括模型选择、数据处理、工具集成、交互界面和部署方式。
当你打开一个通用 AI 助手时,它面对的是"全世界所有问题"。而当你用 AI 解决具体业务问题时(比如"客服工单分类"或"合同风险审查"),你会发现通用模型要么答非所问,要么回答太泛、缺乏业务深度。这就是定制化的价值所在。
下面从技术路径、代码示例和实施路线三个维度,梳理 AI 应用定制化的核心方法。
层次 | 适用场景 | 成本 | 效果 |
|---|---|---|---|
Prompt 工程 | 快速验证、原型搭建 | 极低 | 轻度定制 |
RAG(检索增强生成) | 知识库问答、文档检索 | 中低 | 中度定制 |
模型微调(Fine-tuning) | 特定风格/术语/格式输出 | 中高 | 深度定制 |
预训练(Pre-training) | 垂直领域大模型(如医疗、法律) | 极高 | 完全定制 |
四层的关系不是互斥,而是叠加:一个成熟的生产系统往往是 Prompt 工程 + RAG + 微调的组合使用。
Prompt 工程是定制化成本最低的入口。关键在于 "角色设定 + 输出格式约束 + 输入输出示例" 三件套。
# 一个定制化的 Prompt 模板(客服工单分类场景)
SYSTEM_PROMPT = """
你是一个客服工单分类专家。你的任务是将用户提交的工单文本分类到以下类别之一:
- 售后问题:涉及退换货、维修、质保
- 使用咨询:涉及产品功能、操作方法
- 投诉建议:涉及服务态度、流程改进
- 其他:不在上述三类中的问题
输出格式(严格遵守):
{"category": "类别名称", "confidence": 0.0-1.0, "summary": "一句话摘要"}
输入示例:
"我的手机充电口坏了,还在保修期内,怎么申请维修?"
输出示例:
{"category": "售后问题", "confidence": 0.92, "summary": "手机充电口故障,保修期内申请维修"}
以下是用户输入:
"""
def classify_ticket(user_input: str) -> dict:
response = llm.chat(SYSTEM_PROMPT + user_input)
return json.loads(response)这一段代码虽然简单,但已经完成了业务语义对齐(定义了四类分类)、输出格式化(要求 JSON)、置信度输出(便于下游做人工审核阈值)三个定制化核心任务。
当 Prompt 工程无法满足需求时(如需要理解企业内部文档、或需要特定领域知识),进入第二层定制。
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
class CustomRAG:
def __init__(self, doc_path: str):
# 1. 加载企业私有文档
docs = load_documents(doc_path)
# 2. 切分 + 向量化
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500)
chunks = text_splitter.split_documents(docs)
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())
# 3. 创建检索问答链
self.qa_chain = RetrievalQA.from_chain_type(
llm=ChatOpenAI(model="gpt-4"),
retriever=vectorstore.as_retriever(search_kwargs={"k": 5})
)
def ask(self, question: str) -> str:
# 检索相关文档片段 → 组装上下文 → LLM生成回答
return self.qa_chain.run(question)RAG 的定制化体现在知识库的私有性——你只需要维护文档库,模型能力可以保持不变。
当 RAG 检索到的文档本身不够结构化、或者你需要模型掌握特定的"表达风格"(如法律文书用语、客服话术)时,微调是更彻底的定制方案。
# 使用 Hugging Face 进行微调(简化的核心代码)
from transformers import AutoModelForCausalLM, TrainingArguments, Trainer
from datasets import Dataset
# 1. 准备训练数据(JSONL 格式:{"instruction": "...", "output": "..."})
train_data = Dataset.from_json("custom_train.jsonl")
# 2. 加载基础模型
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-7B-Instruct")
# 3. 配置 LoRA(低秩适配,一种高效的微调方法)
from peft import LoraConfig, get_peft_model
lora_config = LoraConfig(
r=8, # 秩
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05
)
model = get_peft_model(model, lora_config)
# 4. 训练
trainer = Trainer(
model=model,
args=TrainingArguments(
output_dir="./custom_model",
num_train_epochs=3,
per_device_train_batch_size=4,
learning_rate=2e-4
),
train_dataset=train_data
)
trainer.train()微调的本质是把业务知识"烧"进模型参数中——回答时不需要每次去查外部知识库,模型本身就"知道"。
一个完整的定制化 AI 应用,不是"一个模型打天下",而是分层设计:
┌─────────────────────────────────────────────┐
│ 接入层(Web/API/IM) │
├─────────────────────────────────────────────┤
│ 业务逻辑层(Workflow) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │意图识别 │ │路由分发 │ │后处理 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 模型层(Model Gateway) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │通用模型 │ │微调模型 │ │RAG引擎 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
├─────────────────────────────────────────────┤
│ 数据层(私有数据) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │业务DB │ │向量库 │ │文档库 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘关键设计原则:
常见误区 | 正确做法 |
|---|---|
一开始就上微调 | 先用 Prompt 工程 + RAG 快速验证,收集足够数据后再微调 |
用 1000 条数据微调 7B 模型 | 微调至少需要几千到几万条高质量数据,否则不如 RAG |
忽视评估 | 定制化的核心是"比通用模型好在哪",必须建立评估基准 |
一锤子买卖 | AI 定制是持续过程,需要持续收集反馈、更新知识库、重训模型 |
推荐的启动路径:
AI 应用定制化的本质,不是"把模型练得更好",而是把业务逻辑以最优方式嵌入到 AI 系统中。Prompt 工程解决"怎么说",RAG 解决"知道什么",微调解决"怎么表达",三层组合使用才能覆盖真实业务的复杂度。
如果你今天要启动一个定制化项目,建议从 "定义 100 个典型场景 + 用 Prompt 工程跑通 + 每天收集反馈" 开始——先让业务跑起来,再逐步深化定制。比起花两个月微调一个可能没用的模型,两周上线一个"能用的版本"更有价值。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。