llamaIndex - 💡(How to fix) Fix Improve developer error message for unrecognized embedding names in `load_embed_model` [1 pull requests]

Feature Description

Description

Currently, when an invalid embedding name is provided to load_embed_model, the raised error message does not provide any guidance about supported embedding classes.

Current Behavior

if name not in RECOGNIZED_EMBEDDINGS:
    raise ValueError(f"Invalid Embedding name: {name}")

Suggested Change

if name not in RECOGNIZED_EMBEDDINGS:
    available = ", ".join(sorted(RECOGNIZED_EMBEDDINGS.keys()))
    raise ValueError(
        f"Invalid Embedding name: {name}. "
        f"Available embeddings: {available}"
    )

Reason

Currently, LlamaIndex already validates whether an embedding name exists in RECOGNIZED_EMBEDDINGS, but the resulting error message does not expose the list of supported embedding names.

This makes debugging configuration issues harder, especially when:

• an embedding class name is misspelled
• optional embedding dependencies are not installed
• serialized configs contain outdated or invalid class names

At the moment, developers must manually inspect the source code or runtime registry contents to determine valid embedding names.

Existing approaches mainly involve:

• checking the source implementation directly
• printing RECOGNIZED_EMBEDDINGS.keys() manually during debugging
• trial-and-error with embedding names

These approaches work but increase debugging friction and reduce developer experience for a relatively small validation issue.

Value of Feature

This improvement enhances the developer experience by making embedding configuration errors significantly easier to diagnose.

Currently, when an invalid embedding name is provided, the error message only indicates that the name is invalid without showing the supported options. This can slow down debugging and increase confusion, particularly for:

• new contributors
• users working with serialized configs
• environments with optional embedding dependencies installed conditionally

Providing the list of available embedding names directly in the exception message would:

• reduce debugging time
• improve usability and clarity
• make configuration validation more intuitive
• reduce the need to inspect internal source code during troubleshooting

The change is also low-risk and fully backward compatible since it only improves the error message content without affecting existing functionality.