
过去两年,我参与了超过30个大模型应用项目的评审,发现一个惊人的规律:
阶段 | 成功率 | 失败主因 |
|---|---|---|
Demo/POC | 90%能跑通 | 技术可行性不是问题 |
小规模试用 | 40%能继续 | 业务价值不清晰 |
生产级上线 | 15%能稳定运行 | “Demo陷阱”——场景太理想、数据太干净、评估太主观 |
持续迭代 | 5%能产生ROI | 无法构建数据飞轮 |
核心论断:AGI项目失败,90%不是因为大模型能力不够,而是因为一开始就选错了场景、定义错了成功标准、设计错了人机协作边界。
本文将带你走一遍完整的业务导向AGI开发流程,确保你的项目从第一天起就在为“上线”而设计,而不是为“展示”而设计。
不是所有业务场景都适合大模型。你需要先评估场景的“AI必要度”:
象限 | 场景特征 | 典型示例 | 策略 |
|---|---|---|---|
明星区 | 高频+高人工成本 | 客服工单分类、合同初筛 | 优先投入 |
潜力区 | 低频但高价值 | 投标方案撰写、尽调报告 | 谨慎验证 |
探索区 | 高频但低价值 | 日报周报生成、邮件润色 | 视资源投入 |
禁区 | 需要绝对确定性 | 金融风控决策、药物剂量计算 | 暂不碰 |
在选择具体场景时,逐项核对:
□ 该场景当前有人在做,且花费时间>2小时/天
□ 输出质量有“好”与“差”的明显区分,不存在唯一正确答案
□ 有历史数据(至少1000条以上)可作为效果评估基线
□ 场景边界清晰(不是“让AI管公司”,而是“让AI整理会议纪要”)
□ 错误结果的影响可控(不会导致客户流失或法律纠纷)
□ 用户愿意为效率提升付费或付出行为改变成本
□ 有明确的成功衡量指标(如:处理时长从30分钟降到5分钟)如果7项中低于5项,建议重新选场景。
很多人POC失败是因为数据太“干净”了。生产环境的数据是脏、乱、异构的。
数据准备三层结构:
├── 层1:原始数据(直接从生产环境拉取)
│ ├── 客服对话记录(含拼写错误、口语化表达)
│ ├── 用户上传的PDF/Word(格式混乱、有水印)
│ └── 系统日志(含大量噪音)
│
├── 层2:清洗与标注数据(投入最大人力的环节)
│ ├── 脱敏处理(去除PII)
│ ├── 统一格式(HTML转Markdown、PDF转文本)
│ ├── 质量筛选(去除无效样本)
│ └── 人工标注(建立Gold Standard)
│
└── 层3:增强数据(用于RAG检索或微调)
├── 知识图谱构建(实体关系抽取)
├── Q&A对生成(用大模型辅助生成训练数据)
└── 负样本构造(用于边界测试)不要试图标注所有数据。80%的标注精力花在边界案例上,20%花在典型案例上。
# 主动学习标注策略(用模型辅助筛选难例)
def active_learning_pipeline(unlabeled_data, model, budget=500):
"""
仅标注模型最不确定的样本,用最少的人工标注实现最大效果提升
"""
# 1. 用当前模型对未标注数据做预测
predictions = model.predict(unlabeled_data)
# 2. 按置信度排序,取最低的N条(模型最不确定的)
uncertainties = [abs(p - 0.5) for p in predictions] # 二分类举例
uncertain_indices = np.argsort(uncertainties)[:budget]
# 3. 推送给人标注
samples_to_label = [unlabeled_data[i] for i in uncertain_indices]
labeled = human_annotation(samples_to_label)
# 4. 加入训练集,重新训练模型
return labeled构建RAG知识库时,不要一下子灌入所有文档。
阶段 | 文档数量 | 目标 | 验证方式 |
|---|---|---|---|
第一周 | 3份核心文档 | 验证检索+生成的基本流程 | 人工检查top-5召回质量 |
第二周 | 30份扩展文档 | 验证多源异构文档的处理能力 | 端到端问答准确率>70% |
第三周 | 300份生产文档 | 验证系统在高负载下的稳定性 | 性能压测 + 人工抽检 |
关键教训:我见过最快的POC失败,是把3000份PDF一次性丢进去,然后发现检索准确率只有20%,根本无法定位问题出在文档解析、切分、向量化还是检索策略。
维度 | 评估指标 | 测量方法 | 目标值参考 |
|---|---|---|---|
准确性 | 答案正确率 | 人工评判/Golden Set | >85% |
完整性 | 信息遗漏率 | 检查是否覆盖所有关键点 | <10% |
可读性 | 语言流畅度 | 人工评分(1-5) | >4.0 |
相关性 | 回答切题度 | 余弦相似度/人工评分 | >0.8 |
一致性 | 同一问题多次回答的差异度 | 变异系数 | <15% |
时效性 | 是否引用最新信息 | 自动检测引用日期 | >90%引用<1月 |
安全性 | 有害内容/幻觉率 | 红队测试 | <0.5% |
Golden Set是评估AI系统的“标准答案集”,必须在系统上线前建立。
# Golden Set 构建流程
class GoldenSetBuilder:
def __init__(self):
self.human_answers = [] # 人类专家答案
self.ai_answers = [] # 待评估的AI答案
def build(self, test_queries: List[str], num_experts=3):
"""
每个问题由3位专家独立回答,取一致性最高的作为Golden Answer
"""
for query in test_queries:
# 1. 收集专家答案
expert_answers = [get_expert_answer(query) for _ in range(num_experts)]
# 2. 计算答案间的一致性
similarities = []
for i in range(num_experts):
for j in range(i+1, num_experts):
sim = compute_similarity(expert_answers[i], expert_answers[j])
similarities.append(sim)
# 3. 一致性>0.8的采纳,否则该问题留待讨论
if np.mean(similarities) > 0.8:
# 取投票最多的答案
golden = vote(expert_answers)
self.human_answers.append({
'query': query,
'golden_answer': golden,
'confidence': np.mean(similarities)
})
else:
# 需要专家讨论达成共识
golden = expert_consensus_discussion(expert_answers)
self.human_answers.append({
'query': query,
'golden_answer': golden,
'confidence': 1.0 # 讨论后确信
})
return self.human_answers上线后,评估不能停。建立自动化监控面板:
# 评估监控配置
evaluation_pipeline:
frequency: daily
sample_size: 100 # 每天随机抽样100条生产请求
metrics:
- llm_as_judge: # 用更强的大模型做评估
model: "gpt-4-turbo"
prompt_template: "请评价以下回答的质量,打分1-10..."
- user_feedback: # 收集用户反馈
source: "thumbs_up/down_buttons"
threshold: 0.8 # 满意度低于80%触发告警
- hallucination_detection:
method: "fact_checking_with_retrieval"
threshold: 0.05 # 幻觉率超过5%触发告警
alerting:
- slack_channel: "#ai-alerts"
- email: "ai-team@company.com"决策1:什么时候用RAG,什么时候用微调?
维度 | RAG | 微调 |
|---|---|---|
知识更新频率 | ✅ 实时更新(文档变化立即生效) | ❌ 需要重新训练,周期长 |
知识来源多样性 | ✅ 可接入多数据源 | ❌ 受限于训练数据 |
推理成本 | ✅ 仅增加检索成本 | ❌ 模型参数多,成本高 |
幻觉控制 | ✅ 可溯源到原文 | ❌ 难以控制 |
实现复杂度 | ✅ 较低(无需GPU训练) | ❌ 需要MLOps能力 |
推荐场景 | 知识密集型、动态更新的业务 | 风格/行为模式固定的业务 |
最佳实践:90%的业务场景先用RAG。微调只在以下情况考虑:
决策2:Agent设计——大而全还是小而专?
错误做法:做一个“万能Agent”,让它自己决定用什么工具。 正确做法:为每个场景设计专门的Agent,限制其工具集和决策空间。
# 错误:无限工具集
class UniversalAgent:
tools = ALL_TOOLS # 50+个工具
# 正确:场景限定的Agent
class CustomerSupportAgent:
tools = [
query_order_status, # 查订单
search_known_issues, # 查已知问题
create_ticket # 建工单
] # 只允许3个工具
def should_escalate(self, user_input):
# 明确的人机交接策略
if "投诉" in user_input or "退款" in user_input:
return True
return False决策3:如何应对模型输出的不确定性?
永远不要相信大模型会按你的格式输出。必须加一层“输出守卫”:
// 输出校验与修正器
@Component
public class OutputGuardian {
private static final Pattern JSON_PATTERN = Pattern.compile(
"\\{[^{}]*(?:\\{[^{}]*\\}[^{}]*)*\\}"
);
public StructuredOutput validateAndFix(String rawOutput, Class<?> expectedType) {
// 1. 尝试提取JSON(模型经常加额外文字)
Matcher m = JSON_PATTERN.matcher(rawOutput);
if (!m.find()) {
// 如果完全找不到JSON,触发降级
return fallbackResponse("模型输出格式异常");
}
String jsonStr = m.group();
try {
// 2. 尝试反序列化
Object result = objectMapper.readValue(jsonStr, expectedType);
// 3. 业务规则校验
validateBusinessRules(result);
return new StructuredOutput(result, true);
} catch (JsonProcessingException e) {
// 4. JSON格式错误,尝试修复常见问题
String fixed = fixCommonJsonErrors(jsonStr);
try {
Object result = objectMapper.readValue(fixed, expectedType);
return new StructuredOutput(result, true, "已自动修复JSON格式");
} catch (Exception ex) {
// 5. 修复失败,降级
return fallbackResponse("无法解析模型输出,请重试");
}
}
}
}大模型API成本可能超出预期。以下是经过验证的降本方案:
策略 | 实施方法 | 成本节省 |
|---|---|---|
语义缓存 | 相似问题命中缓存直接返回,不调API | 30-50% |
模型路由 | 简单问题用小模型(如DeepSeek-Lite),复杂问题用大模型 | 40-60% |
Prompt压缩 | 用LLMLingua等工具压缩长Prompt | 20-30% |
异步批处理 | 非实时任务合并批量处理 | 15-25% |
结果缓存 | 相同输入(参数)直接返回缓存结果 | 10-30% |
# 智能路由示例
class ModelRouter:
def route(self, query, context):
# 1. 计算查询复杂度
complexity = self.estimate_complexity(query)
# 2. 检查缓存
cached = self.cache.get(query)
if cached:
return cached, "cache_hit"
# 3. 根据复杂度选择模型
if complexity < 0.3:
# 简单事实性问题 -> 小模型
model = "deepseek-lite"
elif complexity < 0.7:
# 中等推理 -> 中模型
model = "deepseek-chat"
else:
# 复杂推理 -> 大模型
model = "gpt-4-turbo"
# 4. 记录路由决策,用于后续优化
self.log_decision(query, complexity, model)
return model, "model_routed"场景类型 | AI角色 | 人类角色 | 典型设计 |
|---|---|---|---|
内容辅助 | 生成初稿 | 审核+修改 | AI生成,人类编辑,标注修改 |
决策辅助 | 提供建议+证据 | 最终决策 | AI输出多方案+置信度,人类选择 |
自动化执行 | 完成常规任务 | 监控+处理异常 | AI自主执行,异常时升级给人 |
探索分析 | 发现模式+生成假设 | 验证假设+制定策略 | AI无监督分析,人类深度洞察 |
# 人机交接协议
class HandoffProtocol:
def decide_handoff(self, ai_output, confidence, context):
"""
决定是否需要人工介入
"""
# 规则1:置信度低于阈值 -> 升级人工
if confidence < 0.7:
return HandoffDecision.ESCALATE
# 规则2:涉及敏感操作 -> 强制人工
if context.get('sensitive_operation'):
return HandoffDecision.ESCALATE
# 规则3:用户明确要求 -> 升级人工
if context.get('user_requested_human'):
return HandoffDecision.ESCALATE
# 规则4:连续3次AI建议被用户拒绝 -> 升级人工
if context.get('consecutive_rejections', 0) >= 3:
return HandoffDecision.ESCALATE
return HandoffDecision.AUTO_COMPLETE
def prepare_handoff_context(self, ai_output):
"""为人工准备完整的上下文"""
return {
'ai_response': ai_output.text,
'confidence': ai_output.confidence,
'sources': ai_output.sources,
'alternative_answers': ai_output.alternatives,
'user_history': get_user_history(),
'system_state': get_current_system_state()
}用户反馈是系统持续改进的生命线。
-- 反馈数据表设计
CREATE TABLE ai_feedback (
id BIGSERIAL PRIMARY KEY,
session_id VARCHAR(64) NOT NULL,
query_text TEXT NOT NULL,
ai_response TEXT NOT NULL,
user_rating INT CHECK (user_rating BETWEEN 1 AND 5),
user_correction TEXT, -- 用户修改后的内容
user_comment TEXT,
was_accepted BOOLEAN, -- 用户是否直接采纳
response_time_ms INT,
model_used VARCHAR(32),
created_at TIMESTAMP DEFAULT NOW(),
INDEX idx_created_at (created_at),
INDEX idx_rating (user_rating)
);每月分析报告自动生成:
def generate_improvement_report():
with db_connection() as conn:
# 1. 低满意度问题识别
low_rated = conn.query("""
SELECT query_text, user_comment, model_used
FROM ai_feedback
WHERE user_rating <= 2
AND created_at > NOW() - INTERVAL '30 days'
GROUP BY query_text, user_comment, model_used
ORDER BY COUNT(*) DESC
LIMIT 20
""")
# 2. 调用大模型分析根因
analysis = llm.invoke(f"""
以下是最低评分的用户反馈,请分析共性模式:
{low_rated}
请输出:
1. 主要问题分类(理解错误/信息不全/格式问题/其他)
2. 改进建议
3. 优先级排序
""")
# 3. 自动生成改进任务
create_jira_issues(analysis)
return analysis三个“不要”:
三个“一定要”:
版本 | 目标 | 核心能力 | 用户感受 |
|---|---|---|---|
V1.0 | 可用 | 单轮问答 + 固定知识库 | “有时挺准,有时很傻” |
V1.5 | 可信 | 加引用溯源 + 置信度 | “至少知道它为什么这么答” |
V2.0 | 可靠 | 多轮对话 + 上下文记忆 | “它记得我之前说过什么” |
V2.5 | 高效 | 主动反问 + 信息补全 | “比有些新人客服还专业” |
V3.0 | 智能 | 任务执行 + 主动建议 | “像个有经验的同事” |
每两个版本之间间隔建议2-3个月,给数据积累和团队消化留足时间。
陷阱 | 我们的错误做法 | 事后反思 |
|---|---|---|
场景定义过宽 | 想让AI审查“所有类型的合同” | 改为只审查“标准销售合同”(格式固定、条款可枚举) |
数据准备不足 | 直接扫描了500份PDF丢给AI | 人工精标了100份合同,覆盖所有风险条款类型 |
评估标准模糊 | “感觉AI审查得还行” | 制定17条明确的风险类别,逐条对比召回率 |
忽视人机流程 | 让AI直接出审查报告 | 改为AI标注风险条款+建议,法务审核确认 |
成本失控 | 每份合同全量调用GPT-4 | 用规则引擎先筛出高风险条款,再用大模型深度分析 |
指标 | 实施前 | 实施后 |
|---|---|---|
单份合同审查时长 | 150分钟 | 45分钟 |
人工投入 | 3位资深法务 | 1位资深法务 + AI |
风险检出率 | 85%(人工水平) | 92%(AI + 人工复核) |
月度处理能力 | 200份 | 600份(不增加人力) |
法务满意度 | 3.2/5 | 4.5/5(重复工作大幅减少) |
关键成功因素:
回顾所有成功与失败的AGI项目,最大的差异不在模型选型、不在代码质量,而在于:
成功者把大模型当作一个“需要被管理和约束的员工”,失败者把它当作一个“魔法黑盒”。
要避开Demo陷阱,请始终问自己三个问题:
大模型不是银弹,但它是过去10年最具生产力的工具。用对场景、做对设计、持续迭代,你完全可以从Demo走向真正的业务价值。
现在,关掉这篇文章,去和你的业务方聊一聊——他们真正的痛点是什么?
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。