Repository navigation
2.1.0
What's Changed
A grader declares what kind of check it is at registration, so a consumer plug-in is categorised the same way a built-in is. Previously any grader outside the seven built-in types reported grader_type = 'unknown' on every row it produced.
Shipped as a minor despite the signature change below. register is public, so the 1.0.0 policy would call this a major; it goes out as 2.1.0 as a deliberate exception, because the break is a one-line edit per grader that fails loudly at import.
Added
graders.GraderType, aStrEnumover the closed set the results store'sgrader_typecolumn accepts:unknown,heuristic,statistical,llm_as_judge,trajectory,human. AStrEnumso it needs no serializer of its own on the way to a row.graders.category_of, the registry lookup behindgrader_lookups.
Changed
- Breaking:
graders.base.registertakes a required second argument,category, agraders.GraderType. Every@base.register('foo')becomes@base.register('foo', base.GraderType.HEURISTIC)or whichever member applies; omitting it is aTypeErrorat import. Required rather than defaulted on purpose - it is the only source of a row'sgrader_type, and a default would be the value every grader forgets to override. store.grader_lookupsreads the category from the registry instead of a closed table of built-in type names, so a plug-in that declaresHEURISTICreportsheuristicwhere it used to reportunknown. Rows for consumer graders change value in thegrader_typecolumn; nothing about the row shape changes.
Removed
store._GRADER_TYPES, the private table the categories used to live in. Keeping it alongside the registration argument would mean two sources for one fact and a precedence rule between them.
Upgrading
Add the category to every @base.register(...) in your plug-ins:
from evalcore.graders import base
@base.register('my_grader', base.GraderType.HEURISTIC)
class MyGrader:
...Pick the member that describes the check, not the grader's shape - an AggregateGrader computing a rate is still HEURISTIC, not STATISTICAL.