大模型产品经理(LLM PM)的专业分水岭,不在于会写多少 prompt,而在于能否把"用户想要更智能的体验"翻译成可评测、可回归、可上线的工程契约。传统 PM 交付 PRD,LLM PM 交付的是"评测集 + 约束定义 + 降级策略"三件套。本文从四个实战动作拆解,并给出 PM 自己就能维护的代码。
"回答要准确、要有帮助"不是需求,是愿望。可验收的需求必须写成指标 + 阈值 + 评测集三元组。PM 应当能独立维护这份定义,而不是等算法团队给数字。
# evals/spec.py —— PM 维护的需求规格,算法与测试共用
from dataclasses import dataclass, field
@dataclass
class Requirement:
name: str
metric: str # 指标定义
threshold: float # 验收线
cases_path: str # 黄金集
blocking: bool = True # 不达标是否阻断发布
notes: str = ""
SPECS = [
Requirement("答案事实正确", "factual_acc", 0.92, "evals/gold/facts.jsonl"),
Requirement("引用可追溯", "citation_rate", 0.98, "evals/gold/cite.jsonl"),
Requirement("拒答越界问题", "refusal_acc", 0.95, "evals/gold/refuse.jsonl"),
Requirement("首字延迟", "p95_ttft_ms", 1200, "evals/gold/perf.jsonl", blocking=False),
]要点:blocking 区分"硬指标"与"软指标",让发布决策有优先级;指标名、阈值、数据集路径全部代码化,改需求即改代码,走 review,而非散落在文档里各自理解。
LLM 产品的可靠性,很大程度取决于输出是否被 schema 约束。PM 决定产品"长什么样",本质是决定 schema 长什么样。带约束的 JSON 输出 + 校验重试,是 PM 必须要求的工程基线。
from pydantic import BaseModel, Field, ValidationError
import json
class Answer(BaseModel):
conclusion: str = Field(max_length=200) # 先给结论
evidence: list[str] = Field(min_length=1, max_length=3) # 必须带证据
confidence: float = Field(ge=0, le=1)
followup: str | None = None
def generate(llm, question: str, retries: int = 2) -> Answer:
for _ in range(retries + 1):
raw = llm.complete(
f"问题:{question}\n按 schema 输出 JSON: {Answer.model_json_schema()}",
temperature=0)
try:
return Answer(**json.loads(raw))
except (json.JSONDecodeError, ValidationError):
continue
return Answer(conclusion="暂时无法可靠回答", evidence=["系统降级"],
confidence=0.0) # 明确降级,不编造要点:evidence 设 min_length=1 把"可追溯"从愿望变成强制字段;confidence 字段为后续分档展示与人工介入提供依据;重试耗尽后返回显式降级结果,这是 LLM 产品与普通 API 最大的体验差异——失败也要体面。
LLM 产品经理必须同时优化三个维度:质量、成本、延迟。三者常冲突,PM 的职责是定义分档策略,而不是让模型对所有请求一视同仁。
ROUTE = {
"simple": {"model": "small", "max_tokens": 300, "budget_ms": 800},
"complex": {"model": "large", "max_tokens": 2000, "budget_ms": 6000},
}
def route(question: str) -> dict:
# 规则优先,可解释、可回归、零成本
if len(question) < 60 and "为什么" not in question:
return ROUTE["simple"]
return ROUTE["complex"]
def handle(llm, question: str) -> Answer:
cfg = route(question)
ans = generate(llm.bind(cfg["model"], cfg["max_tokens"]), question)
if ans.confidence < 0.6:
ans.followup = "是否需要转人工确认?" # 低置信度触发人工路径
return ans要点:路由用规则而非模型——可解释、可写测试、零边际成本;confidence 阈值把"模型不确定"转化为产品动作(转人工),这是提升用户信任的关键设计。
LLM 的版本差异是"软"的——模型换了,接口没变,但行为可能全变。所以 PM 必须定义灰度维度与回滚条件,并与评测集联动。
def canary_gate(old_metrics: dict, new_metrics: dict, specs: list) -> bool:
for s in specs:
if not s.blocking:
continue
key = s.metric
if key.endswith("_ms"): # 延迟类指标越小越好
if new_metrics[key] > s.threshold:
return False
elif new_metrics[key] < s.threshold: # 准确率类越大越好
return False
if new_metrics[key] < old_metrics[key] - 0.02: # 不得显著劣化
return False
return True反馈闭环同样要产品化:每条点踩必须带上 trace_id,PM 每周把高价值 badcase 回流进黄金集,形成"线上问题 → 评测用例 → 回归门禁"的循环。评测集是 LLM 产品唯一会持续增值的资产,PM 应把它当核心交付物管理,而非附属文档。
可验收的 LLM 产品交付物包括:需求规格代码(指标+阈值+数据集)、输出 schema 定义、分档策略与降级话术、灰度与回滚条件、badcase 回流机制。五者缺一,产品就会陷入"感觉变好了/变差了"的不可证伪争论。
大模型产品经理的实战能力,可以用一句话检验:当老板问"新版到底比旧版好还是坏",能否立刻给出指标对比与置信判断。能,说明需求已被编译成契约;不能,那只是把 demo 包装成了"产品"。专业 LLM PM 的全部功夫,都花在让这句话永远有答案上。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。