大模型算法应用与 提示词工程：把经验沉淀成下一次的规则
讨论时，一次 Prompt 改动后，告警群出现大量结构化解析错误。
原本运行平稳的文档摘要与实体抽取服务，突发爆出了大量的结构化解析错误。登上服务器查看日志，发现某位工程师在上个版本提交中，针对某个特例 Bad Case 修改了全局 System Prompt。他加上了三句极具强力倾向的提示要求，结果导致另外四个分支场景的 JSON 输出全部脱轨。模型把原本该放在属性字段里的字段直接提取成了根节点的数组。
这说明仅靠反复修改提示词并不可靠。提示词调整应配合可复现样本、结构校验和回归测试；能由代码表达的约束，不必完全依赖自然语言指令。
1. 现场噩梦：线上人工修 Prompt 导致另外四个分类爆了
那次线上事故的根因过程非常典型。业务方反馈有一批特殊的法律合同文本无法正确识别出履约期限，工程师在调试时为了提高该特例的召回率，在 Prompt 中增加了硬性命令：“一旦文本中出现任何时间节点，必须优先填充至 context_deadline 字段中”。
后果在三小时后显现。普通的采购订单、售后工单等非合同类文本流经大模型时，原本正常的“报修时间”、“创建时间”被强行塞进了context_deadline字段。更严重的是，模型为了满足这一强约束，开始牺牲 JSON Schema 的规范性，在缺少时间节点时输出空字符串甚至带注释的非法文本。
// 线上报错的畸形输出 { "order_id": "ORD-99823", "context_deadline": null /* 提示词要求必须包含时间，但文本未提供 */, "items": ["server_rack"] }这类事故表明，把业务逻辑全盘压在一段非结构化文本的自然语言指令上，极其脆弱。自然语言缺少强类型约束，其注意力分布会在不同上下文长度下发生意想不到的偏移。
2. 单纯依赖 System Prompt 堆叠提示词的边界坍塌
在工程早期，团队最容易走入的误区就是持续向 System Prompt 膨胀添加规则。从 500 字一路增加到 4000 字，包含各种“如果...那么...不应...必须...”的复杂逻辑。
这种做法会迅速击穿模型的注意力机制，带来三个灾难性后果：
- Instruction Following 准确率剧烈下降：当 Prompt 中的指令冲突或密度过高时，模型对尾部指令的遵从度会呈指数级衰减。
- 推理延时与 Token 成本线性暴涨：每一次 API 调用都在为庞大且重复的静态规则支付上下文费用，首包时间（TTFT）显著增加。
- 代码化回归测试无从下手的僵局：你无法评估修改第 3 0 行规则会影响第 80 行规则的哪一部分逻辑，整体陷入黑盒化。
大模型本质上是一个概率文本生成器，而不是可靠的条件分支执行引擎。用概率组件去硬扛确定性的条件分支，本身就是架构上的错位。
3. 从坏 Case 到确定性断言：三层规则提取链路
为了把坏 Case 转变成可靠的规则体系，需要构建一套覆盖全生命周期的规则演进链路。该链路分为输入拦截、输出断言以及离线 Rule 沉淀三层。
在这套架构中，Bad Case 不再被直接通过修改 Prompt 去“贴补丁”，而是经过处理转化为两类产物：一类是直接加入Input Guard的确定性正则表达式与规则引擎；另一类是转化为离线回归测试集中的硬性断言（Assertion）。只有通过全量 Assertion 校验的 Prompt 修改，才允许合并上线。
4. 基于动态匹配与正则断言的 Prompt 自动拦截器代码
在具体代码实现层面，可以构建一套基于 Python Pydantic 与正则断言的强拦截器。以下是生产环境可运行的核心实现逻辑，具备异常捕获与规则匹配降级机制：
import re import json from typing import Dict, Any, Optional, List from pydantic import BaseModel, ValidationError, field_validator class ExtractedEntity(BaseModel): order_id: str context_deadline: Optional[str] = None items: List[str] @field_validator("order_id") def validate_order_id(cls, v: str) -> str: if not re.match(r"^ORD-\d+$", v): raise ValueError(f"畸形的订单ID格式: {v}") return v class PromptRuleInterceptor: def __init__(self, bad_case_rules_path: str): self.exact_rules: Dict[str, Dict[str, Any]] = {} self.regex_rules: List[Dict[str, Any]] = [] self._load_rules(bad_case_rules_path) def _load_rules(self, path: str) -> None: """加载从历史 Bad Case 沉淀出的硬规则集""" try: with open(path, "r", encoding="utf-8") as f: data = json.load(f) self.exact_rules = data.get("exact_matches", {}) self.regex_rules = data.get("regex_patterns", []) except FileNotFoundError: self.exact_rules = {} self.regex_rules = [] def pre_intercept(self, user_input: str) -> Optional[Dict[str, Any]]: """输入前置拦截：命中历史 Bad Case 规则直接返回确定性结果，不走 LLM""" cleaned_input = user_input.strip() if cleaned_input in self.exact_rules: return self.exact_rules[cleaned_input] for rule in self.regex_rules: if re.search(rule["pattern"], cleaned_input): return rule["override_output"] return None def post_validate_and_sanitize(self, raw_llm_output: str) -> ExtractedEntity: """后置结果校验：强制清洗注释并执行强类型 Schema 校验""" # 移除 LLM 可能输出的 Markdown 代码块修饰与 C 风格注释 sanitized = re.sub(r"```json\s*", "", raw_llm_output) sanitized = re.sub(r"```\s*$", "", sanitized) sanitized = re.sub(r"/\*.*?\*/", "", sanitized, flags=re.DOTALL) try: parsed_json = json.loads(sanitized) return ExtractedEntity(**parsed_json) except (json.JSONDecodeError, ValidationError) as err: # 校验失败抛出强类型异常，触发上游断路器或降级逻辑 raise RuntimeError(f"LLM 输出未通过规则检验: {str(err)}") from err这套代码将校验逻辑显式地分离出 LLM 主体。无论模型吐出何种带有注释或格式偏移的内容，后置清洗器与 Pydantic 会在第一时间进行拦截断言，绝不允许非法数据穿透至下游数据库。
5. 向量检索动态 Few-Shot 与静态硬规则的混合编排
解决规则膨胀的另一个关键工具，是动态 Few-Shot 编排。不要把所有历史经验与示例都写死在 System Prompt 中。
通过将过去积累的典型 Bad Case 及其纠错示例存入 Vector Store，在发起请求前，先根据当前 User Input 进行语义相似度 Top-K 检索。仅将最相关的 2~3 个修正 Example 组装进上下文。
# 动态上下文编排的伪代码逻辑 def build_dynamic_prompt(user_query: str, retriever, base_system_prompt: str) -> str: # 针对当前输入检索相关的 Bad Case 案例 relevant_examples = retriever.search(user_query, top_k=2) few_shot_context = "" for ex in relevant_examples: few_shot_context += f"\n[历史易错案例参考]\n输入: {ex.input}\n正确输出格式: {ex.correct_output}\n" final_prompt = f"{base_system_prompt}\n{few_shot_context}\n[当前任务输入]\n{user_query}" return final_prompt这种模式让 System Prompt 的体积从上千行骤降至百行以内，大幅提升了模型的聚焦能力，同时将上下文 Token 消耗降低了 60% 以上。
6. 线上规则变更的回归测试与金丝雀版本隔离
将经验沉淀为规则的最后一步，是建立严格的发布流水线。
任何修改 Prompt 的提交，都必须在 CI 阶段自动化运行包含数百个历史 Bad Case 的测试集（Evaluation Dataset）。测试指标不仅看单个 Case 的通过率，更要统计以下硬性指标：
- Schema Compliance Rate：JSON 格式合规率必须为 100%。
- Regression Rate：历史已修复场景的退化率必须为 0%。
- Latency Shift：首包延迟变化幅度不得超过 15%。
在部署策略上，引入金丝雀灰度隔离。先切 5% 的线上真实流量进入新 Prompt 版本的路由容器，配置监控探针抓取后置post_validate_and_sanitize的报错率。一旦报错率相比基线抖动超过 0.5%，自动触发 API Gateway 级别的路由回滚。把手感依赖彻底踢出生产环境，才是算法真正落地的开始。
