阿里妹导读
本文紧张讲述，以“无需演习模型”的办法实现：AI智能剖析功能需求、写代码、review代码办理特定业务问题的实践过程
择要
本文紧张讲述，以“无需演习模型”的办法实现：AI智能剖析功能需求、写代码、review代码办理特定业务问题的实践过程，办理的是一款极其小众的开拓措辞的问题，模型并无干系领域知识，因此具备一定的代表性。与讲解大模型事理和方法论的文章不同，本文紧张站在工程同学视角记录实践履历，例如：如何做RAG优化、rank排序剪枝、small2big、prompt调优、fewshot、避免幻象等，并不会对算法事理做过多阐发，希望能对同样没有算法背景的同学有所帮助，文中内容仅代表个人不雅观点，若有不严谨之处，欢迎指出谈论。
利用AI实现通过功能需求描述天生脚本代码，并具备自动补全、格式化和CodeReview能力：
业务背景
在B端发卖技能系统中，决策中央扮演着非常主要的浸染，它支持各种繁芜规则决策树的快速配置和接入能力，业务系统在自身流程中接入后，可以快速相应各种政策规则的调度上线。例如，毛利管控政策、售卖勾引政策、审批规则政策、一户一价灵巧报价政策、产品搭配的售卖规则等，还有很多技能类的诸如灰度规则等技能场景，所有繁芜的业务规则都可以抽象成一颗决策树来实现。
一言以蔽之，决策中央能通过灵巧的规则策略配置能力支持各种繁芜业务政策快速落地，给B端系统的灵巧扩展性哀求供应了强有力的支撑。
在业务流程中，接入规则插件实现灵巧运营能力。
从技能架构视角看，决策中央内部是按照，从上至下：策略-规则-指标的层次构造来实现其灵巧配置能力的。个中指标层是其灵巧性的根本保障，指标层紧张基于Aviator脚本[1]实现，技能同学可以通过快速编写Aviator脚本定义出指标给到规则和策略运营配置利用，脚本层可以内聚的实现一些“相对繁芜”的业务流程，规则策略层可以配置出繁芜的决策树组合，从而实现快速支撑业务政策。
Aviator是一个高性能、轻量级的 java 措辞实现的表达式求值引擎, 紧张用于各种表达式的动态求值。现在已经有很多开源可用的 java 表达式求值引擎,为什么还须要 Avaitor 呢?
Aviator的设计目标是轻量级和高性能,比较于Groovy、JRuby的笨重, Aviator非常小, 加上依赖包也才 537K,不算依赖包的话只有 70K; 当然, Aviator的语法是受限的, 它不是一门完全的措辞, 而只是措辞的一小部分凑集。
其次, Aviator的实现思路与其他轻量级的求值器很不相同, 其他求值器一样平常都是通过阐明的办法运行, 而Aviator则是直接将表达式编译成 JVM 字节码, 交给 JVM 去实行。大略来说, Aviator的定位是介于 Groovy 这样的重量级脚本措辞和 IKExpression 这样的轻量级表达式引擎之间。
github:https://github.com/killme2008/aviatorscript
一段Aviator脚本样例：
use java.io.File;let io = require('io');let files = count(ARGV) == 0 ? 5 : long(ARGV[0]);let nums = count(ARGV) < 2? 1000 : long(ARGV[1]);let temp_dir = "/tmp";for i in range(0, files) { let file = "#{temp_dir}#{File.separator}data.#{i}"; let writer = io.writer(io.file(file)); for j in range(0, nums) { write(writer, "#{rand(100000000)}\r\n"); } io.close(writer); p("Generate #{nums} random numbers to file #{file}");}let testResult = indicator_execute("TEST", "TEST-INDICATOR", seq.map());if (is_empty(testResult)) { log.log("测试指标调用结果为空");}let testNameSet = seq.set();for testData in testResult { seq.add(testNameSet, testData.get("name"));}...
业务问题
Aviator脚本在带来灵巧性的同时，给技能同学也带来一定的困扰：
一、研发脚本困难
措辞小众不熟习Aviator相对来说是一门比较小众的脚本措辞，没有完备的知识文档体系，技能同学险些都是java背景，除非已经很闇练Aviator脚本开拓，过程中常常碰着很多的语法问题，基本上是碰着一个查阅一次文档，非常痛楚。
无成熟IDE环境虽然Aviator供应了idea插件可以编辑脚本，但技能同学开拓时每每更习气在决策中央进行，基本都在浏览器的编辑框内，语法缺点很难创造，非常痛楚。
难以掩护
为了更好的运营和掩护指标脚本，我们在脚本根本上设计了指标的名称、描述的属性，用来描述实在现功能，便于掩护和处理，但实际研发过程中，大家每每不愿意投入较大的精力负责填写和掩护，指标的有效性变得越来越差，重复度也越来越高。个中，无效描述（描述字段少于10个中笔墨符）的指标占比超过55%
二、审阅脚本困难
结合上述第1点问题，我们也预判到了可能存在的研发风险，以是开拓了很多稳定性保障功能，如：基于mock数据进行验证估量算、接入变更管控审批、灰度发布和回滚流程等，所有指标开拓须要经由：验证->评审->灰度->发布 过程，但评审时也只能利用决策中央浏览器的编辑器进行查看和剖析。
评审脚本困难以历史履历来看，大量脚本提交审批时存在根本缺点，如缩进格式分歧一、命名风格禁绝确、非常判空处理不敷、注释不敷等，其次则是运行逻辑缺点。脚本多次提交评审才能上线的占比高达80%以上。
大略来说，指标依赖Aviator脚本，但没有完备的研发工具体系导致效率低下。
实践方案
基于AI，github、aone copilot体系已经具备非常厉害的代码天生、注释描述天生、智能代码评审等能力，借鉴于此，我们也可以探索利用AI大模型的能力来提升指标脚本的研发效率，详细来说，便是在决策中央指标编辑页增加：AI 智能研发助手，帮助办理以上难题。
一、寻衅&解题思路
1、模型预演习的知识能力有限以本文实践为例，“通义千问”所节制的信息和数据更新至2023年为止，而“Meta-Llama-3-1-405B-Instruct”的演习数据则截止到2023年3月1日。
2、模型对Aviator的泛化能力很差
Aviator是非常小众的脚本措辞，当你在“通义千问”中讯问Aviator脚本时什么时，它的回答非常“离谱”，当你在“Meta-Llama-3-1-405B-Instruct”模型中讯问：Aviator脚本如何做字符串拼接时，答案也是缺点的，也便是说已有的大模型对付Aviator来说，险些是一问三不知，以是会涌现“胡扯”的幻象。
3、解题思路
上述两个问题，是大模型在实际运用落地时非常普遍的问题，业界办理的思路都大同小异，ROI由高到底的顺序为：选择得当的模型 > 优化好提示词 > RAG检索增强 > 模型预演习，这里不展开说其事理，普通的来讲，让模型帮助我们办理问题，类似寻求一位专家老师的帮助，但老师没有特定领域的知识和履历，比如老师是一个很牛的数学专家、逻辑剖析能力极强，但没有法律干系的履历，而我们要寻求法律干系的帮助，则须要：
1、选择一个得当的模型，就彷佛选择一个精良的老师，它本身的学习能力和知识储备是非常精良的，如果要办理的问题场景是逻辑剖析和推理，我们就不能去找艺术创作能力很强的老师；
2、优化Prompt提示词，便是说我们要把问题问好，要见告他足够多的背景信息，还有一些实际案例的答案，让老师根据自身的能力来做推断，这便是类似Zero Shot、Few Shot的prompt调优；
3、RAG知识增强，就彷佛给老师一本参考书，让老师基于问题首先翻阅参考资料，然后用他的能力来进行理解和剖析，终极给到我们好的答案；
4、模型预演习，这就好比是让老师“持续深造”，让一个数学专家负责学习法律逻辑推理的专业知识，当然耗时和本钱就很高了。
本文在实际落地时，紧张选择了1、2、3点来进行调优，模型选择上，选择了“Meta-Llama-3-1-405B-Instruct”，从业界的评测来看，llama 3.1 405B全方位碾压GPT-3.5 Turbo，Llama 3.1 405B 在 NIH/Multi-needle 基准测试的得分为 98.1，虽然仍旧比不上 GPT-4o，但也表明其在处理繁芜信息的能力上堪称完美，尤其是其在ZeroSCROLLS/QuALITY 基准测试的得分为 95.2，意味着其具有整合海量文本信息的能力， 对付关注 LLM 在 RAG 方面性能的 AI 运用开拓者来说，可谓是相称友好。
再来看代码天生能力，Human-Eval 紧张是卖力测试模型在理解和天生代码、办理抽象逻辑能力的基准测试，而 Llama 3.1 405B 在与其他大模型的比拼中也是稍占上风。
二、RAG实现Aviator语法知识问答
如前文所述，Aviator虽然具备高性能、轻量级且高度兼容java的特性，但它是一个非常小众的脚本措辞，其推广程度和业界熟习程度都非常低，为此，我们没有办法直策应用LLM来做Aviator语法知识的问答。
1、知识向量化与检索实现知识库问答最常用的技能方案便是：RAG，RAG的方案架构可以大略抽象为：用户输入->向量检索知识片段->LLM基于知识片段做扩展->输出给用户。
困难：由于Aviator非常小众，仅有知识库便是：aviatorscript语雀知识库[1]，我们也无法获取到知识库api token权限，也没有其他完全的文档数据，也就没有办法做知识向量数据库。
这里直接省却了向量数据库的搭建，而把文档检索简化成了语雀的公共搜索api[2]，通过传入搜索词直接在语雀知识库搜索，可以实现根本的文档片段检索，这样可以办理用户提问的根本检索问题。
当然，如果有完备的知识库，则可以自研进行文本分段和向量化存储，并采取一些常用的技能方案实现检索。在大规模实际工程落地时，远比这个架构繁芜，涉及到如何做查询意图识别、查询改写优化、向量化调优、模型调头等等。
2、LLM内容增强在完成根本的文档片段检索后，就可以利用LLM对检索结果进行内容增强，prompt则是采取范例的RAG提示词，例如当我们搜索“如何遍历凑集”时，首先会通过语雀的公共api搜索出干系的文档片段择要，接着会采取如下prompt去讯问大模型：
你非常善于回答关于aviator脚本干系的技能问题，须要按以下步骤和回答用户问题。# 步骤- 识别用户输入的问题，问题在<input></input>中；- 理解已有的参考文档，文档在<ref></ref>中；- 对参考文档中的信息进行整理，将干系信息与用户问题进行关联，形成回答内容，供应详细和准确的回答；# 哀求- 你须要在回答中注明参考文档的来源和链接，以便用户可以进一步查看干系资料。# 限定- 如果问题与aviator脚本技能并不干系，则直接回答"我只能回答aviator技能干系问题。"- 严格按照参考文档中的内容进行回答，如果没有能回答问题的参考文档，你须要直接回答“没有找到干系文档，我只能回答aviator技能干系问题！
”。- 不能利用js、ruby、python、java等其他措辞规范回答问题，不要捏造或创造禁绝确的答案。<input>如何遍历凑集</input><ref># 10. 数组、凑集和 Sequence## 择要这一章，我们将先容<em>如何</em>在 AviatorScript <em>如何</em>方便地创建和操作数组、<em>凑集</em>。同时先容在此之上的 Sequence 抽象。AviatorScript 中将数组和<em>凑集</em>都抽象成一个序列<em>凑集</em> Sequence，在此之上可以用同一套高阶函数方便地...[文档链接](https://www.yuque.com/boyan-avfmj/aviatorscript/zg7bf9)# 用户指南（5.0之前版本）## 择要本文档不再掩护，请参考《<em>如何</em>升级到 5.0 大版本（老用户必读）》，升级到 5.0 大版本，阅读《AviatorScript 编程指南》，感激。简介 Aviator是一个高性能、轻量级的 java 措辞实现的表达式求值引擎,紧张用于各种...[文档链接](https://www.yuque.com/boyan-avfmj/aviatorscript/ra28g1)</ref>
终极模型会对搜索出来的文档择要与问题进行了干系性剖析，并进行了总结和整理终极答案。而prompt的调优对付模型工程落地效果，每每是ROI最高的，因此也出身了一门新的学科：提示词工程[3]，还有很多优化prompt的履历和工具可以参考和利用。
Demo
3、下一步优化检索结果Rerank重排序
通过语雀api搜索出来的文档择要还是存在一些与问题本身干系度较低的内容，如果采取自建向量搜索能力依然会存在类似问题，同时，LLM模型能接管的高下文窗口大小也是存在限定的，如果检索出来的参考文档内容过大，也没有办法直接交给LLM进行内容增强，因此，就须要对检索结果进行Rerank重排序，过滤掉干系度低的内容，避免超出模型窗口大小的限定，也能避免不必要的“幻象”。
Small to Big通过渐进式的检索方法，先检索出文档择要（Small），然后结合择要Rerank重排序后，按顺序根据链接获取原始文档内容，再对原始文档内（Big）容进行检索查询，直到找到更精准匹配的文档内容，末了再由模型剖析总结答案。
三、LLM实现通过功能描述天生脚本代码
在AI营销泛滥的时期，网上充斥着各种AI自动写代码、程序员失落业的软文，但事实上，离AI根据prd需求直接天生项目代码并能正常运行的时期还较远，一些公司的团队正在做类似的项目，但也并没有达到可商业化落地的阶段。虽然AI还并不具备通过业务需求天生可商业化项目级代码的能力，但AI已经具备一些通过单代码文件实现大略清晰的function需求的能力了，例如：我们可以让AI帮我们写一个对map数据进行sort by value的操作代码。
1、利用Few Shot，根据指标名称和功能描述天生脚本代码
themis指标脚本在LLM代码天生的可行性就在于，它与常规的项目级代码不同，它的设计初衷便是一个实现大略闭环功能的function，并且按场景进行了划分，每个独立场景内的指标都具备以下特色：1、利用相同的高下文数据构造；2、实现类似的功能。这就使得通过像模型供应指标名称和功能描述，再结合一些已有案例，让模型推断出待实现功能代码具备了可行性。
用户输入需求文档（1、待实现指标脚本的名称；2、功能描述；3、场景），系统找出相同场景的指标名城、功能描述、脚本代码，再结合一些诸如语法规范等约束条件，利用Few Shot的办法组装成Prompt让模型进行剖析推理，从而产出相应的脚本代码。
Prompt：
你须要按照以下"步骤"和"哀求"来帮助用户按照描述天生新的脚本代码:# 步骤- 利用aviator脚本语法进行剖析、理解和代码天生，不要利用其他开拓措辞的语法；- 剖析理解<prefix></prefix>部分描述的案例，个中描述了不同名称和功能的脚本代码是如何实现的；- 理解<name></name>部分，它代表当前用户须要编写的脚本的名称；- 理解<desc></desc>部分，它代表当前用户须要编写的脚本须要实现的功能解释；- 根据上述信息，天生能实现<name>和<desc>所描述名称和功能的脚本代码；# 哀求- 天生代码要符合aviator语法规范，不要天生与描述无关的内容；- 天生代码变量和函数以驼峰办法进行命名；- 天生代码统一以两个空格进行缩进；- 天生代码时要添加注释，aviator仅支持利用```##```单行注释；- 天生代码做好必要的判空处理，避免发生不预期的非常；- 可以利用内置函数，如indicator_execute、hsf_invoke、db_query等，以originalContext构造体作为输入；- 只管即便调用已有脚本而少写重复代码，格式为：indicator_execute($code, $args...)，个中$code为被调用脚本编码，$args为参数列表；- 天生内容按名称、功能、代码分段展示，采取markdown格式输出；<prefix>%s</prefix><name>%s</name><desc>%s</desc>
困难：这样的办法确实有效，但模型的高下文窗口存在max token限定，现在朝利用的模型（未付费，若采取付费版本可以长达128k）限定token数为8k，而prompt里传入大量代码，使得要求很随意马虎超出限定而失落败。而同场景的指标脚本，实在也存在一些与带推理脚本并不干系的代码，须要过滤掉他们并尽可能给模型供应干系度更高的脚本代码。
2、利用Rerank对样例数据进行干系度排序和筛选，剪枝高下文通过rerank模型，可以判断输入的目标文本与待判断文本列表的相似度，并按排序返回。这里利用了BAAI/bge-reranker-v2-m3[4]作为rerank模型，对召回的同场景指标按名称、功能描述与待实现需求的名称和描述进行相似度排序，过滤掉低干系度的代码，再组装prompt让模型推理，大幅提升推理的成功率和精准度。
Demo
3、下一步优化
现在天生的脚本代码，有几率涌当代码无法直接编译通过、运行的情形，对此，可以在系统中实现对天生代码的编译运行，并将结果再次喂给模型进行优化，通过迭代式的交互直到天生可编译运行的代码为止。
四、接入AoneCopilot实现脚本代码自动补全
虽然模型根据功能描述能自动天生脚本代码，但依然存在须要对代码进行调度的场景，连续采取上述的思路，已有的指标脚本是可以用来辅导我们进行代码的自动补全的。这里可以学习理解一下Aone Copilot以及GitHub Copilot的实现事理，大略来说便是利用高质量的代码库（300多种开拓措辞）进行模型演习，结合待补全文件的：1、措辞类型；2、干系代码（犹如路径、import、打开tab的文件等）；3、相似代码片段等进行推理来实当代码补全的。而aone copilot也供应了代码补全的api 做事，但接入做事须要传入代码仓库地址、代码prefix、代码suffix以进行项目级别的prompt的构建。
Aone Copilot是一个类似GitHub Copilot的自研智能研发助手，具备代码自动补全等能力。
困难：指标脚本代码没有独立的代码仓库，就没办法进行多文件联动推理补全了。
这里依然利用了指标脚本独立场景和function级实现的特性，直接找出同场景的指标脚本代码，同时全部拼接到prefix的部分，这样就构建了一个“假的”项目级别的prompt高下文给到推理做事，以此复用aone copilot的代码补全能力。
Demo
五、LLM实现通过代码生成功能描述和评审代码
除了自动天生脚本代码外，还须要办理“指标描述无效率高”和“脚本评审效率低”的问题，这个实现就相对来说大略一些，紧张是利用prompt优化和LLM本身的能力来进行，例如通过在提示词里给到模型既定的语法规范、评审规则、评审格式、代码本身和修复建议标准，让模型产出详细的评审结果和修正建议。
1、按哀求评审脚本并给出修正建议
你拥有高超的代码编写和检讨技能，熟习多种编程措辞和设计模式，可以根据代码的详细情形，指出存在的问题。请你参考<schedule></schedule>中的检讨步骤，<tab></tab>中的检讨哀求，对<code></code>中的代码进行检讨。<tab>- 空指针：指出可能存在未剖断空指针的地方，剖断办法为```param == nil```。- 缺少同等性：利用了不一致的缩进、命名风格、代码注释等，使得代码难以阅读和掩护。- 变量和函数命名不清晰：变量和函数名未利用驼峰命名，利用没故意义或者太过大略的变量和函数名，无法清晰地表达其用场。- 长方法或函数：方法或函数超过50行，增加了代码的繁芜性，难以理解和测试。- 注释不敷或者缺点：缺少注释或者注释与代码不一致，无法理解代码的用场和实现细节。- 不合理的代码布局：缺少良好的排版和布局，使得代码难以理解和浏览。- 过多的重复代码：存在超过10行的代码段，增加了代码冗余和掩护难度，可以将重复代码抽成函数。- 没有缺点处理机制：未考虑非常情形，没有适当的缺点处理机制，导致程序随意马虎崩溃或者涌现不可预见的缺点。</tab><schedule>- 利用aviator脚本语法进行检讨和优化，不要利用其他开拓措辞的语法，aviator仅支持利用```##```单行注释，统一以两个空格进行缩进，以驼峰办法进行命名，脚本引擎内置了很多函数，如indicator_execute、hsf_invoke、db_query等，脚本以originalContext构造体作为输入；- 若代码都检讨了空指针，则指明详细检讨的地方；- 若方法或函数代码没有超过50行，则无需检讨长方法或函数；- 若重复代码没有超过10行，则无需检讨重复代码；- 深入理解要检讨的代码，包括其功能、逻辑和构造等方面的特点；- 检讨代码，指出其存在的问题，解释检讨的过程和结果，明确指出问题代码的位置行数，如果没有问题则无需输出；- 如果可以，针对问题代码给出修正建议，不要针对不同问题重复天生建议代码，而要用一段代码建议办理所有问题，确保不毁坏现有功能，不要天生与原代码严重不符的代码建议；- 回答内容不要复述检讨步骤和哀求，采取markdown格式输出；</schedule><code>%s</code>
困难：因模型对Aviator语法并不理解，因此多数时候天生的代码评审修复建议是类似js、ruby、python等脚本措辞的语法，如if ... then ...，这样的修复建议是完备不符合Aviator规范的。
1.1 优化prompt以代码样例见告模型Aviator的语法规范对此，连续采取few shot的思路，在prompt布局时见告模型Aviator脚本的语法规范，但如果我们将全体知识库的文档都输入给模型，一来高下文长度无法支持，二来也没有原始的文档数据，这里采取一个变通的办法：从github高下载Aviator脚本的样例代码，同样地为了避免超出高下文窗口限定，随机选取部分代码片段喂给模型，从而让模型不要涌现天生js、ruby脚本的幻象。
你拥有高超的代码编写和检讨技能，熟习多种编程措辞和设计模式，可以根据代码的详细情形，指出存在的问题。首先你须要从<example></example>中的样例代码中学习aviator脚本语法规范，例如：- 利用```let goodName = "name";```的办法定义变量，无需设定变量类型；- 利用```fn addFunction(a, b) {return a + b;}```的办法定义函数；- 利用```seq.set()```定义凑集，利用```seq.list()```定义数组，利用```seq.map()```定义map；- 利用```str.isNotBlank(...)```的办法引用字符串工具；- 利用```json.toJSONString(...)```的办法引用json工具；- 以originalContext构造体作为输入；- 内置了很多函数可以调用，如```indicator_execute(...)```、```hsf_invoke(...)```、```db_query(...)```、```with_cache(...)```、```saveData(...)```等，日志输出只支持```log.log(...)```的办法。然后你须要参考<tab></tab>中的检讨哀求、<schedule></schedule>中的检讨步骤，对<code></code>中的代码进行检讨和优化。<tab>- 剖断空指针：针对利用的变量，必须剖断空指针，对函数名无需剖断空指针。- 保持同等性风格：要利用同等的缩进、命名风格、代码注释等，统一用两个空格进行缩进，变量函数要以驼峰办法进行命名；- 变量和函数命名要清晰：变量和函数名必须利用驼峰命名，同时命名必须故意义，能通过命名理解其用场；- 方法和函数不能过长：定义的方法和函数不能超过50行，若存在超过50行的方法或函数，该当拆解成更小的方法和函数；- 注释要充足且故意义：只能利用```##```单行注释，不能用其他如```//```,```/ /```进行注释，不能多行注释，代码不能缺少注释，注释内容与代码含义必须保持同等；- 合理的代码布局：代码要有良好的排版和布局，使得代码便于理解和浏览；- 不能有过多的重复代码：不能存在超过10行的重复代码段，若存在超过10行的重复代码，该当抽成函数进行调用；- 要有缺点处理机制：必须有适当的缺点处理机制，增加程序的健壮性；</tab><schedule>- 深入理解要检讨的代码，包括其功能、逻辑和构造等方面的特点；- 按<tab></tab>中的规则检讨代码，清晰解释检讨过程和结果，不能利用js、ruby、python、java等其他措辞规范；- 若不存在违反规则约束的问题，不要捏造问题和修正建议；- 若存在违反规则约束的问题，则首先对问题进行总结剖析，要明确指出问题代码的位置和行数，并给出代码修正建议，确保建议代码要符合aviator脚本语法规范，同时与原代码实现的功能和逻辑保持同等，不要对问题以外的代码做修正；- 如果捏造问题将会受随处分，如果修正建议代码不符合aviator语法规范将会受随处分，如果修正建议代码与原代码严重不符将会受随处分；- 采取markdown格式输出，建议代码用```包装起来；</schedule><example>%s</example><code>%s</code>
Demo
2、根据指标脚本生成功能描述
你拥有高超的脚本代码理解能力，可以根据代码的详细情形，总结出脚本所实现的功能描述。请你参考<schedule></schedule>中的步骤，对<code></code>中的代码进行总结。<schedule>- 利用aviator脚本语法进行剖析和理解，不要利用其他开拓措辞的语法，除aviator基本语法外，脚本引擎内置了很多函数，如indicator_execute、hsf_invoke、db_query等，脚本以originalContext构造体作为输入；- 深入理解代码，包括其功能、逻辑和构造等方面的特点；- 用一到两句话总结代码所实现的功能是什么，然后再总结实在现步骤是什么；- 要简明扼要，不要长篇大论，如果无法理解代码逻辑就无需输出，不要总结出绝不相关的描述；- 回答内容不要复述处理步骤和哀求，采取markdown格式输出；</schedule><code>%s</code>Demo
利用浏览器编辑器编辑脚本代码还会碰着格式化的问题，而因措辞小众找不到得当的格式化插件，这里也可以利用模型的推理能力帮助进行快速的格式化代码。
你拥有高超的代码编写技能，熟习多种编程措辞和设计模式，可以对代码进行格式化。首先你须要从<example></example>中的样例代码中学习aviator脚本语法和代码规范，例如：- 利用```let goodName = "name";```的办法定义变量，无需设定变量类型；- 利用```fn addFunction(a, b) {return a + b;}```的办法定义函数；- 利用```seq.set()```定义凑集，利用```seq.list()```定义数组，利用```seq.map()```定义map；- 利用```str.isNotBlank(...)```的办法引用字符串工具；- 利用```json.toJSONString(...)```的办法引用json工具；- 以originalContext构造体作为输入；- 内置了很多函数可以调用，如```indicator_execute(...)```、```hsf_invoke(...)```、```db_query(...)```、```with_cache(...)```、```saveData(...)```等，日志输出只支持```log.log(...)```的办法。然后你须要参考<tab></tab>中的哀求，对<code></code>中的代码给出格式化修正建议。<tab>- 每一行的末端不能有空格；- 统一用两个空格的办法进行缩进；- 变量函数要以驼峰办法进行命名；- 只能利用```##```单行注释，不能用其他如```//```,```/ /```进行注释，不能多行注释，代码不能缺少注释，注释内容与代码含义必须保持同等；- 代码要有良好的排版和布局，使得代码便于理解和浏览；- 不能存在超过10行的重复代码段，若存在超过10行的重复代码，该当抽成函数进行调用；- 给出代码格式化建议，确保建议代码要符合aviator脚本语法规范，确保不要对代码逻辑做任何修正；- 如果修正建议代码不符合aviator语法规范将会受随处分，如果修正建议代码与原代码严重不符将会受随处分；- 采取markdown格式输出，建议代码用```包装起来；</schedule><example>%s</example><code>%s</code>
Demo
下一步实践操持
一、效果评估
目前，实践落地还剩下一个非常主要的部分没有完成，也是模型落地运用里非常主要的一个部分：效果评估，AI内容天生是否具备商业化、工业级有效的结果，必须由完备的测评体系来衡量，如果模型天生的代码根本不可用，那这样的运用就毫无意义。
下一步，将针对上述运用处景构建一些评测能力，目前的思路大致按照三个维度去展开：
1、模型交叉评估，如通过meta-llama天生的代码，由qwen或者其他大模型来进行打分评测反馈。
2、系统实现评估，如大模型天生的代码，直接调用引擎进行编译、实行，若编译出错或者实行失落败，则进行负向打分反馈；
3、人为评估，对付模型产生的所有内容，建立人工点赞、点踩的快速评价功能，通过低本钱的人为反馈来进行评测反馈。
二、智能策略
在指标层的智能天生上若能取得不错的效果，那么规则、策略也可以考试测验通过需求描述来天生，由于指标层相对来说是更繁芜的代码天生，而规则、策略则更多的是逻辑构造的推理，而这正好是大模型的强项，也就可以做到：根据完全的业务需求描述进行剖析拆解，转化成策略-规则-指标的智能天生，从而完全实现全体策略的智能化天生。
结语
本文紧张以工程视角记录，如何在不演习模型的情形下实现RAG知识库、AI智能天生代码等技能实践，个中还有很多待优化和完善的地方，例如：基于向量检索进行知识召回使得内容更精确，在未演习模型时采取In-Context Learning会存在token资源摧残浪费蹂躏等，但并不影响以此理解大模型运用背后的技能事理，希望对读者有所启示。
本文实践技能选型
Aviator语法知识库：语雀知识库文档检索：语雀公共apiLLM：Meta-Llama-3-1-405B-InstructRerank：bge-reranker-v2-m3脚本代码补全：aone copilot api提示词及调优：自研参考链接：
[1]https://www.yuque.com/boyan-avfmj/aviatorscript/ra28g1
[2]https://www.yuque.com/api/zsearch?type=content&scope=boyan-avfmj%2Faviatorscript&tab=group&p=1&sence=searchPage&q=xxx
[3]https://www.promptingguide.ai/zh
[4]https://huggingface.co/BAAI/bge-reranker-v2-m3