1. 项目概述从“幻觉”到“可控”的工程化实践在深度使用大语言模型LLM进行应用开发时我们几乎都遇到过同一个令人头疼的问题模型的输出不稳定。有时它妙语连珠精准地解决了问题有时却会一本正经地“胡说八道”生成一些看似合理但完全错误或脱离指令的“幻觉”内容。这种不确定性是LLM从实验室玩具走向生产级应用的最大障碍之一。我们需要的不是一个偶尔会“灵光一现”的黑箱而是一个输出稳定、质量可控、能够持续自我改进的可靠系统。这正是“LLM自优化流水线”要解决的核心问题。这个项目我们称之为“Harness”其目标就是构建一套工程化的框架将LLM的“自由发挥”纳入一个可观测、可评估、可优化的闭环流程中。它不是一个单一的算法而是一套组合了多种技术思想的工程实践核心在于利用LLM自身的能力LLM as Judge和系统化的采样策略如Best of N Sampling来自动化地筛选、评估并迭代优化LLM的生成结果。简单来说就是让LLM自己当裁判从自己生成的多个答案中选出最好的那个并从中学习如何变得更好。这个过程不是一次性的而是一个可以持续运行的“流水线”每一次交互都是一次微小的优化迭代最终目标是让模型的输出越来越符合我们的预期将“幻觉”的概率降到最低实现输出的高度“可控”。这套流水线非常适合那些对输出质量有严格要求且需要自动化处理的场景。比如自动生成产品描述、代码审查注释、客服话术质检、报告摘要等。如果你正在为LLM输出的随机性而烦恼希望构建一个更健壮、更可靠的AI应用那么这个手把手构建Harness的过程将为你提供一个清晰的工程蓝图。2. 自优化流水线的核心架构与设计思路构建一个有效的自优化流水线关键在于设计一个能够自我评估、自我修正的闭环系统。我们不能指望单次提示就能得到完美答案而是要通过“生成-评估-选择-反馈”的循环来逼近最优解。Harness的架构正是围绕这个循环展开的。2.1 核心组件与工作流拆解一个完整的Harness流水线通常包含以下几个核心组件它们像工厂的流水线一样协同工作提示词工程与任务分解器这是流水线的起点。它的任务不仅仅是发送一个简单的用户查询而是将复杂任务分解为LLM更容易理解和执行的子任务并精心设计系统提示词System Prompt来约束模型的行为范围减少无关“幻觉”的产生。例如生成SQL的任务可能会先分解为“理解自然语言问题”、“识别实体和关系”、“映射到数据库schema”等步骤。候选生成器这是利用LLM生成能力的环节。对于同一个输入我们不会只生成一个答案。这里会采用诸如Best of N Sampling、温度采样Temperature Sampling、Top-p采样等策略让模型基于相同的提示词生成N个例如5个或10个不同的候选回答。多样性是后续优化的基础。评估器这是流水线的“大脑”和“裁判”通常由另一个LLM实例扮演即LLM as Judge。它的职责是根据预设的、明确的标准如准确性、相关性、完整性、安全性、风格一致性等对生成的N个候选答案进行打分或排序。评估提示词的设计至关重要它需要将主观的质量要求转化为客观、可比较的评分项。选择与聚合器评估器给出评分后这个组件负责根据分数选出最优答案。策略可以很简单比如直接选择最高分也可以很复杂比如根据多个维度分数加权计算或者设置最低阈值仅输出达标的结果。反馈与优化循环这是实现“自优化”的关键。被选出的最优答案及其生成路径包括使用的提示词、中间步骤等可以被记录下来形成一个高质量的数据对。这些数据对可以用于后续的提示词迭代优化如通过少量示例进行提示词微调或者在极端情况下作为微调数据集对模型本身进行微调从而让模型在下一次类似任务中表现更好。这个工作流的核心思想是将不确定性前置并系统化处理。与其祈祷单次生成的结果是好的不如承认生成具有随机性然后通过系统化的方法从多个可能中找出最好的那个并让系统从这个过程中学习。2.2 为什么是“Best of N” “LLM as Judge”这是Harness架构中最经典也最有效的组合拳其背后的逻辑非常坚实。Best of N Sampling解决了“广度”问题。LLM的生成本质上是概率性的单次采样就像抽奖可能抽到“头奖”完美答案也可能抽到“谢谢惠顾”幻觉答案。通过多次独立采样我们极大地提高了抽中“头奖”或至少是“二等奖”的概率。这比单纯调整温度参数更直接有效因为高温度虽然增加多样性但也可能直接导致语法混乱低温度虽然稳定但可能陷入局部最优、缺乏创意。Best of N在保持生成质量基线通常用较低温度的同时通过增加尝试次数来覆盖更多的可能性空间。LLM as Judge解决了“评估”问题。传统的评估方法可能需要编写复杂的规则引擎或者依赖人工标注前者不够灵活后者成本高昂且无法自动化。而使用LLM作为评估者其优势在于灵活性你可以用自然语言定义复杂的评估标准LLM能够理解。例如“检查这个代码片段是否存在安全漏洞并解释原因”。上下文感知LLM可以结合原始问题和生成的答案进行整体评估理解答案是否真正解决了问题。可扩展性增加一个新的评估维度通常只需要修改评估提示词而无需重写整个评估系统。将两者结合就形成了一个高效的“生成-筛选”漏斗生成器提供多样化的候选评估器用智能的标准进行过滤和排序最终输出经得起检验的结果。这个组合将LLM从一个“生成器”升级为一个具备“批判性思维”和“质量控制”能力的系统。注意LLM as Judge并非完美。它自身也可能产生评估“幻觉”比如对某个细微错误过度惩罚或对流畅但错误的答案给予高分。因此评估提示词需要精心设计有时甚至需要引入多个LLM进行“交叉验证”或者结合一些确定性规则如代码能否通过编译、SQL能否执行来增强评估的可靠性。3. 手把手构建Harness从环境准备到核心实现理论讲完了我们进入实战环节。我将以一个具体的场景为例手把手搭建一个简化但功能完整的Harness流水线。我们的场景是构建一个“文本转JSON”的自动化工具。用户输入一段描述性的文本我们需要输出结构化的JSON数据。这是一个非常典型的需求在数据抽取、表单填写、API参数生成等场景下广泛应用也极易因为模型理解偏差而产生“幻觉”比如生成错误的字段名或值。3.1 环境准备与工具选型工欲善其事必先利其器。我们首先需要搭建开发环境。编程语言与框架Python是目前LLM生态最丰富的语言。我们将使用openai库或兼容OpenAI API的库如litellm来调用模型使用pydantic来定义严谨的数据结构使用langchain或llama-index来构建流水线框架会更方便但为了理解底层原理我们先从基础实现开始。模型选择对于生成和评估我们都可以使用同一个强大的模型例如GPT-4 Turbo、Claude 3或者开源的DeepSeek-V2、Qwen2.5。考虑到成本和可控性生成器可以使用性价比高的模型如GPT-3.5-Turbo、DeepSeek-V2而评估器为了更高的判断力建议使用能力更强的模型如GPT-4。对于本地部署可以选择Qwen2.5-72B-Instruct这类高性能开源模型。关键库安装pip install openai pydantic tenacityopenai: 用于调用API。pydantic: 用于数据验证和设置确保输入输出的结构。tenacity: 用于实现API调用的重试机制增强流水线的鲁棒性。项目结构规划harness_project/ ├── config.py # 存放API密钥、模型配置等 ├── schemas.py # 用Pydantic定义输入/输出JSON Schema ├── generator.py # 候选生成器模块 ├── evaluator.py # LLM评估器模块 ├── selector.py # 答案选择器模块 ├── pipeline.py # 主流水线串联所有组件 └── main.py # 示例运行入口3.2 定义任务与数据结构文本转JSON首先我们必须明确任务边界。模糊的任务会导致模糊的结果。我们使用Pydantic来严格定义我们希望输出的JSON结构。假设我们要从产品描述中提取信息输出结构化的产品数据。我们在schemas.py中定义from pydantic import BaseModel, Field from typing import List, Optional class ProductInfo(BaseModel): 产品信息数据结构 product_name: str Field(description产品名称) brand: Optional[str] Field(defaultNone, description品牌如未提及则为None) main_category: str Field(description主要分类如电子产品、家居用品) price: Optional[float] Field(defaultNone, description价格单位元如未提及则为None) key_features: List[str] Field(description关键特性列表至少一项) in_stock: bool Field(description是否有库存) # 可以添加自定义验证器 # validator(price) # def price_must_be_positive(cls, v): # if v is not None and v 0: # raise ValueError(价格必须为正数) # return v这个ProductInfo类就是我们期望的“完美答案”的蓝图。它明确了每个字段的名称、类型、是否可选以及描述。这个Schema有两个重要作用用于生成我们可以将其描述作为系统提示词的一部分极大地约束LLM的输出格式减少格式错误。用于验证在评估阶段我们可以先尝试用Pydantic解析LLM生成的JSON字符串如果解析失败说明格式不正确可以直接给予低分或淘汰。这是第一道也是最硬的过滤网。3.3 实现候选生成器接下来我们实现generator.py中的CandidateGenerator类。它的核心是调用LLM API并利用温度等参数进行多次采样。import openai import json from tenacity import retry, stop_after_attempt, wait_random_exponential from schemas import ProductInfo from typing import List import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class CandidateGenerator: def __init__(self, model: str gpt-3.5-turbo, api_key: str None): self.client openai.OpenAI(api_keyapi_key) self.model model retry(stopstop_after_attempt(3), waitwait_random_exponential(min1, max20)) def _call_llm(self, prompt: str, temperature: float 0.7) - str: 带重试机制的LLM调用 try: response self.client.chat.completions.create( modelself.model, messages[{role: system, content: 你是一个精准的信息抽取助手必须严格按照给定的JSON格式输出。}, {role: user, content: prompt}], temperaturetemperature, response_format{type: json_object} # 强制要求返回JSON ) return response.choices[0].message.content except Exception as e: logger.error(fLLM调用失败: {e}) raise def generate_candidates(self, user_input: str, schema: BaseModel, n: int 5) - List[dict]: 生成N个候选答案 candidates [] # 构建系统化的提示词 schema_description schema.schema_json(indent2) # 获取JSON Schema描述 system_prompt f 你的任务是从用户输入中提取信息并填充到以下JSON结构中。 请严格遵循此结构只输出JSON对象不要有任何额外解释。 JSON Schema: {schema_description} 示例仅说明格式内容不一定相关 输入“这是一款苹果手机iPhone 15属于智能手机售价5999元特点是超视网膜显示屏和A16芯片目前有货。” 输出{{product_name: iPhone 15, brand: 苹果, main_category: 智能手机, price: 5999.0, key_features: [超视网膜显示屏, A16芯片], in_stock: true}} 现在请处理以下输入 full_prompt system_prompt f\n输入{user_input} for i in range(n): # 可以微调温度让每次生成略有不同。例如第一次用较低温度求稳后面几次用稍高温度探索。 temp 0.3 if i 0 else 0.7 try: raw_output self._call_llm(full_prompt, temperaturetemp) # 尝试解析为Python字典 parsed_dict json.loads(raw_output) candidates.append({ raw_text: raw_output, parsed_dict: parsed_dict, index: i, temperature_used: temp }) logger.info(f成功生成候选答案 {i1}/{n}) except json.JSONDecodeError as e: logger.warning(f候选 {i} 输出不是合法JSON已丢弃。错误: {e}) # 可以选择记录这个错误答案用于分析但在此不加入候选池 candidates.append({ raw_text: raw_output, parsed_dict: None, index: i, temperature_used: temp, error: str(e) }) except Exception as e: logger.error(f生成候选 {i} 时发生未知错误: {e}) return candidates实操心得重试机制是必须的API调用可能因网络、速率限制失败tenacity库能优雅地处理间歇性故障。利用response_formatOpenAI等API支持指定返回格式为json_object这能显著提高模型输出合规JSON的概率。温度策略第一个候选用较低温度如0.3确保一个“稳健”的基线答案后续用较高温度如0.7探索更多可能性。这是一种简单有效的多样性策略。立即验证JSON在生成环节就进行初步的JSON语法验证将无法解析的结果标记出来避免污染后续的评估流程。3.4 实现LLM评估器这是Harness最精妙的部分。我们在evaluator.py中构建评估器。评估标准需要具体、可操作。我们将从以下几个维度打分每个维度1-5分格式正确性输出是否为严格符合Schema的JSON此维度可一票否决信息完整性是否提取了输入文本中所有相关且Schema要求的字段信息准确性提取的值是否与输入文本描述一致有无虚构或曲解逻辑合理性提取的信息在常识和业务逻辑上是否合理例如价格不会是负数class LLMEvaluator: def __init__(self, judge_model: str gpt-4, api_key: str None): self.client openai.OpenAI(api_keyapi_key) self.judge_model judge_model def create_evaluation_prompt(self, user_input: str, candidate_output: dict, schema: BaseModel) - str: 构建评估提示词 schema_description schema.schema_json(indent2) evaluation_criteria 请你作为公正的裁判根据以下标准对候选答案进行评分1-5分5分为最佳。请先进行思考然后给出各维度分数及简要理由最后输出一个JSON格式的评分结果。 评分维度 1. 格式正确性候选答案是否是一个完全符合提供之JSON Schema的、无语法错误的JSON对象如果不符合此项直接1分。 2. 信息完整性候选答案是否填充了Schema中所有非可选字段是否尽可能填充了可选字段参考原始输入 3. 信息准确性候选答案中每个字段的值是否严格忠实于用户输入文本有无添加、删减或曲解原文信息 4. 逻辑合理性候选答案在常识和业务逻辑上是否合理例如价格应为正数库存状态应为布尔值 请基于以下信息进行评估 - 用户输入{user_input} - 目标JSON Schema{schema_description} - 候选答案{candidate_json} 你的输出必须是且仅是一个JSON对象包含以下字段 {{ reasoning: 你的逐步思考过程, scores: {{ format_correctness: 分数, information_completeness: 分数, information_accuracy: 分数, logical_soundness: 分数 }}, overall_score: 平均分, has_critical_error: 布尔值如果格式错误或严重歪曲事实则为true }} # 将候选字典转为格式化的JSON字符串用于展示 candidate_json_str json.dumps(candidate_output, ensure_asciiFalse, indent2) if candidate_output else 无效JSON或为空 prompt evaluation_criteria.format( user_inputuser_input, schema_descriptionschema_description, candidate_jsoncandidate_json_str ) return prompt retry(stopstop_after_attempt(2), waitwait_random_exponential(min2, max30)) def evaluate_candidate(self, user_input: str, candidate: dict, schema: BaseModel) - dict: 评估单个候选答案 # 检查1如果生成时就没解析成功直接给最低分 if candidate.get(parsed_dict) is None: return { scores: {format_correctness: 1, information_completeness: 1, information_accuracy: 1, logical_soundness: 1}, overall_score: 1.0, has_critical_error: True, reasoning: 候选答案非有效JSON无法解析。 } eval_prompt self.create_evaluation_prompt(user_input, candidate[parsed_dict], schema) try: response self.client.chat.completions.create( modelself.judge_model, messages[{role: system, content: 你是一个严谨、公正的质量评估助手。}, {role: user, content: eval_prompt}], temperature0.0, # 评估需要确定性温度设为0 response_format{type: json_object} ) eval_result json.loads(response.choices[0].message.content) # 将评估结果合并到候选信息中 candidate.update({evaluation: eval_result}) return candidate except Exception as e: logger.error(f评估候选 {candidate.get(index)} 时失败: {e}) # 评估失败给予一个保守的中等偏下分数 default_eval { scores: {format_correctness: 2, information_completeness: 2, information_accuracy: 2, logical_soundness: 2}, overall_score: 2.0, has_critical_error: False, reasoning: f评估过程发生异常{e} } candidate.update({evaluation: default_eval}) return candidate注意事项评估模型的选择评估器Judge通常需要比生成器更强的推理和理解能力以确保评估质量。GPT-4、Claude 3 Opus是很好的选择。如果成本敏感可以尝试让生成器模型自我评估但效果会打折扣。评估提示词是核心提示词必须清晰、无歧义地定义评分标准。要求模型先进行“思考”reasoning再输出分数有助于提高评估的稳定性和可解释性。这种“思维链”提示对评估任务非常有效。温度设为0评估需要一致性和客观性因此应将温度参数设为0确保相同的输入得到相同的评估输出。结构化输出强制要求评估器返回结构化JSON便于程序自动化处理评分结果。3.5 实现选择器与聚合逻辑评估完成后selector.py中的Selector类需要根据评估结果做出选择。策略可以多样化from typing import List, Dict, Any class Selector: staticmethod def select_best_by_score(evaluated_candidates: List[Dict[str, Any]]) - Dict[str, Any]: 根据综合得分选择最佳候选 valid_candidates [c for c in evaluated_candidates if not c.get(evaluation, {}).get(has_critical_error, True)] if not valid_candidates: logger.error(所有候选答案均存在关键错误无法选择。) # 可以返回一个兜底答案或触发人工干预 return {error: No valid candidate found, fallback: evaluated_candidates[0] if evaluated_candidates else None} # 按整体分数排序 sorted_candidates sorted(valid_candidates, keylambda x: x[evaluation][overall_score], reverseTrue) best_candidate sorted_candidates[0] # 记录选择理由 best_candidate[selection_reason] f综合得分最高 ({best_candidate[evaluation][overall_score]:.2f}) return best_candidate staticmethod def select_by_threshold(evaluated_candidates: List[Dict[str, Any]], min_overall: float 3.5, min_accuracy: float 4.0) - List[Dict[str, Any]]: 根据阈值筛选合格候选可用于多答案输出或后续人工复核 qualified [] for cand in evaluated_candidates: eval_data cand.get(evaluation, {}) if eval_data.get(has_critical_error): continue if (eval_data.get(overall_score, 0) min_overall and eval_data.get(scores, {}).get(information_accuracy, 0) min_accuracy): qualified.append(cand) return qualified选择策略的考量简单最高分最直接的策略适用于大多数情况。阈值过滤设置最低分数线只有达标的结果才被输出。如果多个达标可以全部返回供下游处理或按分数排序。加权评分不同维度的分数重要性不同。例如对于“文本转JSON”“信息准确性”的权重可能远高于“逻辑合理性”。可以在选择器中实现加权平均计算。一票否决如果某个维度如格式正确性得分极低即使总分高也可以淘汰。3.6 组装完整流水线与运行示例最后我们在pipeline.py中将所有组件串联起来形成一个完整的HarnessPipeline类。class HarnessPipeline: def __init__(self, generator_model: str, judge_model: str, api_key: str): self.generator CandidateGenerator(modelgenerator_model, api_keyapi_key) self.evaluator LLMEvaluator(judge_modeljudge_model, api_keyapi_key) self.selector Selector() def run(self, user_input: str, output_schema: BaseModel, num_candidates: int 5) - Dict[str, Any]: 运行完整自优化流水线 logger.info(f开始处理输入: {user_input[:50]}...) # 1. 生成候选 logger.info(f步骤1: 生成 {num_candidates} 个候选答案...) candidates self.generator.generate_candidates(user_input, output_schema, nnum_candidates) # 2. 评估候选 logger.info(步骤2: 评估候选答案...) evaluated_candidates [] for cand in candidates: evaluated self.evaluator.evaluate_candidate(user_input, cand, output_schema) evaluated_candidates.append(evaluated) # 3. 选择最佳 logger.info(步骤3: 选择最佳答案...) best_candidate self.selector.select_best_by_score(evaluated_candidates) # 4. 最终验证与格式化输出 result { original_input: user_input, best_candidate: best_candidate.get(parsed_dict), best_candidate_raw: best_candidate.get(raw_text), best_candidate_score: best_candidate.get(evaluation, {}).get(overall_score), all_candidates_summary: [ { index: c.get(index), score: c.get(evaluation, {}).get(overall_score), has_error: c.get(evaluation, {}).get(has_critical_error, False) } for c in evaluated_candidates ], selection_reason: best_candidate.get(selection_reason, N/A) } # 尝试用Pydantic Schema做最终验证确保输出格式绝对正确 try: if result[best_candidate]: validated_data output_schema(**result[best_candidate]) result[validated_output] validated_data.dict() else: result[validated_output] None except Exception as e: logger.error(f最终输出验证失败: {e}) result[validation_error] str(e) result[validated_output] None logger.info(f流水线执行完毕。最佳答案得分: {result[best_candidate_score]}) return result现在我们可以在main.py中运行一个示例from pipeline import HarnessPipeline from schemas import ProductInfo import os # 配置API密钥 api_key os.getenv(OPENAI_API_KEY) pipeline HarnessPipeline( generator_modelgpt-3.5-turbo, judge_modelgpt-4, api_keyapi_key ) # 测试输入 test_input 我想买一个华为的MateBook X Pro笔记本电脑是轻薄本价格大概在8999元左右店员说现在有现货特点是3.1K触控屏和超长续航。 result pipeline.run( user_inputtest_input, output_schemaProductInfo, num_candidates3 # 演示用3个 ) print(最终输出:) print(json.dumps(result[validated_output], indent2, ensure_asciiFalse)) print(f\n选择理由: {result[selection_reason]}) print(f\n所有候选概览: {result[all_candidates_summary]})运行后你可能会得到类似这样的输出{ product_name: MateBook X Pro, brand: 华为, main_category: 笔记本电脑, price: 8999.0, key_features: [3.1K触控屏, 超长续航, 轻薄本], in_stock: true }选择理由: 综合得分最高 (4.75) 所有候选概览: [{index: 0, score: 4.5, has_error: false}, {index: 1, score: 4.75, has_error: false}, {index: 2, score: 4.25, has_error: false}]可以看到系统从3个候选答案中自动选出了评分最高4.75分的一个作为最终输出。整个过程中生成、评估、选择全部自动化完成。4. 高级优化与工程化考量基础流水线搭建完成后我们可以从多个维度对其进行增强使其更健壮、更高效、更适合生产环境。4.1 提升评估的可靠性与效率LLM as Judge的评估质量直接决定流水线的效果。我们可以通过以下方法提升它多评委投票引入多个不同的评估模型如GPT-4、Claude、DeepSeek-V2对同一候选进行评分然后取平均分或中位数可以减少单一模型的偏差和随机性。这类似于“集成学习”的思想。分步评估与链式思考将复杂的评估任务分解。例如先让一个LLM判断“格式是否正确”如果正确再交给另一个LLM判断“信息是否准确”。或者要求评估LLM必须逐步推理Chain-of-Thought并在提示词中提供几个评估示例Few-shot能显著提高评估的一致性。引入确定性规则校验对于可以程序化验证的部分绝不依赖LLM。例如在“文本转JSON”任务中我们可以先用Pydantic验证JSON格式和类型在“文本转SQL”任务中可以用一个轻量级SQL解析器检查语法甚至在一个隔离的测试数据库里执行EXPLAIN来验证其是否可运行。将规则校验与LLM评估结合形成混合评估系统。评估结果缓存对于相同的(用户输入, 候选答案)对评估结果应该是确定的。可以建立缓存机制避免重复调用昂贵的评估模型尤其是当生成器参数如温度固定时多次运行流水线可能产生相同候选。4.2 构建反馈循环与持续优化Harness的终极目标是“自优化”这意味着它应该能从每次运行中学习。收集高质量数据对每次流水线运行后将(用户输入 被选中的最佳输出)作为一个高质量的训练数据对保存下来。特别是当最佳答案的评分很高时例如4.5分这个数据对非常宝贵。提示词迭代优化定期分析失败案例。如果发现某一类错误频繁出现例如模型总是漏掉“品牌”字段可以修改生成器的系统提示词加入针对性的强调或示例。甚至可以自动化这个过程用收集到的高质量数据对作为Few-shot示例动态地构建更有效的提示词。模型微调当积累到足够多例如数千个高质量数据对时可以考虑用它们对生成器模型进行监督微调。这能让模型更直接地学习到我们期望的输入-输出映射从根本上提升其在特定任务上的表现和稳定性。对于开源模型这是非常可行的路径。评估标准进化随着业务发展评估标准可能需要调整。Harness系统应该允许动态更新评估提示词而无需修改代码。4.3 性能、成本与监控将Harness用于生产必须考虑工程现实。成本控制Harness的核心成本来自LLM API调用尤其是评估步骤。策略包括候选数N的权衡N越大找到好答案的概率越高但成本线性增加。需要通过实验找到性价比最高的N值例如对于大多数任务N3到5可能就足够了。模型选型生成器用较小/较便宜的模型评估器用较大/较贵的模型。提前淘汰在完整评估前先进行低成本过滤。例如先用规则检查JSON格式格式错误的直接淘汰不送评估。延迟优化生成和评估N个候选是顺序进行的会导致延迟增加。可以考虑并行调用生成API如果API支持来减少生成阶段的耗时。评估阶段也可以并行评估多个候选。监控与可观测性必须为流水线添加详细的日志和监控。记录每个环节的耗时、每个候选的分数分布、最终选择的原因、失败案例等。这有助于发现问题如果某天平均分突然下降可能意味着模型服务异常或提示词出了问题。分析瓶颈了解时间主要花在生成还是评估上。持续改进基于监控数据分析哪些类型的输入容易导致低分从而针对性优化。5. 常见问题、故障排查与避坑指南在实际构建和运行Harness的过程中你会遇到各种各样的问题。下面是我踩过的一些坑以及解决方案。5.1 评估器LLM as Judge本身不可靠问题表现评估分数波动大或者明显给出错误评判如对事实错误的答案打高分。排查与解决检查评估提示词确保评分标准清晰、无歧义。加入具体的评分示例Few-shot能极大提高一致性。例如“如果答案完全准确给5分有细微偏差给4分有主要错误给2分完全无关给1分。”要求“思维链”在评估提示词中明确要求模型“请逐步推理然后给出分数”。这能迫使模型进行更深入的思考而不是凭直觉打分。使用更强的模型如果用的是GPT-3.5做评估尝试升级到GPT-4或Claude 3。评估通常比生成需要更强的推理能力。多模型投票如前所述使用多个模型评估并取综合结果。人工校准定期抽样一批评估结果进行人工复核。如果发现系统性的评分偏差调整提示词或评分规则。5.2 流水线输出质量不稳定问题表现有时效果很好有时很差无法达到稳定的生产要求。排查与解决增加候选数量N这是最直接的方法。从N3增加到N5或7找到优质答案的概率会显著提升但成本和延迟也会增加。优化生成提示词生成器的提示词是源头。确保它清晰、具体并包含了输出格式的明确约束如使用JSON Schema。在提示词中加入少量高质量示例Few-shot learning效果极佳。调整温度策略不要对所有候选使用相同的温度。尝试“低温度高温度”混合策略确保既有稳健输出也有多样性探索。引入后处理对于选出的最佳答案可以增加一个“润色”或“一致性检查”步骤。例如让另一个LLM快速检查一下最终答案是否与原始输入矛盾。5.3 API调用失败与速率限制问题表现流水线运行时随机失败报错超时或额度不足。排查与解决实现健壮的重试机制使用tenacity等库对可重试的错误如网络超时、速率限制进行指数退避重试。设置合理的超时时间根据模型和任务复杂度为API调用设置合适的超时时间避免无限等待。监控使用量和成本设置每日预算和用量告警。对于评估这类高成本操作可以考虑使用缓存。使用负载均衡与多API密钥如果请求量很大可以使用多个API端点或密钥并在客户端实现简单的轮询或负载均衡。5.4 如何处理“没有合格答案”的情况问题表现所有候选答案的评估分数都很低或者都有关键错误。解决方案设置兜底策略在Selector中当所有候选都不合格时可以返回一个预定义的错误信息或者返回分数“相对最高”的那个但标记上低置信度。触发人工审核流程将低置信度的结果放入一个待审核队列由人工处理。同时这些案例是优化提示词或模型的宝贵素材。动态回退如果多次尝试均失败可以自动切换到一个更简单、更保守的生成策略例如使用温度0、更详细的提示词只生成一个答案。5.5 针对特定场景的调优技巧文本转SQL这是“幻觉”重灾区。除了上述通用流程务必加入SQL语法验证和执行计划验证。可以在一个只有Schema没有数据的测试库中执行EXPLAIN确保SQL语法正确且能有效利用索引避免产生笛卡尔积等性能炸弹。评估标准中要强调“查询结果必须与问题意图匹配”。创意写作对于写小说、营销文案等任务“准确性”可能不那么重要而“连贯性”、“创意性”、“风格符合度”更重要。需要重新设计评估维度甚至可以让多个评估器分别从不同维度打分。代码生成必须集成代码静态分析和单元测试。评估器不仅要看代码是否“看起来对”更要能通过编译和基本的测试用例。可以将代码放入沙箱执行来验证其功能。构建LLM自优化流水线是一个典型的“用魔法打败魔法”的工程实践。它承认当前LLM的不完美但通过系统化的工程方法将这种不稳定性控制在一个可接受、可管理的范围内。从简单的Best of N采样到复杂的LLM自我评估与迭代优化Harness的理念为我们提供了一条通往可靠AI应用的切实路径。记住没有一劳永逸的银弹持续地观察流水线的输出分析失败案例并迭代优化你的提示词、评估标准和流程才是让这个系统越来越强大的关键。