AlphaEvolve 会利用提供的代码基准以及用户提供的具体上下文来指导其运营。
用户上下文
用户提供的上下文会注入到每个生成提示中。它通过为 LLM 提供领域知识、数学公式和系统约束来平衡搜索空间。
- token 预算：最多 20 万个 token 的效果良好。超过 20 万个 token 的阈值后，上下文窗口会变得过载，LLM 的注意力会降低，变异质量也会降低。如果您的组合上下文（问题描述、代码和之前的程序）超过 20 万个 token，则必须减少。
要包含的内容
优化问题的精确数学公式。
关键约束及其明确的理由。
特定领域的术语和定义。
已知的良好方法或现有技术，以指导 LLM 的搜索方向。
详细说明不应做什么的具体明确的说明。
不应包含的内容
一般编程教程。
标准库文档（LLM 已经知道
numpy、sklearn等）。但是，请务必包含 LLM 可能不太了解的利基库或特定领域库 （自定义内核 API、专有 SDK 或专用 DSL）的文档。原始任意数据、电子表格或大型数据转储。数据应位于评估器框架中，而不是提示上下文中。
不相关的上下文，会消耗 token 但不会添加搜索信号。
您包含的每个上下文都必须通过积极帮助 LLM 生成更好、结构合理的变异来提供明确的价值。
评估反馈（分析洞见）
在每个执行循环之后，评估器可以返回诊断反馈文本以及数值分数。此反馈会自动附加到未来的提示结构中。
质量基准：强反馈具体、可操作且简洁。 不良反馈是通用反馈（例如“评估失败”）或过于 冗长。
运营目的：这些分析洞见会在后续生成中显示给 LLM，使其能够从执行失败中明确学习，并避免重复出现 bug。
内置提示多样化
AlphaEvolve 会自动使其传输到后端 LLM 集成的提示多样化。此操作在内部处理，无需手动用户配置。
该系统会在连续生成中改变其核心指令，以鼓励多样化的变异，并防止 LLM 陷入重复的编码模式。此行为是帮助 AlphaEvolve 探索广阔领域而不是陷入狭隘局部最优解的主要机制之一。
代码可读性
代码复杂性是一个有效的辅助指标。如果最终代码可读性是生产用例的一个因素，请考虑添加代码长度或认知复杂性作为辅助目标指标。
AlphaEvolve 可以实现高达 50% 的文件压缩，而不会降低功能性能。但是，LLM 会利用简单的指标（例如，移除所有内嵌注释以减少原始字符数）。为防止这种情况，请实现可捕获有意义的结构复杂性的指标，例如圈复杂度或抽象语法树 (AST) 节点计数，而不是评估原始字符串长度。