Skip to main content
Die meisten Teams nutzen eine generische Embedding-API und hoffen, dass sie ihre Domäne versteht. Conares Position ist eine andere: das Embedding-Modell ist Teil des Retrieval-Stacks, kein Commodity-Input – und die stärkste Version davon ist eine, die auf Ihren eigenen Daten trainiert wurde. Conare Embeddings gibt es in zwei Schichten:

Gehostete API

POST /api/v1/embeddings – Abfrage- und Dokumentvektoren aus genau dem selbstgehosteten Modell, das Conare verwendet. Heute in jedem Tarif verfügbar.

Custom Models

Ein auf Ihren Daten fein-abgestimmtes Embedding-Modell, an Ihren echten Queries akzeptanz-gated, ausgeliefert mit eigenem Reranker. Vertriebsgeführt.

​
Warum Vektoren aus demselben Modell wichtig sind

Die Retrieval-Qualität verschlechtert sich stillschweigend, wenn die Vektoren in Ihrem Index und die Vektoren zur Abfragezeit aus verschiedenen Repräsentationen stammen. Die gehostete API gibt Vektoren aus demselben Modell zurück, mit dem Conare abruft – was sie zur richtigen Wahl macht, wenn:
  • Sie Ihre eigenen Vektor-Features (Clustering, Deduplizierung, Ähnlichkeits-Heuristiken) neben dem Conare-Gedächtnis oder ConareDB aufbauen und die Repräsentationen übereinstimmen müssen;
  • Sie Modell-Pinning-Semantik wünschen – eine explizite Garantie, dass Vektoren aus einem anderen Modell niemals stillschweigend in Ihren Index eingesetzt werden.

​
Warum Custom Models existieren

Ein generisches Modell verteilt seine Kapazität auf jede Domäne im Internet. Ihre Queries leben in einer Domäne – dem Vokabular Ihres Produkts, der Ausdrucksweise Ihrer Kunden, der Struktur Ihrer Dokumente. Fein-Abstimmung auf diese Verteilung bewegt zuverlässig die Metriken, die zählen (Recall auf Ihren echten Queries, Ranking-Qualität, Erkennen, wenn es keine Antwort gibt) – und Conare bringt ein Custom Model nur dann heraus, wenn es nachweislich den Vorgänger auf Ihrer eigenen Auswertungs-Menge schlägt, niemals auf Vertrauensbasis. Lesen Sie wie die Zusammenarbeit funktioniert.