Summary
- Use
input_mappingto map/transform evaluator-required field names to your input data. - You can bind an
input_mappingto an evaluator for reuse with multiple inputs using.bindorbind_evaluator
Why do evaluators accept a payload and an input_mapping vs. kwargs?
Different evaluators require different keyword arguments to operate. These arguments may not perfectly match those in your example or dataset. Let’s say our example looks like this, where the inputs and outputs contain nested dictionaries:Hallucination, which requiresquery,context, andresponseexact_match, which requiresexpectedandoutput
input_mapping enables the evaluators to run on the same payload - the map/transform steps are handled by the evaluator itself.
Input Mapping Types
Theinput_mapping parameter accepts several types of mappings:
- Simple key mapping:
{"field": "key"}- maps evaluator field to input key - Path mapping:
{"field": "nested.path"}- uses JSON path syntax from jsonpath-ng - Callable mapping:
{"field": lambda x: x["key"]}- custom extraction logic
Path Mapping Examples
Callable Mappings
For complex transformations, use callable functions that accept aneval_input payload:
Pydantic Input Schemas
Evaluators use Pydantic models for input validation and type safety. Most of the time (e.g. forClassificationEvaluator or functions decorated with create_evaluator), the input schema is inferred. But, you can always define your own. The Pydantic model allows you to annotate input fields with additional information such as aliases or descriptions.
Schema Inference
Most evaluators automatically infer schemas if not provided at instantiation. LLM evaluators infer schemas from prompt templates:Binding System
Usebind_evaluator or .bind to create a pre-configured evaluator with a fixed input mapping. At evaluation time, you only need to provide the eval_input and the mapping is handled internally.

