Skip to content

Save embedding_model_name in the Chunk node - #575

Open
stellasia wants to merge 3 commits into
neo4j:mainfrom
stellasia:estelle/save-model-and-dimension-in-chunks
Open

Save embedding_model_name in the Chunk node#575
stellasia wants to merge 3 commits into
neo4j:mainfrom
stellasia:estelle/save-model-and-dimension-in-chunks

Conversation

@stellasia

@stellasia stellasia commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Description

What

Save the embedding model name in the Chunk node.

How

  • Add a model (+ dimensions) attribute to all Embedder classes
  • Add properties / warnings for backward compatible changes -> only breaking change for users using a custom Embedder

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Documentation update
  • Project configuration change

Complexity

Complexity:

How Has This Been Tested?

  • Unit tests
  • E2E tests
  • Manual tests

Checklist

The following requirements should have been met (depending on the changes in the branch):

  • Documentation has been updated
  • Unit tests have been updated
  • E2E tests have been updated
  • Examples have been updated
  • New files have copyright header
  • CLA (https://neo4j.com/developer/cla/) has been signed
  • CHANGELOG.md updated if appropriate

@stellasia
stellasia requested a review from a team as a code owner July 22, 2026 14:35
@stellasia stellasia changed the title Save embedding_model_name and embedding_dimensions in the Chunk node Save embedding_model_name in the Chunk node Jul 27, 2026
Comment thread CHANGELOG.md

- `AnthropicLLM` now supports structured output via the `response_format` argument, accepting a Pydantic model or an Anthropic `output_config` dict, alongside `OpenAILLM` and `VertexAILLM`.
- Chunk node metadata now contains `embedding_model_name` and `embedding_dimensions

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be misreading this — the changelog says chunk metadata now holds embedding_model_name and embedding_dimensions, but I can only find embedding_model_name being set in components/embedder.py. Was embedding_dimensions meant to land too? If so it looks like a one-liner and would be genuinely handy; if not, just checking the wording before we ship it. (Also the entry's missing a closing backtick on embedding_dimensions.)

"""
embedding = self._embedder.embed_query(text_chunk.text)
metadata = text_chunk.metadata if text_chunk.metadata else {}
metadata["embedding"] = embedding

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question — _async_embed_chunk sets embedding_model_name but _embed_chunk doesn't. I might be missing something, but run() looks like it always goes async and I couldn't find any callers of the sync method, so I'm guessing this doesn't matter in practice.
Curious whether the intent is to keep them in sync anyway, or the sync path is on its way out.

embedding = await self._embedder.async_embed_query(text_chunk.text)
metadata = text_chunk.metadata if text_chunk.metadata else {}
metadata["embedding"] = embedding
metadata["embedding_model_name"] = getattr(self._embedder, "model", None)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small one — since getattr(embedder, "model", None) defaults to None, a custom embedder with no model would store embedding_model_name: None rather than omit the key. Curious if that's deliberate (predictable schema) or if it'd be cleaner to skip the key when there's no model. Either's fine by me.

super().__init__(rate_limit_handler)
self.model_id = model_id
self.dimensions = dimensions
super().__init__(model_id, dimensions, rate_limit_handler)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I right that Bedrock is staying on model_id for now, with model exposed as a deprecated read-only property? If so, the changelog's "subclasses now require a model argument" note doesn't quite cover it. Not sure whether keeping Bedrock on model_id is intentional or it's meant to move across like the others — whichever way you want to go, I'm happy to accommodate.

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.

2 participants