在实际 AI 应用开发中我们经常面临一个挑战如何确保大语言模型LLM生成的输出不仅“通顺”而且“正确”无论是生成代码、回答事实性问题还是执行复杂的推理任务LLM 都可能产生看似合理但实则错误或有害的“幻觉”内容。传统的解决方案是依赖更强大的模型或进行复杂的提示工程但这往往成本高昂且效果不稳定。DeepSeek HarnessDSH作为一个新兴的 AI 应用开发与部署平台提供了插件化的架构来扩展其核心能力。LLM-as-a-Verifier插件正是为了解决上述“幻觉”问题而生。它的核心思想是引入一个独立的“验证者”LLM对主 LLM或称为“生成者”的输出进行二次审查、验证和修正从而构建一个更可靠、更可控的生成-验证工作流。本文将带你从零开始理解LLM-as-a-Verifier插件在 DeepSeek Harness 中的工作原理并完成一个从环境准备、插件安装、配置到实际运行的完整示例。你将学会如何搭建一个简单的问答系统其中生成模型负责快速给出答案验证模型则负责检查答案的事实准确性并在发现问题时触发修正或提供警告。这种模式特别适用于对准确性要求高的场景如代码生成、数据分析和知识问答。1. 理解 LLM-as-a-Verifier 的核心机制与价值在深入代码之前我们需要先厘清几个核心概念以及为什么“生成-验证”分离的架构比单纯使用一个更强大的模型更有优势。1.1 什么是“幻觉”以及为什么需要验证LLM 的“幻觉”指的是模型生成的内容虽然语法流畅、逻辑自洽但与事实、既定规则或输入前提不符。例如让模型写一段连接数据库的代码它可能生成一个语法正确但使用了错误驱动类名或 API 的片段。在单次生成流程中模型自身很难发现这类错误。LLM-as-a-Verifier插件引入了一个独立的验证环节。这个环节可以看作是一个专注的“审查员”它的任务不是创造而是评估。审查员可以拥有与生成者不同的知识侧重、不同的提示词甚至可以是专门针对事实核查或代码安全检查进行微调的模型。这种职责分离带来了几个关键优势成本与性能的平衡你可以使用一个快速、经济的模型如较小的开源模型作为生成者负责创意和初稿同时使用一个更精确但可能更慢、更贵的模型如 GPT-4、Claude 3 或专门的事实核查模型作为验证者。这样在保证最终质量的同时控制了高频次生成的成本。可定制的验证逻辑验证者的提示词可以专门设计来检查特定类型的错误例如“检查上述回答中提到的历史日期是否准确”、“验证代码片段中是否存在已知的安全漏洞如 SQL 注入”、“判断回答是否超出了给定的上下文范围”。这种针对性是单一模型提示词难以实现的。构建安全护栏验证者可以作为内容安全过滤器检查输出是否包含偏见、有害信息或敏感数据泄露为应用增加一层可靠的安全保障。1.2 DeepSeek Harness 插件如何实现这一流程DeepSeek Harness 将 AI 工作流抽象为“管道”Pipeline管道由多个“节点”Node组成。LLM-as-a-Verifier插件本质上提供了一种特殊类型的节点或节点组合模式。一个典型的工作流如下输入用户问题或任务描述进入管道。生成节点第一个 LLM 节点生成者接收输入并生成初步答案或内容。验证节点LLM-as-a-Verifier插件节点被触发。它接收两个关键输入原始的用户输入original_input和生成者产生的初步输出draft_output。验证逻辑执行验证节点内部根据预设的验证提示词要求验证者 LLM 对draft_output进行评估。评估结果通常包括验证状态PASS通过、FAIL失败或NEEDS_REVISION需要修订。反馈/理由解释为什么通过或失败如果失败指出具体问题。修订后的输出可选如果状态是NEEDS_REVISION验证者可以尝试直接生成一个修正后的版本。管道决策根据验证状态管道决定后续动作PASS将draft_output作为最终结果返回给用户。FAIL可能丢弃结果并返回一个错误信息或要求用户重新提问。NEEDS_REVISION可以将验证者提供的修订输出作为最终结果或者将反馈送回给生成者进行第二轮生成形成一个循环。这种设计使得整个系统变得透明且可调试。你可以清晰地看到生成结果和验证反馈便于定位问题是出在生成阶段还是验证阶段。2. 环境准备与 DeepSeek Harness 基础配置在开始使用插件前你需要一个可运行的 DeepSeek Harness 环境。以下步骤将指导你完成从安装到基础项目创建的整个过程。2.1 系统与 Node.js 环境准备DeepSeek Harness 是一个基于 Node.js 的平台因此首先需要配置 Node.js 环境。为了避免不同项目间的版本冲突强烈推荐使用 Node 版本管理器NVM。1. 安装 NVM (Node Version Manager):在 Linux/macOS 上可以通过 curl 或 wget 安装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 或 wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash安装完成后重启终端或执行source ~/.bashrc或~/.zshrc使 nvm 命令生效。在 Windows 上可以使用 nvm-windows 项目提供的安装包。2. 安装并切换至推荐的 Node.js 版本DeepSeek Harness 通常对 Node.js 版本有要求请查阅其官方文档。假设要求 Node.js 18可以执行nvm install 18.19.0 # 安装一个具体的 LTS 版本如 18.19.0 nvm use 18.19.0 # 在当前 shell 中使用该版本 nvm alias default 18.19.0 # 可选设置为默认版本验证安装node --version # 应输出 v18.19.0 或类似 npm --version # 确保 npm 也已安装3. 解决常见的 Node 环境问题Error: Cannot find module node:util此错误通常意味着你的 Node.js 版本过低。node:协议导入是 Node.js v16 的特性。使用nvm install 18或更高版本即可解决。权限问题避免使用sudo安装全局 npm 包。如果遇到 EACCES 错误可以按照官方指南重新安装 Node.js或使用npm config set prefix ~/.npm-global并配置 PATH。2.2 安装与初始化 DeepSeek HarnessDeepSeek Harness 提供了命令行工具dsh来管理项目和插件。1. 全局安装 DeepSeek Harness CLInpm install -g deepseek/harness-cli安装完成后运行dsh --version确认安装成功。2. 创建你的第一个 Harness 项目mkdir my-verifier-project cd my-verifier-project dsh initdsh init命令会交互式地引导你创建项目包括选择模板、配置项目名称等。对于初学者可以选择“Basic AI Pipeline”或“Empty Project”模板。3. 项目结构初览初始化后你会看到一个类似如下的目录结构my-verifier-project/ ├── pipeline/ # 存放管道定义文件 (.yaml 或 .json) ├── plugins/ # 项目本地插件目录 ├── config/ # 配置文件如模型 API 密钥 ├── .env.example # 环境变量示例文件 ├── dsh.yaml # 项目主配置文件 └── package.json关键文件说明dsh.yaml: 定义了项目元数据、依赖的插件以及运行时配置。pipeline/: 你将在这里创建和编辑你的 AI 工作流。config/: 通常用于存放非敏感的配置敏感信息如 API Key 应通过环境变量或.env文件管理。4. 配置模型 API 密钥DeepSeek Harness 本身不提供模型你需要连接外部的 LLM API如 OpenAI、Anthropic、DeepSeek API 或本地部署的 Ollama 等。 复制环境变量示例文件并填入你的密钥cp .env.example .env # 编辑 .env 文件填入你的 API 密钥 # 例如 # OPENAI_API_KEYsk-your-openai-key-here # DEEPSEEK_API_KEYyour-deepseek-api-key-here # ANTHROPIC_API_KEYyour-claude-key-here注意永远不要将.env文件提交到版本控制系统如 Git。确保它在.gitignore中。3. 安装与配置 LLM-as-a-Verifier 插件有了基础的 Harness 项目后接下来安装并理解如何配置验证插件。3.1 安装插件DeepSeek Harness 的插件可以通过其官方市场或直接通过 Git 仓库安装。假设LLM-as-a-Verifier插件已在市场dshmarket上架你可以使用以下命令安装dsh plugin add dshmarket/llm-verifier # 或者如果插件在本地开发可以链接到本地路径 # dsh plugin link ./path/to/local/llm-verifier-plugin安装后插件代码通常会出现在项目的plugins/目录下同时dsh.yaml文件的plugins部分会被自动更新添加对该插件的引用。3.2 理解插件配置与参数安装插件后你需要在管道定义中使用它。首先让我们看看一个典型的LLM-as-a-Verifier节点在管道 YAML 文件中可能如何定义# pipeline/my_qa_pipeline.yaml name: QA with Verification nodes: - id: question_input type: input config: prompt: 请输入你的问题 - id: answer_generator type: llm # 假设 Harness 有一个基础的 LLM 节点类型 config: model: gpt-3.5-turbo # 生成者使用快速、经济的模型 system_prompt: 你是一个乐于助人的助手请准确回答用户的问题。 inputs: - from: question_input - id: fact_verifier type: llm-verifier # 使用插件提供的节点类型 config: verifier_model: gpt-4 # 验证者使用更强、更精确的模型 verification_prompt: | 你是一个事实核查员。请严格评估以下回答的准确性。 评估基于 1. 内部一致性回答是否自相矛盾 2. 事实准确性回答中提及的事实、日期、数据是否准确如果你不确定某项事实请标记为‘可能不准确’ 3. 相关性回答是否完全针对问题 原始问题{{original_input}} 待评估回答{{draft_output}} 请按以下 JSON 格式输出你的评估结果 { status: PASS | FAIL | NEEDS_REVISION, confidence: HIGH | MEDIUM | LOW, feedback: 详细的评估理由..., revised_answer: 如果状态为 NEEDS_REVISION请提供修正后的答案。否则为 null。 } criteria: - type: fact_check - type: hallucination_detection on_fail: reject # 或 revise, notify on_revision: replace # 用修订版替换原答案 inputs: - from: answer_generator as: draft_output - from: question_input as: original_input - id: final_output type: output inputs: - from: fact_verifier field: verified_output # 假设验证节点输出一个 verified_output 字段关键配置参数解析参数类型说明verifier_modelString必填。指定用于验证的 LLM 模型标识符如gpt-4,claude-3-sonnet,deepseek-chat。需要在 Harness 的模型配置中预先定义好。verification_promptString必填。这是验证环节的核心。提示词必须清晰定义验证者的角色、任务、评估标准以及输出格式。使用{{original_input}}和{{draft_output}}等占位符来接收上游节点的数据。criteriaArray可选。定义一组验证标准插件内部可能会根据这些标准结构化地调用验证模型或进行后处理。例如fact_check事实核查、safety_check安全审查、code_correctness代码正确性。on_failString当验证状态为FAIL时的行为。reject直接拒绝并可能抛出错误revise尝试让验证者修订notify仅在输出中添加警告。on_revisionString当验证状态为NEEDS_REVISION且验证者提供了修订答案时的行为。replace直接用修订答案作为输出append将修订答案和原答案一起输出。inputsArray定义该节点的输入来源。必须包含draft_output来自生成节点和original_input来自原始输入节点。3.3 配置双模型连接为了让管道中的两个 LLM 节点生成者和验证者能正常工作你需要在 Harness 中配置对应的模型连接。这通常在项目级的配置文件或环境变量中完成。1. 在config/models.yaml中配置模型端点# config/models.yaml openai: api_key: ${OPENAI_API_KEY} # 从环境变量读取 default_model: gpt-3.5-turbo openai-gpt4: api_key: ${OPENAI_API_KEY} default_model: gpt-4-turbo-preview deepseek: api_key: ${DEEPSEEK_API_KEY} default_model: deepseek-chat base_url: https://api.deepseek.com2. 在管道节点中引用配置好的模型上面示例中answer_generator节点的model: gpt-3.5-turbo以及fact_verifier节点的verifier_model: gpt-4Harness 会根据名称如openai去config/models.yaml中查找对应的配置和 API 密钥。4. 构建一个完整的问答验证管道现在我们将把以上所有部分组合起来创建一个可以实际运行的、带验证的问答管道。4.1 管道定义详解创建一个新文件pipeline/verified_qa.yaml内容如下name: Verified QA Pipeline version: 1.0 description: 一个使用 GPT-3.5 生成GPT-4 验证的问答管道。 # 定义管道需要的变量和输入输出接口 interface: input: - name: question type: string description: 用户提出的问题 output: - name: final_answer type: string - name: verification_status type: string - name: verification_feedback type: string # 节点定义 nodes: # 节点1接收用户输入 - id: user_question type: input config: variable: question # 绑定到接口的输入变量 # 节点2快速生成初始答案 (使用成本较低的模型) - id: fast_responder type: llm config: provider: openai # 引用 config/models.yaml 中的配置 model: gpt-3.5-turbo temperature: 0.7 max_tokens: 500 system_prompt: 你是一个知识渊博的助手。请用中文清晰、简洁地回答用户的问题。如果你不确定请说明。 inputs: - from: user_question field: content # 将用户问题作为 LLM 的输入内容 # 节点3使用 LLM-as-a-Verifier 插件进行事实核查 - id: fact_checker type: llm-verifier # 插件注册的节点类型 config: verifier_provider: openai-gpt4 # 使用配置好的 GPT-4 连接 verifier_model: gpt-4-turbo-preview verification_prompt: | 你是一个严格的事实核查专家。你的任务不是回答问题而是评估一个已有答案的质量。 【待核查答案】 {{draft_output}} 【原始问题】 {{original_input}} 【核查指令】 1. 事实准确性答案中的具体事实如事件、日期、人物、数据、地点是否正确如果存在明显错误或无法确认请指出。 2. 逻辑一致性答案内部是否存在矛盾答案是否完全回应了问题 3. 完整性对于复杂问题答案是否涵盖了必要的方面 4. 安全性答案是否包含有害、偏见或未经证实的信息 请以 JSON 格式输出你的评估格式如下 { status: PASS, // 可选值: PASS, NEEDS_REVISION, FAIL confidence: HIGH, // 可选值: HIGH, MEDIUM, LOW issues_found: [问题1, 问题2...], // 发现的具体问题列表若无则为空数组 corrected_facts: [修正1, 修正2...], // 对错误事实的修正建议若无则为空数组 overall_feedback: 总体评估文本... } on_fail: notify # 即使失败也继续流程但会在输出中标记 on_revision: replace # 如果有修订建议用修订版替换原答案 inputs: - from: fast_responder as: draft_output - from: user_question as: original_input # 节点4格式化最终输出 - id: output_formatter type: code # 使用一个代码执行节点来处理逻辑 config: language: javascript code: | function formatOutput(verifiedResult, originalAnswer) { const status verifiedResult.status; let finalAnswer originalAnswer; let statusMessage 验证状态: ${status}; if (status NEEDS_REVISION verifiedResult.corrected_facts verifiedResult.corrected_facts.length 0) { // 这里简化处理直接将修正建议拼接在答案后。实际可更复杂。 finalAnswer ${originalAnswer}\n\n【验证器修正提示】${verifiedResult.corrected_facts.join(; )}; statusMessage 验证状态: ${status} (已根据建议修正); } else if (status FAIL) { finalAnswer 【警告】答案未通过事实核查${verifiedResult.overall_feedback}\n原始答案仅供参考${originalAnswer}; } return { final_answer: finalAnswer, verification_status: statusMessage, verification_feedback: verifiedResult.overall_feedback || 无额外反馈 }; } // 调用函数节点会自动注入输入变量 return formatOutput($.fact_checker, $.fast_responder); inputs: - from: fact_checker - from: fast_responder # 节点5定义管道最终输出 - id: pipeline_output type: output config: final_answer: $.output_formatter.final_answer verification_status: $.output_formatter.verification_status verification_feedback: $.output_formatter.verification_feedback inputs: - from: output_formatter4.2 关键代码与逻辑解释双模型策略fast_responder使用gpt-3.5-turbo追求速度和经济性fact_checker使用gpt-4-turbo-preview追求核查的深度和准确性。这是本管道价值的核心。结构化验证提示verification_prompt是成功的关键。它明确规定了验证者的角色事实核查专家、任务评估而非创造、评估维度事实、逻辑、完整、安全以及强制性的 JSON 输出格式。结构化输出便于后续节点如output_formatter解析和处理。验证结果处理output_formatter节点一个内联 JavaScript 函数节点根据验证结果决定最终输出。这是一种常见的模式将业务逻辑放在独立的代码节点中使管道更灵活。例如如果验证失败可以选择返回原答案加警告也可以完全拒绝回答。数据流清晰通过inputs字段数据从user_question-fast_responder-fact_checker-output_formatter-pipeline_output流动。original_input也被传递到验证器这对于评估“相关性”至关重要。5. 运行、测试与结果分析5.1 启动管道服务器并运行测试1. 启动本地开发服务器在项目根目录下运行dsh serve这将启动一个本地服务器通常默认在http://localhost:3000并提供图形化界面或 API 端点来测试管道。2. 通过 API 调用管道你也可以通过 curl 命令直接测试curl -X POST http://localhost:3000/api/run/verified_qa \ -H Content-Type: application/json \ -d { question: 特斯拉汽车的创始人是谁他还在哪些公司担任CEO }3. 预期输出结构一个成功的响应体可能如下所示{ final_answer: 特斯拉汽车的创始人是埃隆·马斯克Elon Musk。他目前还担任太空探索技术公司SpaceX的CEO和总工程师以及神经科技公司Neuralink和隧道建设公司The Boring Company的CEO。, verification_status: 验证状态: PASS, verification_feedback: 答案事实准确逻辑清晰完整回答了问题的两个方面。 }如果生成者给出了一个包含事实错误的答案例如错误地将马丁·艾伯哈德说成是唯一的创始人验证器可能会返回{ final_answer: 特斯拉汽车的创始人是马丁·艾伯哈德和马克·塔彭宁埃隆·马斯克是早期投资者并后来成为CEO。他目前还担任太空探索技术公司SpaceX的CEO和总工程师以及神经科技公司Neuralink和隧道建设公司The Boring Company的CEO。\n\n【验证器修正提示】特斯拉由马丁·艾伯哈德和马克·塔彭宁于2003年创立埃隆·马斯克于2004年加入并领导了A轮融资后成为董事长和CEO。, verification_status: 验证状态: NEEDS_REVISION (已根据建议修正), verification_feedback: 原始答案关于特斯拉创始人的信息不完整且可能产生误导。已提供修正建议。 }5.2 验证流程的日志与调试DeepSeek Harness 通常提供详细的运行日志。在运行管道时关注控制台或日志文件中的输出你可以看到每个节点的开始和结束时间。发送给生成者和验证者的具体提示词。从两个模型返回的原始响应。验证节点解析出的结构化 JSON 结果。最终输出的形成过程。这对于调试验证提示词的效果至关重要。如果验证器总是返回FAIL或无法解析 JSON你需要检查日志中的原始响应来调整提示词。6. 常见问题排查与优化策略在实际使用LLM-as-a-Verifier模式时你会遇到一些典型问题。下面列出常见问题及其排查路径。6.1 插件与管道运行问题问题现象可能原因检查与解决步骤运行管道时报错Node type ‘llm-verifier’ not found1. 插件未正确安装。2. 插件未在dsh.yaml中注册。3. 节点类型名称写错。1. 运行dsh plugin list确认插件已安装。2. 检查dsh.yaml的plugins部分是否包含该插件。3. 运行dsh plugin info plugin-name查看插件提供的准确节点类型名。验证节点返回FAIL状态但看起来答案没问题验证提示词过于严格或模糊导致验证模型“过度批判”。1. 查看验证模型的原始输出日志分析其给出的feedback。2. 调整verification_prompt使评估标准更具体、客观。例如将“答案是否准确”改为“答案中是否有与公认事实相悖的陈述”。3. 在criteria中设置阈值例如只对“高置信度”的错误才标记为FAIL。验证节点输出不是预期的 JSON 格式导致后续节点解析失败验证模型的输出未严格遵循提示词中规定的 JSON 格式。1. 在verification_prompt中强化格式要求使用“你必须输出纯 JSON不要有任何额外解释”等指令。2. 在验证节点后添加一个code节点用于尝试解析 JSON如果失败则返回一个兜底的默认结构或优雅的错误信息。管道运行速度很慢1. 验证模型如 GPT-4本身响应慢。2. 网络延迟高。3. 提示词过长导致处理时间增加。1. 考虑对不那么关键的任务使用更快的验证模型如 Claude Haiku。2. 优化提示词去除冗余指令保持简洁。3. 为管道设置超时时间并考虑异步或批处理调用。6.2 验证效果与成本优化验证器也产生幻觉怎么办问题验证模型本身也可能犯错比如误判正确信息为错误。策略引入“多数决”或“分层验证”。例如用两个不同的验证模型如 GPT-4 和 Claude同时验证只有两者都认为失败时才标记为FAIL。或者先让验证器指出具体可疑点再让第三个模型做仲裁。如何控制 API 调用成本策略并非所有回答都需要验证。可以在生成节点后添加一个“过滤节点”根据某些规则如答案长度、包含特定关键词、生成模型的置信度分数决定是否跳过验证。例如对于“你好”这样的简单问候可以直接返回不触发昂贵的 GPT-4 验证。验证提示词如何设计得更有效原则具体、可操作、结构化。反面教材“检查这个答案好不好。”过于模糊正面教材“检查答案中是否包含以下任何一项1. 2020年之后发生的具体事件需提供日期。2. 引用某个研究或数据需提供来源名称或大致年份。3. 对人物性格或动机的明确断言。如果包含请评估其可信度并标记。”6.3 生产环境部署考量当这个管道从开发环境走向生产环境时还需要考虑以下几点错误处理与降级在output_formatter或管道层面添加全面的 try-catch。如果验证器 API 调用失败应有降级策略例如直接返回生成者的答案并附加“未经核查”的标签同时记录错误告警。速率限制与重试在config/models.yaml中为 OpenAI 等供应商配置合理的重试逻辑和退避策略以应对 API 的速率限制。监控与可观测性记录关键指标生成与验证的耗时、验证通过率PASS/FAIL/REVISION的比例、各模型 token 消耗量。这有助于优化成本和提示词。敏感信息过滤在最终输出前添加一个内容安全过滤节点扫描并过滤掉可能意外泄露的 API 密钥、内部 IP 等敏感信息。7. 扩展方向与最佳实践LLM-as-a-Verifier模式可以扩展到许多有趣的方向代码生成与安全检查生成者写代码验证者运行静态分析工具通过插件集成、检查安全漏洞如使用 Semgrep 规则或执行单元测试。多轮对话一致性检查在聊天机器人中验证者可以检查当前回复是否与历史对话矛盾。基于知识库的验证验证提示词中可以包含从向量数据库检索出的相关文档片段要求验证者判断答案是否与提供文档一致。多专家投票部署多个具有不同专长的验证者如一个检查事实一个检查逻辑一个检查语气综合它们的判断做出最终决策。最佳实践清单从简单开始先让生成-验证流程跑通再逐步复杂化验证逻辑。提示词迭代验证提示词需要像生成提示词一样精心设计和反复测试。使用真实且多样的测试用例进行评估。成本监控验证步骤会显著增加每次调用的成本和延迟。明确业务场景对准确性的要求是否值得这份开销。人机回环对于验证结果为FAIL或低置信度NEEDS_REVISION的高风险内容设计流程将其转入人工审核队列而不是自动处理。评估指标定义清晰的评估指标来衡量验证插件的价值例如“幻觉率降低百分比”、“用户负面反馈减少量”等。通过将LLM-as-a-Verifier插件集成到你的 DeepSeek Harness 工作流中你不仅仅是增加了一个步骤而是引入了一个可审查、可调试、可优化的质量控制层。这种模式承认了当前 LLM 的局限性并通过架构设计来系统性缓解它是构建可靠 AI 应用的重要一步。