Skip to content

fix(embeddings): handle compatible endpoints that return float arrays - #2150

Open
anishesg wants to merge 1 commit into
openai:mainfrom
proudhare:fix/ph-issue-1542
Open

fix(embeddings): handle compatible endpoints that return float arrays#2150
anishesg wants to merge 1 commit into
openai:mainfrom
proudhare:fix/ph-issue-1542

Conversation

@anishesg

@anishesg anishesg commented Aug 8, 2026

Copy link
Copy Markdown

Changes being requested

  • Fixed embedding dimension truncation when using OpenAI-compatible endpoints (ollama, LM Studio)
  • Added type check in src/resources/embeddings.ts to detect when embeddings are already returned as float arrays
  • Added regression test for endpoints that ignore the encoding_format parameter

Additional context & links

Some OpenAI-compatible endpoints like ollama and LM Studio ignore the encoding_format parameter and always return embeddings as float arrays instead of base64-encoded strings. The SDK was attempting to decode these arrays as base64, which caused Buffer.from() to interpret the array as bytes rather than a base64 string. For a 1024-element float array, this created a 1024-byte buffer, which when divided by 4 (Float32Array.BYTES_PER_ELEMENT) resulted in exactly 256 dimensions.

The fix adds an Array.isArray() check before attempting base64 decoding. If the embedding is already an array, it's used directly. Otherwise, it's decoded from base64 as before. This preserves backward compatibility with the official OpenAI API while supporting endpoints that return float arrays.

Fixes #1542

## Changes being requested

Signed-off-by: anish <anishesg@users.noreply.github.com>
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.

Embedding dimensions are truncated to 256 in some cases

1 participant