Skip to main content

​
Functions

​
FUNC requirement_check_to_bool 

requirement_check_to_bool(x: CBlock | str) -> bool
Checks if a given output should be marked converted to True. By default, the requirement check alora outputs: {"requirement_likelihood": 0.0}. True if >.5

​
FUNC reqify 

reqify(r: str | Requirement) -> Requirement
Maps strings to Requirements. This is a utility method for functions that allow you to pass in Requirements as either explicit Requirement objects or strings that you intend to be interpreted as requirements.

​
FUNC req 

req(*args, **kwargs) -> Requirement
Shorthand for Requirement.init.

​
FUNC check 

check(*args, **kwargs) -> Requirement
Shorthand for Requirement.init(…, check_only=True).

​
FUNC simple_validate 

simple_validate(fn: Callable[[str], Any]) -> Callable[[Context], ValidationResult]
Syntactic sugar for writing validation functions that only operate over the last output from the model (interpreted as a string). This is useful when your validation logic only depends upon the most recent model output. For example: Requirement("Answer 'yes' or 'no'", simple_validate(lambda x: x == 'yes' or x == 'no') Validation functions operate over Context. Often you do not care about the entire context, and just want to consider the most recent output from the model. Args:
  • fn: the simple validation function that takes a string and returns either a bool or (bool, str)
  • reason: only used if the provided function returns a bool; if the validation function fails, a static reason for that failure to give to the llm when repairing

​
Classes

​
CLASS LLMaJRequirement

A requirement that always uses LLM-as-a-Judge. Any available constraint ALoRA will be ignored.

​
CLASS ALoraRequirement

A requirement that always uses an (possibly specified) ALora. If an exception is thrown during the ALora execution path, mellea will fall back to LLMaJ. But that is the only case where LLMaJ will be used.