Feature: llamacpp support + strict collection naming (optional)

[spumer]

Hi. I'm testing few models and providers for my projects and make some contributions to claude-context repo.

May be this features will be usefull for your projects too.

Thanks for your work!

Below you can see description prepared by Claude Code:

🎯 Summary

Add configurable collection naming strategy to prevent data conflicts when switching between different embedding providers and models.

💡 Motivation

Currently, when users switch between embedding providers (e.g., from Ollama to LlamaCpp), all providers share the same collection name (hybrid_code_chunks_<hash>). This causes:

• Data contamination: New embeddings overwrite previous ones
• Invalid comparisons: Mixed embeddings from different models in same collection
• Lost work: Previous indexing is lost when switching providers

✨ What's New

Core Features

1. Strict Collection Naming Mode (opt-in via EMBEDDING_STRICT_COLLECTION_NAMES=true)

   • Collections include provider and model: hybrid_<provider>_<model>_<path_hash>_<unique_hash>
   • Example: hybrid_ollama_nomic_embed_text_abc12345_def67890
   • Complete isolation between providers

2. Custom Collection Names (via MILVUS_COLLECTION_NAME)

   • Override automatic naming with custom collection name
   • Useful for advanced use cases and testing

3. New getModel() Method

   • Added to base Embedding class
   • Implemented in all providers (Ollama, LlamaCpp, OpenAI, Gemini, VoyageAI)
   • Enables provider+model identification

Backward Compatibility

• Default behavior unchanged: Legacy naming (hybrid_code_chunks_<hash>) remains default
• Opt-in feature: Users must explicitly enable strict naming
• No breaking changes: Existing collections continue to work

🎁 Benefits

For Users

• Safe experimentation: Test multiple providers without data loss
• Quality comparison: Compare embedding quality accurately
• Flexibility: Choose naming strategy that fits workflow
• Transparency: Debug output shows active configuration

For Project

• No breaking changes: Fully backward compatible
• Well-tested: Comprehensive test coverage
• Well-documented: Complete docs for users
• Extensible: Easy to add more providers