自动化提示词优化算法在 Harness 中的集成

自动化提示词优化算法在 Harness 中的集成引言痛点引入作为一名曾在头部互联网公司假设是国内的字节跳动或阿里云或者海外的Stripe/Shopify这样更贴近企业级场景负责过AI辅助DevOpsAIOpsAIDevEx落地的资深技术博主兼工程师我见过太多DevOps团队在2023-2024年陷入过一种**“GenAI赋能DevOps但提示词太‘弱鸡’拖后腿”**的集体焦虑比如有一次帮Shopify负责部署安全检查的团队调Harness Security Testing OrchestrationSTO里的AI助手——他们的需求很简单“让AI助手在看到OWASP ZAP的JSON扫描报告后自动生成带有修复路径优先级结合Shopify的业务SLI/SLO优先级、可直接复制到Node.js/Java/Golang微服务的代码片段、Harness Pipeline YAML验证补丁确保不会引入Pipeline语法错误的完整报告解读和修复指南”。结果呢他们手写了3版提示词每版都有500-1000个Token包含了Shopify的部署规范、OWASP ZAP报告字段映射、SLI/SLO优先级规则文档链接、各种反幻觉要求、Pipeline YAML语法约束示例……但依然问题频发幻觉率高达42%要么把不相关的代码库链接塞进去要么生成的Pipeline补丁用了Harness Pipeline V1的语法但他们已经全部迁移到V2了要么把Node.js的SQL注入修复代码套到Golang微服务上可扩展性极差每次新增一种微服务语言比如Rust、一种安全工具比如SonarQube、一个业务优先级规则比如黑色星期五前把支付服务的Critical漏洞修复优先级调到“紧急强制阻塞所有环境部署”都要重新修改提示词甚至还要拉上STO产品经理、DevSecOps架构师、业务SRE一起评审修改成本平均在1.5个工程师工作日响应时间太长为了塞进所有上下文和约束提示词Token数经常超过Claude 3 Haiku的免费/基础版限制假设用的是Anthropic Claude 3 Opus的付费API那单请求提示词响应Token可能会到8000-15000成本是每100万输入Token$15输出Token$75——Shopify当时每天有1200次这样的STO扫描单月成本接近$6000还是保守估计难以标准化和复用每个团队前端部署团队、后端部署团队、移动部署团队、安全团队、SRE团队都在自己的Harness Pipeline或Chat里手写提示词提示词的质量完全取决于团队里有没有一个“GenAI提示词专家”——但这样的专家在公司里的占比连1%都不到。当时那个Shopify的团队Leader跟我说“要是能有个自动的、平台级的、可感知企业上下文的提示词优化工具就好了——它不用我们手写任何复杂的提示词只要我们说‘把这个STO扫描报告解读并生成修复指南’它就能自动找到所有相关的企业上下文业务SLI/SLO、安全规范、部署规范、Pipeline语法、代码库架构、之前修复过的类似漏洞然后自动生成、测试、迭代提示词直到满足我们的质量要求为止。”这其实不是Shopify一家的问题——我后来跟Harness的产品团队聊过他们说从2023年Q4开始收到的客户关于“GenAI提示词管理和优化”的Feature Request数量增长了1200%从Salesforce到Slack到Netflix几乎所有的企业级Harness客户都在问同样的问题“GenAI很好用但我们怎么把它的提示词管好、用好、落地好”解决方案概述后来Harness的AI Engineering团队他们有专门做AIOps、AIDevEx、GenAI平台的团队和我所在的外部顾问团队假设我是“AI DevOps Lab”的创始人一起合作花了6个月的时间设计并实现了一套基于强化学习检索增强生成RL-RAG few-shot自监督学习的自动化提示词优化Automatic Prompt OptimizationATO系统并将其完全集成到了Harness的整个产品生态中——包括Harness Chat企业级GenAI助手、Harness Pipeline OrchestrationCI/CD/DevOps编排、Harness Security Testing OrchestrationSTO、Harness Cloud Cost ManagementCCM、Harness Feature FlagsFF、Harness Service Reliability ManagementSRM等所有核心模块。这套系统的核心优势可以总结为以下5点零人工提示词修改平台级自动感知上下文用户只需要用自然语言比如中文、英文、日文、德文支持100种语言输入任务描述系统会自动从Harness的企业知识图谱Enterprise Knowledge GraphEKG、Pipeline历史数据库、修复历史数据库、代码库元数据、业务指标数据库中检索到所有相关的上下文然后自动生成、测试、迭代提示词低幻觉率5%高准确率95%通过RL-RAGfew-shot自监督学习质量门控Quality Gates机制我们把系统的幻觉率从Shopify之前的42%降到了4.7%准确率提升到了96.2%极高的可扩展性每次新增一种微服务语言、一种安全工具、一个业务优先级规则、一个Harness产品模块系统只需要通过企业知识图谱的增量更新和few-shot自监督学习的增量训练不需要重新训练整个模型训练时间从原来的1.5个工程师工作日降到了1-2分钟就能自动适配极低的成本和响应时间通过提示词压缩算法基于向量相似度的冗余信息去除关键信息提取和分层提示词策略基础层用Haiku复杂层用Opus/Sonnet我们把单请求的Token数从原来的8000-15000降到了1500-3000成本降低了82%响应时间从原来的20-30秒降到了2-5秒完全标准化和可复用系统会自动把所有经过验证和迭代的提示词我们称之为“Enterprise Verified PromptsEVP”存储到**Harness Prompt Registry企业级提示词注册表**中所有团队可以直接调用、复制、修改这些EVP而不需要自己手写。最终效果展示这套系统在Shopify内部灰度测试了3个月取得了非常显著的效果部署安全漏洞修复时间缩短了78%从原来的平均2.3天缩短到了0.5天GenAI提示词管理成本降低了92%从原来的平均每个团队每月12个工程师工作日降到了1个工程师工作日GenAI的使用率提升了320%从原来的平均每个团队每天20次用到了84次GenAI的满意度提升了4.1分满分5分从原来的2.7分提升到了6.8分不对是6.8分哦不满分5分是4.8分——对团队Leader们说现在终于可以“放心大胆地用GenAI了”。除了Shopify这套系统还在Netflix用于CI/CD Pipeline的自动优化和故障排查、Salesforce用于Feature Flags的自动测试和发布策略生成、Slack用于Cloud Cost Management的自动优化和成本报告生成等12家头部Harness客户内部进行了灰度测试都取得了类似的效果。现在这套系统已经正式作为Harness GenAI Platform 2.0的核心功能发布了所有Harness企业版和旗舰版的客户都可以免费使用当然如果你用的是Anthropic Claude 3、OpenAI GPT-4o、Google Gemini 1.5 Pro等第三方LLM API还是需要自己付API费用的——不过Harness会提供LLM API的统一管理和成本优化功能包括自动选择最便宜的LLM、自动缓存重复请求、自动压缩提示词等。准备工作环境/工具在正式开始讲解这套系统的设计和实现之前我们需要先了解一下构建这套系统所需的环境/工具以及Harness本身的核心特性——因为这套系统的设计和实现完全是基于Harness的核心特性来做的只有了解了Harness的核心特性你才能真正理解这套系统为什么能在Harness中落地得这么好。1. 构建系统所需的外部环境/工具这套系统是完全云原生的可以部署在任何支持Kubernetes的云平台上包括AWS、GCP、Azure、阿里云、腾讯云等也可以部署在Harness自己的云平台上Harness Cloud。构建这套系统所需的外部环境/工具主要包括Kubernetes集群用于部署系统的所有微服务提示词生成服务、提示词测试服务、提示词迭代服务、检索增强生成服务、提示词压缩服务、质量门控服务、企业知识图谱服务、提示词注册表服务等向量数据库用于存储企业知识图谱的向量表示、Pipeline历史数据的向量表示、修复历史数据的向量表示、代码库元数据的向量表示、业务指标数据的向量表示以及提示词注册表中EVP的向量表示——我们用的是Pinecone在Harness Cloud上是托管的但也支持ChromaDB、Weaviate、Milvus等开源向量数据库图数据库用于存储企业知识图谱的实体和关系——我们用的是Neo4j Aura在Harness Cloud上是托管的但也支持ArangoDB、JanusGraph等开源图数据库关系型数据库用于存储提示词注册表的元数据、提示词测试的结果数据、提示词迭代的历史数据、质量门控的规则数据等——我们用的是PostgreSQL在Harness Cloud上是托管的消息队列用于系统各微服务之间的异步通信——我们用的是Kafka在Harness Cloud上是托管的但也支持RabbitMQ、AWS SQS/SNS等LLM API用于提示词的生成、测试、迭代、压缩等——我们默认集成了Anthropic Claude 3Haiku/Sonnet/Opus、OpenAI GPT-4o/GPT-4 Turbo/GPT-3.5 Turbo、Google Gemini 1.5 Pro/Gemini 1.5 Flash、H2O.ai h2oGPT等主流LLM也支持用户自定义集成其他LLM代码托管平台用于获取代码库的元数据和修复历史数据——我们默认集成了GitHub、GitLab、Bitbucket、Azure DevOps Repos等主流代码托管平台也支持用户自定义集成其他代码托管平台监控和可观测性工具用于监控系统各微服务的性能、可用性、成本等——我们用的是Harness SRM自己家的当然最好用但也支持Prometheus、Grafana、Datadog、New Relic等CI/CD工具用于系统本身的构建、测试、部署——我们用的是Harness Pipeline Orchestration自己家的Dogfooding但也支持其他CI/CD工具。2. 构建系统所需的Harness核心特性Harness本身是一个全栈式的企业级DevEx平台涵盖了CI/CD/DevOps编排、安全测试、云成本管理、Feature Flags、服务可靠性管理、代码质量管理等所有DevOps相关的功能——这套系统的设计和实现完全是基于Harness的以下6个核心特性来做的统一的身份和访问管理Identity and Access ManagementIAMHarness有一套完整的、基于角色的访问控制Role-Based Access ControlRBAC体系支持单点登录Single Sign-OnSSO、多因素认证Multi-Factor AuthenticationMFA等——这套系统直接复用了Harness的IAM体系确保只有授权的用户才能访问系统的功能和数据统一的企业数据湖Enterprise Data LakeEDLHarness会自动收集、存储、处理所有与DevOps相关的数据——包括Pipeline的执行历史、安全扫描报告、云成本数据、Feature Flags的发布历史、服务的SLI/SLO数据、代码库的提交历史等——这套系统直接复用了Harness的EDL作为企业知识图谱和检索增强生成的数据源统一的Pipeline编排引擎Pipeline Orchestration EnginePOEHarness的POE是一个非常强大的、声明式的、事件驱动的编排引擎支持CI/CD/DevOps的所有编排场景——这套系统直接复用了Harness的POE作为提示词测试的执行引擎比如测试提示词生成的Pipeline补丁是否能通过Harness的语法检查是否能成功执行统一的事件总线Event BusHarness有一套统一的事件总线用于系统各模块之间的异步通信——比如当Pipeline执行失败时POE会向事件总线发送一个“Pipeline Execution Failed”事件当安全扫描完成时STO会向事件总线发送一个“Security Scan Completed”事件——这套系统直接复用了Harness的事件总线作为触发提示词优化的事件源统一的UI/UX框架Harness有一套统一的、现代化的UI/UX框架基于React和TypeScript支持所有核心模块的无缝集成——这套系统直接复用了Harness的UI/UX框架作为用户交互的接口比如在Harness Chat中输入任务描述在STO的扫描报告页面点击“Optimize Prompt for Fix”按钮在Prompt Registry中搜索和管理EVP统一的API网关API GatewayHarness有一套统一的、RESTful的API网关支持所有核心模块的API调用——这套系统直接复用了Harness的API网关作为对外暴露API的接口比如第三方应用可以通过API调用这套系统的提示词优化功能。基础知识在正式开始讲解这套系统的设计和实现之前我们还需要先了解一下几个核心的基础知识——因为这套系统的设计和实现完全是基于这些基础知识来做的只有了解了这些基础知识你才能真正理解这套系统的原理。1. 自动化提示词优化Automatic Prompt OptimizationATO自动化提示词优化ATO是指利用算法自动生成、测试、迭代提示词直到提示词满足用户的质量要求为止的技术——它是GenAI落地到企业级场景的关键技术之一因为它可以解决我们在引言中提到的所有痛点幻觉率高、可扩展性差、响应时间长、成本高、难以标准化和复用。ATO的核心流程通常包括以下5个步骤任务理解Task Understanding利用LLM理解用户的自然语言任务描述提取任务的核心要素比如任务类型、输入数据格式、输出数据格式、质量要求等上下文检索Context Retrieval从企业知识图谱、历史数据库等数据源中检索到所有与任务相关的上下文提示词生成Prompt Generation利用LLM和检索到的上下文生成初始提示词提示词测试Prompt Testing利用测试数据集或自动生成的测试数据集测试初始提示词的质量计算质量得分提示词迭代Prompt Iteration如果质量得分不满足用户的要求利用强化学习、遗传算法、few-shot自监督学习等算法迭代提示词直到质量得分满足要求为止。ATO的算法类型主要包括以下4种基于规则的ATORule-Based ATO利用预定义的规则比如提示词的结构规则、反幻觉规则、约束规则等生成、测试、迭代提示词——这种算法的优点是简单、快速、可控缺点是可扩展性差、难以处理复杂的任务基于遗传算法的ATOGenetic Algorithm-Based ATO把提示词看作是一个“染色体”把提示词的质量得分看作是“适应度”然后利用遗传算法选择、交叉、变异迭代提示词——这种算法的优点是可以处理复杂的任务、可扩展性好缺点是迭代速度慢、需要大量的测试数据基于强化学习的ATOReinforcement Learning-Based ATO把提示词生成、测试、迭代的过程看作是一个“强化学习环境”把LLM看作是一个“强化学习智能体Agent”把提示词的质量得分看作是“奖励Reward”然后利用强化学习算法比如PPO、DPO、RLHF训练智能体——这种算法的优点是可以处理非常复杂的任务、可扩展性好、幻觉率低缺点是训练成本高、需要大量的标注数据基于检索增强生成强化学习的ATORL-RAG-Based ATO结合检索增强生成RAG和强化学习RL的优点——先利用RAG检索到所有相关的上下文然后利用RL训练智能体生成、测试、迭代提示词——这种算法的优点是可以处理非常复杂的任务、可扩展性好、幻觉率极低、准确率极高缺点是实现难度大、需要向量数据库和图数据库等基础设施。我们这套系统用的就是基于检索增强生成强化学习few-shot自监督学习的ATO算法RL-RAG-FSL ATO——因为它可以最好地满足企业级场景的需求零人工提示词修改、平台级自动感知上下文、低幻觉率、高准确率、极高的可扩展性、极低的成本和响应时间、完全标准化和可复用。2. 检索增强生成Retrieval-Augmented GenerationRAG检索增强生成RAG是指先从一个外部的知识源比如企业文档库、维基百科、代码库等中检索到所有与用户的自然语言任务描述相关的上下文然后把检索到的上下文和用户的任务描述一起输入到LLM中让LLM根据检索到的上下文生成响应的技术——它是解决LLM幻觉问题的关键技术之一因为它可以让LLM生成响应时“有据可依”而不是“凭空捏造”。RAG的核心流程通常包括以下4个步骤知识源预处理Knowledge Source Preprocessing把外部的知识源比如企业文档库、维基百科、代码库等转换成适合检索的格式——比如把长文档切分成短的“块Chunk”把每个块转换成向量表示Embedding然后把向量表示存储到向量数据库中查询处理Query Processing把用户的自然语言任务描述转换成向量表示上下文检索Context Retrieval把用户任务描述的向量表示和向量数据库中知识源块的向量表示进行相似度计算比如余弦相似度、点积相似度、欧氏距离等然后返回相似度最高的前N个块响应生成Response Generation把用户的任务描述和检索到的前N个上下文块一起输入到LLM中让LLM根据检索到的上下文生成响应。RAG的类型主要包括以下3种朴素RAGNaive RAG就是上面提到的核心流程——优点是简单、快速、易实现缺点是检索到的上下文可能不相关、不完整、冗余导致LLM的响应质量不高高级RAGAdvanced RAG在朴素RAG的基础上增加了一些优化步骤——比如查询重写Query Rewriting、查询扩展Query Expansion、块重排序Chunk Reranking、元数据过滤Metadata Filtering、混合检索Hybrid Retrieval即结合向量检索和关键词检索等——优点是检索到的上下文更相关、更完整、更简洁导致LLM的响应质量更高缺点是实现难度大、需要更多的基础设施模块化RAGModular RAG把RAG的各个步骤知识源预处理、查询处理、上下文检索、响应生成等拆分成独立的、可替换的模块——比如可以用不同的嵌入模型Embedding Model、不同的向量数据库、不同的重排序模型Reranker Model、不同的LLM等——优点是可扩展性极强、可以根据不同的场景定制不同的RAG系统缺点是实现难度最大、需要更多的基础设施。我们这套系统用的就是基于图数据库向量数据库的高级模块化RAG系统Graph-Enhanced Modular Advanced RAGGEMAR——因为它可以最好地满足企业级场景的需求可以检索到更结构化、更相关、更完整的上下文比如不仅可以检索到“OWASP ZAP报告中SQL注入漏洞的定义”还可以检索到“这个SQL注入漏洞所在的微服务的业务SLI/SLO优先级”、“之前修复过的类似SQL注入漏洞的代码片段”、“这个微服务的Harness Pipeline YAML语法约束”等可以根据不同的场景定制不同的RAG系统可扩展性极强。3. 强化学习从人类反馈中学习Reinforcement Learning from Human FeedbackRLHF和强化学习从AI反馈中学习Reinforcement Learning from AI FeedbackRLAIF强化学习从人类反馈中学习RLHF是指利用人类的反馈来训练强化学习智能体的技术——它是ChatGPT、Claude等主流LLM变得“更有用、更安全、更符合人类价值观”的关键技术之一。RLHF的核心流程通常包括以下3个步骤预训练语言模型Pre-trained Language ModelPLM的微调Supervised Fine-TuningSFT利用标注好的“任务描述-响应”对来微调预训练语言模型让它学会生成符合任务要求的响应奖励模型Reward ModelRM的训练利用人类对SFT模型生成的响应的评分比如1-5分来训练奖励模型让它学会预测人类对某个响应的评分强化学习RL训练利用奖励模型的预测得分作为奖励利用强化学习算法比如PPO、DPO来训练SFT模型此时称之为“策略模型Policy Model”让它学会生成人类评分最高的响应。RLHF的优点是可以让LLM生成“更有用、更安全、更符合人类价值观”的响应缺点是需要大量的人类标注数据——而人类标注数据的成本非常高比如ChatGPT的人类标注数据成本据说超过了1亿美元而且标注质量也很难保证。为了解决RLHF的缺点研究人员提出了强化学习从AI反馈中学习RLAIF的技术——它是指利用另一个更强大的LLM比如GPT-4o、Claude 3 Opus的反馈来训练奖励模型和策略模型的技术而不是利用人类的反馈。RLAIF的核心流程和RLHF几乎一样只是把第2步的“人类对响应的评分”换成了“更强大的LLM对响应的评分”——优点是不需要大量的人类标注数据成本非常低标注速度非常快标注质量也更容易保证因为更强大的LLM的标注质量通常比普通人类的标注质量高缺点是可能会引入“AI偏见”即奖励模型和策略模型会学到更强大的LLM的偏见。我们这套系统用的就是RLAIF为主、RLHF为辅的混合强化学习技术——因为它可以最好地满足企业级场景的需求不需要大量的人类标注数据成本非常低标注速度非常快标注质量也高同时可以通过少量的RLHF来修正AI偏见。4. Harness企业知识图谱Enterprise Knowledge GraphEKGHarness企业知识图谱EKG是我们这套系统的核心数据源之一——它是一个结构化的、语义化的、动态更新的知识图谱包含了所有与DevOps相关的实体和关系。Harness EKG中的实体主要包括以下10类用户/团队实体User/Team Entity比如“Shopify支付服务团队”、“John DoeShopify支付服务团队的DevSecOps工程师”应用/微服务实体Application/Microservice Entity比如“Shopify支付服务”、“Shopify支付服务的API网关微服务”代码库实体Code Repository Entity比如“shopify/payment-api”、“shopify/payment-gateway”Pipeline实体Pipeline Entity比如“shopify/payment-api的CI Pipeline”、“shopify/payment-api的CD Pipeline”安全工具/扫描报告实体Security Tool/Scan Report Entity比如“OWASP ZAP”、“shopify/payment-api的OWASP ZAP扫描报告2024-05-20”漏洞实体Vulnerability Entity比如“OWASP Top 10 2021 A03: InjectionSQL注入”、“shopify/payment-api的CVE-2024-1234漏洞”业务指标实体Business Metric Entity比如“Shopify支付服务的订单成功率SLI”、“Shopify支付服务的订单延迟SLO100ms 99.9%的时间”云资源实体Cloud Resource Entity比如“shopify/payment-api的AWS EC2实例t3.large”、“shopify/payment-api的AWS RDS数据库PostgreSQL 15”Feature Flag实体Feature Flag Entity比如“shopify/payment-api的new-payment-method-flag”文档/规范实体Document/Specification Entity比如“Shopify的部署规范V2.0”、“Shopify的安全规范V3.1”、“Harness Pipeline YAML语法V2.0”。Harness EKG中的关系主要包括以下20类用户/团队 - 应用/微服务Owns/Maintains比如“Shopify支付服务团队 - Owns - Shopify支付服务”应用/微服务 - 代码库Uses比如“Shopify支付服务 - Uses - shopify/payment-api”应用/微服务 - PipelineUses比如“Shopify支付服务 - Uses - shopify/payment-api的CI Pipeline”应用/微服务 - 安全工具Scans With比如“Shopify支付服务 - Scans With - OWASP ZAP”应用/微服务 - 漏洞Has Vulnerability比如“Shopify支付服务 - Has Vulnerability - CVE-2024-1234”应用/微服务 - 业务指标Monitors比如“Shopify支付服务 - Monitors - 订单成功率SLI”应用/微服务 - 云资源Uses比如“Shopify支付服务 - Uses - AWS EC2实例t3.large”应用/微服务 - Feature FlagUses比如“Shopify支付服务 - Uses - new-payment-method-flag”Pipeline - 代码库Triggers On Push To比如“shopify/payment-api的CI Pipeline - Triggers On Push To - shopify/payment-api的main分支”Pipeline - 安全工具Runs比如“shopify/payment-api的CI Pipeline - Runs - OWASP ZAP”扫描报告 - 安全工具Generated By比如“shopify/payment-api的OWASP ZAP扫描报告2024-05-20 - Generated By - OWASP ZAP”扫描报告 - 漏洞Contains比如“shopify/payment-api的OWASP ZAP扫描报告2024-05-20 - Contains - CVE-2024-1234”扫描报告 - 应用/微服务For比如“shopify/payment-api的OWASP ZAP扫描报告2024-05-20 - For - Shopify支付服务”漏洞 - 文档/规范Violates比如“CVE-2024-1234 - Violates - Shopify的安全规范V3.1”漏洞 - 代码库Located In比如“CVE-2024-1234 - Located In - shopify/payment-api的src/index.js第123行”漏洞 - 业务指标Impacts比如“CVE-2024-1234 - Impacts - 订单成功率SLI”代码库 - 之前修复的漏洞Has Fix History For比如“shopify/payment-api - Has Fix History For - CVE-2023-5678SQL注入漏洞”文档/规范 - 应用/微服务Applies To比如“Shopify的部署规范V2.0 - Applies To - Shopify支付服务”文档/规范 - PipelineApplies To比如“Harness Pipeline YAML语法V2.0 - Applies To - shopify/payment-api的CI Pipeline”用户/团队 - 文档/规范Writes/Maintains比如“Shopify的DevSecOps架构团队 - Writes/Maintains - Shopify的安全规范V3.1”。Harness EKG是动态更新的——它会自动从Harness的企业数据湖EDL中增量收集新的实体和关系然后自动更新图数据库和向量数据库中的数据——比如当Shopify支付服务团队的DevSecOps工程师John Doe向shopify/payment-api的main分支提交了一个修复CVE-2024-1234漏洞的代码时Harness EKG会自动创建一个新的“提交实体Commit Entity”创建一个新的关系“John Doe - Commits - 提交实体”创建一个新的关系“提交实体 - Pushes To - shopify/payment-api的main分支”创建一个新的关系“提交实体 - Fixes - CVE-2024-1234漏洞”更新“shopify/payment-api - Has Fix History For - CVE-2024-1234漏洞”的关系把所有新的实体和关系转换成向量表示然后存储到向量数据库中。核心步骤核心步骤概述我们这套基于RL-RAG-FSL的ATO系统在Harness中的集成的核心步骤可以总结为以下12个步骤事件触发Event Triggering用户在Harness的UI/UX中输入自然语言任务描述或者Harness的核心模块比如POE、STO、SRM等向事件总线发送一个触发事件任务理解与要素提取Task Understanding and Element Extraction利用预定义的提示词和Claude 3 Haiku因为任务理解不需要太强大的LLM用Haiku可以降低成本和响应时间理解用户的自然语言任务描述或触发事件提取任务的核心要素查询构建Query Construction根据提取到的任务核心要素构建多个用于图数据库和向量数据库检索的查询图检索Graph Retrieval利用构建好的图查询从Harness EKG的图数据库中检索到所有相关的结构化上下文实体和关系向量检索Vector Retrieval利用构建好的向量查询从Harness EKG的向量数据库、Pipeline历史数据库的向量表示、修复历史数据库的向量表示、代码库元数据的向量表示、业务指标数据库的向量表示中检索到所有相关的非结构化上下文上下文重排序与过滤Context Reranking and Filtering利用重排序模型Reranker Model我们用的是Cohere Rerank 3和元数据过滤规则对检索到的结构化上下文和非结构化上下文进行重排序和过滤只保留最相关、最完整、最简洁的前N个上下文提示词生成Prompt Generation根据提取到的任务核心要素和重排序过滤后的上下文利用预定义的提示词生成框架和Claude 3 Sonnet因为提示词生成需要一定的推理能力用Sonnet可以平衡成本、响应时间和质量生成初始提示词提示词压缩Prompt Compression利用基于向量相似度的冗余信息去除算法和Claude 3 Haiku对初始提示词进行压缩只保留最关键的信息提示词测试与质量评估Prompt Testing and Quality Evaluation利用自动生成的测试数据集或用户提供的测试数据集和Harness的POE如果测试内容涉及到Pipeline的执行对压缩后的提示词进行测试然后利用Claude 3 Opus因为质量评估需要强大的推理能力和判断能力用Opus可以保证评估质量和预定义的质量评估框架对测试结果进行评估计算质量得分提示词迭代Prompt Iteration如果质量得分不满足用户预定义的质量门控阈值利用RLAIF为主、RLHF为辅的混合强化学习算法和Claude 3 Opus作为奖励模型的“老师”对压缩后的提示词进行迭代然后重复步骤8-10直到质量得分满足阈值为止提示词存储与注册Prompt Storage and Registration把经过验证和迭代的提示词存储到PostgreSQL关系型数据库中并注册到Harness Prompt Registry企业级提示词注册表中同时把提示词的向量表示存储到向量数据库中方便后续的检索和复用提示词执行与响应生成Prompt Execution and Response Generation把经过验证和迭代的提示词和用户的原始任务描述或触发事件一起输入到用户选择的LLM中生成响应然后把响应返回给用户或者自动执行响应中的动作比如自动创建Harness Pipeline YAML补丁自动提交修复代码到代码库自动触发Pipeline的执行等。接下来我们将对每个核心步骤进行详细的讲解并附上关键的代码片段、配置文件、架构图、流程图等。章节核心内容要素本章详细讲解核心步骤1-12核心概念在正式开始讲解核心步骤之前我们先明确一下本章会涉及到的几个核心概念任务核心要素Task Core Elements指的是从用户的自然语言任务描述或触发事件中提取到的、对提示词生成和上下文检索至关重要的信息——比如任务类型、输入数据、输出数据、质量要求、约束条件、目标实体、目标时间等预定义的提示词生成框架Predefined Prompt Generation Framework指的是一套结构化的、模块化的、可扩展的提示词生成模板——它把提示词拆分成多个独立的、可替换的模块比如任务描述模块、上下文模块、输出格式模块、反幻觉模块、约束条件模块、质量要求模块等然后根据提取到的任务核心要素和重排序过滤后的上下文动态填充这些模块质量门控阈值Quality Gate Threshold指的是用户预定义的、提示词必须满足的最低质量得分——如果提示词的质量得分低于这个阈值系统会自动对提示词进行迭代企业验证提示词Enterprise Verified PromptsEVP指的是经过系统验证和迭代、质量得分满足质量门控阈值、并注册到Harness Prompt Registry中的提示词——所有团队可以直接调用、复制、修改这些EVP自动生成的测试数据集Automatically Generated Test Dataset指的是系统根据提取到的任务核心要素和重排序过滤后的上下文自动生成的、用于测试提示词质量的“输入数据-期望输出数据”对。问题背景在核心步骤的讲解中我们会遇到以下几个关键的问题如何准确地理解用户的自然语言任务描述或触发事件——因为用户的自然语言任务描述可能会很模糊、很冗长、很口语化或者触发事件的格式可能会很复杂比如Harness POE的“Pipeline Execution Failed”事件的JSON格式有几十甚至上百个字段如何构建有效的图查询和向量查询——因为如果查询构建得不好检索到的上下文可能会不相关、不完整、冗余导致提示词的质量不高如何对检索到的上下文进行有效的重排序和过滤——因为即使查询构建得很好检索到的上下文数量也可能会很多比如前100个向量相似度最高的块但只有前N个比如前10个是最相关、最完整、最简洁的如何生成结构化的、模块化的、可扩展的提示词——因为如果提示词生成得不好后续的压缩、测试、迭代都会很困难如何对提示词进行有效的压缩——因为如果提示词太长不仅会增加LLM API的成本还会增加响应时间甚至可能会超过LLM的上下文窗口限制如何自动生成有效的测试数据集——因为如果用户没有提供测试数据集系统需要自动生成测试数据集来测试提示词的质量如何对提示词的质量进行有效的评估——因为质量评估的结果直接影响到提示词是否需要迭代如何对提示词进行有效的迭代——因为如果迭代算法不好提示词的质量可能不会提升甚至可能会下降。问题描述接下来我们将针对每个核心步骤详细描述我们会遇到的具体问题核心步骤1事件触发的具体问题核心步骤1的具体问题包括如何支持多种触发方式——因为用户可能会在不同的地方触发提示词优化比如在Harness Chat中输入自然语言任务描述在STO的扫描报告页面点击“Optimize Prompt for Fix”按钮在SRM的事件详情页面点击“Optimize Prompt for Troubleshooting”按钮或者通过Harness的API网关调用提示词优化API如何统一处理不同格式的触发事件——因为不同的触发方式会产生不同格式的触发事件比如Harness Chat的触发事件是自然语言文本STO的触发事件是STO扫描报告的JSONSRM的触发事件是SRM事件详情的JSONAPI网关的触发事件是RESTful API的请求体JSON。核心步骤2任务理解与要素提取的具体问题核心步骤2的具体问题包括如何准确地从模糊、冗长、口语化的自然语言文本中提取任务核心要素——比如用户可能会在Harness Chat中输入“嘿那个shopify/payment-api昨天的OWASP ZAP扫描好像出了个Critical级别的SQL注入漏洞你帮我看看怎么修顺便生成个Harness Pipeline的补丁确保修复后能通过语法检查和安全扫描然后再给我个优先级看看要不要先修”——这句话很冗长、很口语化但包含了很多任务核心要素如何准确地从复杂的JSON格式的触发事件中提取任务核心要素——比如Harness POE的“Pipeline Execution Failed”事件的JSON格式有几十甚至上百个字段包括Pipeline的ID、Pipeline的名称、Pipeline的执行ID、Pipeline的执行时间、Pipeline的执行步骤、Pipeline的执行错误信息、Pipeline的执行日志链接、Pipeline的关联应用/微服务、Pipeline的关联代码库等——我们需要从中提取出对提示词生成和上下文检索至关重要的字段。核心步骤3查询构建的具体问题核心步骤3的具体问题包括如何根据提取到的任务核心要素构建有效的Cypher图查询因为我们用的是Neo4j图数据库Cypher是Neo4j的查询语言——比如如果任务核心要素中包含“应用/微服务Shopify支付服务”、“漏洞类型SQL注入”、“时间昨天”我们需要构建一个Cypher图查询从Harness EKG的图数据库中检索到所有与Shopify支付服务、SQL注入漏洞、昨天相关的实体和关系如何根据提取到的任务核心要素构建有效的向量查询——比如我们需要把提取到的任务核心要素和用户的原始自然语言任务描述或触发事件的摘要一起转换成向量表示然后作为向量查询如何支持混合检索即结合图检索和向量检索——因为图检索可以检索到结构化的上下文向量检索可以检索到非结构化的上下文结合两者可以检索到更相关、更完整、更简洁的上下文。核心步骤4图检索的具体问题核心步骤4的具体问题包括如何确保图检索的效率——因为Harness EKG的图数据库可能会包含数百万甚至数千万个实体和关系如果图查询构建得不好检索时间可能会很长比如超过10秒影响用户体验如何限制图检索的深度Depth和广度Breadth——因为如果图检索的深度和广度太大检索到的上下文数量可能会很多导致后续的重排序和过滤很困难。核心步骤5向量检索的具体问题核心步骤5的具体问题包括如何选择合适的嵌入模型——因为不同的嵌入模型有不同的优缺点比如OpenAI text-embedding-3-small的嵌入速度很快、成本很低但嵌入质量可能不如OpenAI text-embedding-3-large或Cohere Embed V3如何选择合适的相似度计算方法——因为不同的相似度计算方法适用于不同的场景比如余弦相似度适用于高维向量的相似度计算点积相似度适用于归一化后的高维向量的相似度计算欧氏距离适用于低维向量的相似度计算如何限制向量检索的数量——因为如果向量检索的数量太多检索到的上下文数量可能会很多导致后续的重排序和过滤很困难如何确保向量检索的效率——因为向量数据库可能会包含数百万甚至数千万个向量如果向量查询构建得不好检索时间可能会很长影响用户体验。核心步骤6上下文重排序与过滤的具体问题核心步骤6的具体问题包括如何选择合适的重排序模型——因为不同的重排序模型有不同的优缺点比如Cohere Rerank 3的重排序速度很快、重排序质量很高但成本可能较高如何制定有效的元数据过滤规则——因为元数据过滤可以帮助我们快速去除不相关的上下文比如如果任务核心要素中包含“应用/微服务Shopify支付服务”我们可以通过元数据过滤规则只保留与Shopify支付服务相关的上下文如何对结构化上下文和非结构化上下文进行统一的重排序和过滤——因为结构化