Skip to main content
Die meisten Teams nutzen eine generische Embedding-API und hoffen, dass sie ihre Domäne versteht. Conares Position ist anders: Das Embedding-Modell ist Teil des Retrieval-Stacks, kein Commodity-Input – und seine stärkste Ausprägung ist eines, das auf deinen eigenen Daten trainiert wurde. Conare Embeddings kommt in zwei Ebenen:

Hosted API

POST /api/v1/embeddings – Vektoren im Dokumentenraum aus genau dem selbst gehosteten Modell, das Conare-Memories indiziert und retrievt. Heute in jedem Plan verfügbar.

Custom Models

Ein auf deinen Daten fine-getuntes Embedding-Modell, akzeptanzgeprüft anhand deiner echten Queries, samt eigenem Reranker. Sales-led.

​
Warum Vektoren aus demselben Modell wichtig sind

Retrieval-Qualität leidet still, wenn die Vektoren in deinem Index und die Vektoren zur Query-Zeit aus unterschiedlichen Repräsentationen stammen. Die Hosted-API liefert Vektoren aus demselben Modell, mit dem Conare retrievt – die richtige Wahl, wenn:
  • du eigene Vektor-Features (Clustering, Dedup, Ähnlichkeits-Heuristiken) neben Conare Memory oder ConareDB baust und die Repräsentationen zueinander passen müssen;
  • du Model-Pinning-Semantik willst – die explizite Garantie, dass Vektoren aus einem anderen Modell nie stillschweigend in deinen Index gemischt werden.

​
Warum es Custom Models gibt

Ein generisches Modell verteilt seine Kapazität auf jede Domäne im Internet. Deine Queries leben in einer Domäne – im Vokabular deines Produkts, in der Sprache deiner Kunden, in der Struktur deiner Dokumente. Fine-Tuning auf dieser Verteilung bewegt zuverlässig die Metriken, die zählen (Recall auf deinen echten Queries, Ranking-Qualität, das Erkennen, wenn es keine Antwort gibt) – und Conare rollt ein Custom-Modell nur aus, wenn es nachweislich das bestehende auf deinem eigenen Evaluations-Set schlägt, nie im Vertrauen. Lies, wie das Engagement abläuft.