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