Embeddings y RAG

POST /v1/embeddings. Scope: embeddings:invoke.

{ "model": "callsist-embed-1", "input": ["texto 1", "texto 2"], "dimensions": 768 }

• input: cadena o array. Máximo 256 elementos por petición.
• dimensions: opcional. Por defecto 768. Si lo pides distinto y el proveedor devuelve otra cosa, la petición falla en vez de guardar vectores de dimensión equivocada.
• Ventana: 32 000 tokens.

{
  "object": "list",
  "model": "callsist-embed-1",
  "data": [ { "object": "embedding", "index": 0, "embedding": [0.0123, -0.0456] } ],
  "usage": { "prompt_tokens": 412, "total_tokens": 412 }
}

El orden de data corresponde al de input por el campo index, no por la posición del array.

Precio: 0,28 €/M tokens. Reembeber una base de conocimiento de un millón de tokens cuesta 0,28 €; no es ahí donde está el gasto.

Callsist no almacena ni busca vectores

No es una carencia pendiente de tapar: un almacén de vectores es un producto distinto, con su propio ciclo de vida, sus copias de seguridad y su modelo de permisos. Preferimos no fingir que lo tenemos.

El patrón completo

1. POST /v1/embeddings          ← embeber los documentos, una vez
2. (tu almacén)                 ← guardar los vectores, dimensión 768
3. POST /v1/embeddings          ← embeber la consulta
4. (tu almacén)                 ← recuperar los k fragmentos más cercanos
5. POST /v1/chat/completions    ← prompt + fragmentos, con response_format json_object

El paso que la gente se salta es el 2 con la dimensión correcta: si tu tabla de pgvector está declarada como vector(1536) porque venías de otro proveedor, la inserción falla o —peor— truncas. 768.

Reembeber cuando cambie el modelo

Los vectores de dos modelos distintos no son comparables. Si algún día callsist-embed-1 se sustituye por otro identificador, hay que reembeber la colección entera: mezclar vectores de dos modelos en el mismo índice da resultados que parecen funcionar y no lo hacen.

A 0,28 €/M tokens, reembeber es la parte barata del problema; lo caro es no darse cuenta.