Resolve systemic issues with how intrinsic adapters are loaded, invoked, and configured across backends. We should finalize a design for the below points and then create issues for that finalized implementation.
Initial implementation of EmbeddedIntrinsicAdapters in: #881
Initial removal of OpenAI adapters: #543
-
Adapter Loading & Unloading
a. Clean up divergent control flow between EmbeddedAdapters and regular Intrinsics loading.
b. Fix bug where obtain_lora is always called during call_intrinsic when embedded_adapters=False, which masks the real error from users and conflicts with different loading methods.
c. Address that adapter loading/unloading is both backend-specific and adapter-type-specific — design a coherent abstraction for this.
-
Model Option Handling
a. Fix intrinsic rewriters overwriting model options unconditionally.
b. Decide and document how intrinsics should interact with model options.
c. There's a larger question of hierarchy with model options as well. Model options can technically be defined in all the following places: hf base model defaults in generation_config.json, adapter defaults in generation_config.json, io.yaml defaults, io.yaml values specified in the Mellea intrinsic, mellea model options.
-
Naming Consistency
a. Resolve whether adapter name must equal adapter.intrinsic_name or can differ (open issue).
b. Standardize usage of "adapter name", "intrinsic name", and "qualified name" across the codebase.
-
Output Parsing & Generic Intrinsic Contracts
a. Address the problem where top-level call_intrinsics helpers assume a single output structure (e.g., result_json["answerability"] vs result_json["answerability_likelihood"]). We likely need to work with the Intrinsic team here to set common assumptions.
b. Determine whether all adapters of a given type must conform to a standard output schema (e.g., a single output field, required keys) or whether parsing should be adapter-specific.
c. This also encompasses "versioning" of intrinsics. The "same" intrinsic may be updated / changed to have a different expected output format and our top-level call_intrinsic functions only allow one version.
-
OpenAI Backend Support
a. Add OpenAIAdapters back — requires discussion on the logic for pulling/registering these. EmbeddedIntrinsicAdapters should technically inherit from these.
-
Cleanup
a. Remove or repurpose the catalog. We shouldn't mandate all intrinsics be a part of the known catalog.
Resolve systemic issues with how intrinsic adapters are loaded, invoked, and configured across backends. We should finalize a design for the below points and then create issues for that finalized implementation.
Initial implementation of EmbeddedIntrinsicAdapters in: #881
Initial removal of OpenAI adapters: #543
Adapter Loading & Unloading
a. Clean up divergent control flow between EmbeddedAdapters and regular Intrinsics loading.
b. Fix bug where obtain_lora is always called during call_intrinsic when embedded_adapters=False, which masks the real error from users and conflicts with different loading methods.
c. Address that adapter loading/unloading is both backend-specific and adapter-type-specific — design a coherent abstraction for this.
Model Option Handling
a. Fix intrinsic rewriters overwriting model options unconditionally.
b. Decide and document how intrinsics should interact with model options.
c. There's a larger question of hierarchy with model options as well. Model options can technically be defined in all the following places: hf base model defaults in generation_config.json, adapter defaults in generation_config.json, io.yaml defaults, io.yaml values specified in the Mellea intrinsic, mellea model options.
Naming Consistency
a. Resolve whether adapter name must equal adapter.intrinsic_name or can differ (open issue).
b. Standardize usage of "adapter name", "intrinsic name", and "qualified name" across the codebase.
Output Parsing & Generic Intrinsic Contracts
a. Address the problem where top-level call_intrinsics helpers assume a single output structure (e.g., result_json["answerability"] vs result_json["answerability_likelihood"]). We likely need to work with the Intrinsic team here to set common assumptions.
b. Determine whether all adapters of a given type must conform to a standard output schema (e.g., a single output field, required keys) or whether parsing should be adapter-specific.
c. This also encompasses "versioning" of intrinsics. The "same" intrinsic may be updated / changed to have a different expected output format and our top-level call_intrinsic functions only allow one version.
OpenAI Backend Support
a. Add OpenAIAdapters back — requires discussion on the logic for pulling/registering these. EmbeddedIntrinsicAdapters should technically inherit from these.
Cleanup
a. Remove or repurpose the catalog. We shouldn't mandate all intrinsics be a part of the known catalog.