Skip to content

Latest commit

 

History

History
99 lines (55 loc) · 8.26 KB

File metadata and controls

99 lines (55 loc) · 8.26 KB

决赛轮

决赛阶段为开放竞赛,选手可以在代码全链路中实现优化,通过修改代码、调整索引构建与向量查询参数、修改编译选项与数据库参数等方式优化向量索引构建与向量查询性能。

祝开发者们勇攀性能高峰!

时间安排

  • 决赛第一阶段:

    • 2025 年 12 月 5 日公布决赛题目及评测技术指标,15:00(北京时间,下同)正式开放测评,测评截止时间为 2026 年 1 月 5 日 23:59。在测评结束后,参赛队伍需按要求提交源代码以及设计与实现文档,评审委员会将根据决赛提交的源代码和测试结果剔除不合法的成绩。赛题组将根据各个队伍的合法成绩折算最终分数并进行成绩排名,排名完成后将按排名发布入围决赛第二阶段的赛队名单(名单发布时间请关注组委会通知)。

    • 提交设计与实现文档:比赛过程中,参赛队伍需提交比赛设计与实现文档,组委会将审核并反馈修改建议,具体提交时间和提交入口请关注组委会官方通知。

  • 决赛第二阶段:2026 年 1 月中下旬,线下举办,入围该阶段的参赛队伍需针对题目做整体展示并完成答辩,评审委员会给出总成绩。

  • 决赛第二阶段和颁奖典礼初步安排在 2026 年 1 月中下旬举行(具体时间以组委会公布为准)。

决赛题目

在决赛第一阶段中,选手需要通过代码开发、调整参数等方式,优化向量索引构建与向量查询的性能。相较于初赛,决赛将给予选手更高的优化自由度,允许的行为如下:

  • 修改 PolarDB-PG 或 pgvector 源代码。选手提交的代码需要能在目标硬件环境中完成编译与部署,同时通过数据库与 pgvector 基础回归测试等功能测试。

  • 以源码的形式引入其他第三方库。选手可以以源码的形式将第三方代码引入 PolarDB-PG 或 pgvector 中,但是不能直接引入成熟的 PostgreSQL 数据库插件。

    • 为保障赛事公平性,参赛队伍禁止使用任何具备完整向量索引与查询最近邻向量能力的第三方库。非向量索引相关的第三方库,选手可自由选用。

    • 规则边界合规申请机制:若有参赛队伍对上述第三方库使用规定存在疑问,或需申请使用特定第三方库,请于 12 月 19 日 23:59 前,通过大赛官方沟通群联系赛事管理员,向赛题组提交正式申请。赛题组经讨论后,将向申请选手反馈结果。

    • 对于普遍性或具有重要影响的申请,赛题组必要时将在大赛官方沟通群内进行公示。未在截止时间前申请且使用涉及合规边界的第三方库,赛事方将按本禁用条款处理。赛事组对本规则保留最终解释权。

  • 修改数据库部署参数,包括内存使用量、并发线程数等。需要注意,如果提交的内存使用量参数过大,可能会出现内存耗尽(Out Of Memory,OOM)的问题,导致测评流程异常退出。

  • 指定建表与建立向量索引的语句。决赛允许选手指定向量索引构建语句,选手可以自主选择索引类型、索引数据精度等参数,便于选手增加和使用新的索引类型、数据精度。

  • 修改向量索引构建与向量查询参数。

测评环境

决赛将会在独立的容器中运行数据库与压测程序,数据库将被部署在一个 8C 32GB 的容器环境中,压测程序将运行在一个 8C 8GB 的容器环境中,运行容器镜像基于 polardb-pg-docker-devel-ubuntu24.04

数据集说明

决赛数据集为私有数据集,基于 Text-to-Image 1B 数据集随机抽取制作。

数据集原始数据类型为 float32(4 字节),维度为 200,数据集大小为 7.5GB,训练集数据条数为 1000w 条,测试集数据条数为 1w 条。

测评流程

测评分为三个阶段:

  • 数据库初始化阶段:预计约 5 分钟,测评程序将运行回归测试验证数据库、pgvector 插件基础功能的正确性,如果回归测试通过则会完成数据库、测试账号以及基础表结构的创建。

  • 数据导入与索引构建阶段:测评程序会将向量数据导入到数据库中,并建立向量索引,索引构建时间限时 60 分钟。因选手提供的向量构建参数不同,索引构建的时间也不尽相同,选手需要将索引构建时间控制在指定区间内

  • 基准测试阶段:根据选手提供的向量查询参数进行多轮查询,测评系统将返回召回率(Recall)超过 0.85 时的最大每秒查询数(Query Per Second,QPS)作为选手的成绩并排名,基准测试阶段总限时 30 分钟

测评提交方式

决赛的提交方式与初赛基本相同,只需要将配置文件上传到天池平台并点击提交,即可进行评测。配置文件格式参考ROUND2/config下的配置文件。

  • 决赛可以提交两个配置文件,其中config.conf包含代码库地址、提交 ID、索引构建与向量查询等参数项,主要控制代码与索引构建、向量查询等流程;postgresql.conf包含数据库参数项,主要控制数据库的运行行为

  • 选手提交代码测试时,需要进入 ROUND2 目录,将 config 文件夹压缩为 zip 文件上传,压缩命令为zip -r config.zip config/

  • 提交入口与初赛相同,为天池平台->提交结果->配置路径->上传 TCCFile ->提交,返回结果可以在我的成绩中查看。

  • 功能测试与性能测试通过后,系统将返回成绩,如果未通过测试会返回报错信息。参赛者每天有若干次机会提交评测(具体次数见天池页面),如果评测出错则不计入次数,排行榜取最优成绩排名。

计分规则

考核指标 评分逻辑 说明
索引构建时间 时间越短,得分越高 从数据导入到索引构建完成的耗时
查询 QPS QPS 越高,得分越高 每秒成功处理的查询请求数
  • 核心指标:向量索引的构建时间与向量查询 QPS (召回率 Recall > 0.85 时的最大 QPS)

  • 计分规则

    • 索引构建时间评分 $score_build = \frac{build_time_{baseline}}{build_time}$,其中 $build_time_{baseline}$ 是优化前的原始成绩,作为评测基准纳入计算。
    • 查询 QPS 评分 $score_qps = \frac{QPS}{QPS_{baseline}}$,其中 $QPS_{baseline}$ 是优化前的原始成绩,作为评测基准纳入计算。
    • 总成绩 $score = 100 * (lg(score_build * score_qps) + 1)$,天池平台将根据 $score$ 进行排名,参赛队伍应该综合考虑 QPS 与索引构建时间方面的性能。
  • 在决赛第一阶段结束后,会汇总所有选手合法的最优 $score$ 并将 $score$ 映射到 $[60, 100]$ 区间,具体计算方式如下:

    • $score_{final} = 60 + 40 * \frac{score_i - score_{min}}{score_{max} - score_{min}}$,其中:
    • $score_{max}$ 为全部队伍中最高的合法成绩
    • $score_{min}$ 为全部队伍中最低的合法成绩
    • $score_i$ 为第 i 支队伍的最优合法成绩

注意事项

  • 决赛允许选手修改数据库部署参数,包括内存使用量、并发线程数等。但是需要注意,如果提交的内存使用量参数过大,可能会出现内存耗尽(Out Of Memory,OOM)的问题,导致测评流程异常退出。

  • 决赛禁止选手修改数据库与 pgvector 回归测试的预期结果或禁用某些测试用例。

  • 决赛禁止选手直接以非源码的方式引入代码,也不允许使用其他数据库或成熟向量数据库插件(如 vectorchord、pgvector.rs等)代码替换当前的基础代码。

  • 若选手使用了可能触发禁用规则的优化手段,请主动联系赛题组成员进行审核申请,赛题组经过讨论后会给出答复。未在截止时间(12 月 19 日 23:59)前申请且使用涉及合规边界的第三方库,赛事方将按本禁用条款处理。赛事组对本规则保留最终解释权。