Skip to content

Fix: hardcoded embedding dimension#582

Open
LaansDole wants to merge 2 commits intoOpenBMB:mainfrom
LaansDole:main
Open

Fix: hardcoded embedding dimension#582
LaansDole wants to merge 2 commits intoOpenBMB:mainfrom
LaansDole:main

Conversation

@LaansDole
Copy link
Contributor

@LaansDole LaansDole commented Mar 16, 2026

Context

Memory embeddings were being stored with inconsistent dimensions.

What's changing

  1. embedding.py - Dynamic fallback dimension
    Instead of hardcoding 1536, a _fallback_dim attribute is set to 1536 initially, then updated to the real dimension after the first successful API call:
self._fallback_dim = 1536  # Default; updated after first successful call
# After a successful embed:
embedding = response.data[0].embedding
self._fallback_dim = len(embedding)  # e.g., now 768
return embedding
# All fallback paths now use:
return [0.0] * self._fallback_dim  # matches model's actual dim
  1. file_memory.py - Dimension validation at retrieval
    Even if old corrupt data exists, retrieve() now skips mismatched embeddings instead of crashing:
expected_dim = query_embedding.shape[1]
for item in self.contents:
    if item.embedding is not None:
        if len(item.embedding) != expected_dim:  # ← NEW guard
            logger.warning("Skipping memory item %s: dim %d != expected %d", ...)
            continue
        memory_embeddings.append(item.embedding)
  1. Makefile - make check-backend for Quality Checks in the future project's consistency

@LaansDole LaansDole changed the title Main Fix: Hardcoded embedding dimension Mar 16, 2026
@LaansDole LaansDole changed the title Fix: Hardcoded embedding dimension Fix: hardcoded embedding dimension Mar 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant