Betreiben wir eine Vector Database?

Nein. Legen Sie Dokumente in eine Collection, und die Plattform extrahiert, chunked und indexiert sie im Hintergrund. Es gibt keinen Store zu betreiben und keine Pipeline zu warten.

Können Inhalte des einen Teams in Antworten des anderen auftauchen?

Nein. Jede Collection ist eine eigene Partition, auf Ihre Organisation und Workspace genamespaced, bevor die Query gebaut wird.

Müssen wir Retrieval selbst aufrufen?

Nein. Retrieval läuft, sobald die Workspace etwas zum Nachschlagen hat. Es gibt keinen rag-Parameter und keine Collection, die in der Request stehen müsste.

Wie zeigen wir, woher eine Antwort kommt?

Die Response trägt ein sources-Array mit den Dokumenten und Passagen, die sie benutzt hat, und deren Relevanz.

Wo werden die Dokumente verarbeitet?

In der EU. Die Embedding-Modelle und der Graph sind EU-resident, und jede Request hält die Region fest, die sie bedient hat.

RAG-Anwendungen

Retrieval-Anwendungen ohne die Rohrleitungen.

Bauen Sie Anwendungen, die aus Ihren eigenen Inhalten antworten und zeigen, worauf sie stehen. Legen Sie Dokumente in eine Collection, und jede Antwort kommt mit den Passagen zurück, die sie benutzt hat. Darunter nimmt Akumi sie in einen Knowledge Graph auf, der pro Workspace abgetrennt ist, eine Request kommt also nur an Ihre eigenen. Kein Vector Store zu betreiben, und nichts verlässt die EU.

Kostenlos starten Sprechen Sie uns an

Collections · ein Graph · EU-resident

Als Kontext an den Prompt gehängt, bevor das Modell antwortet.

RAG ist schnell demonstriert und ein Projekt im Betrieb.

Hinter einer laufenden Demo stecken eine Vector Database im Betrieb, eine Embedding-Pipeline in der Wartung, eine Chunking-Strategie zum Abstimmen, und oft eine US-Embeddings-API, die Ihre Dokumente außer Landes schickt. Und dann müssen Sie die Inhalte des einen Teams noch aus den Antworten des anderen halten und belegen, wo etwas davon verarbeitet wurde.

Was Sie bekommen

Retrieval als gemanagter Service.

Die Teile eines Retrieval-Stacks, die ein Quartal zum Bauen und ein Jahr zum Warten kosten, sind genau die Teile, die Sie hier nicht betreiben.

Keine Pipeline zu betreiben
Fügen Sie PDF, Text oder Markdown in eine Collection ein oder laden Sie es hoch. Die Plattform extrahiert, chunked und schreibt es im Hintergrund in den Knowledge Graph. Kein Vector Store, keine Embedding-Pipeline, keine Chunking-Strategie zum Abstimmen.
Abgetrennt by Design
Jede Collection ist eine eigene Partition des Graphen, auf Ihre Organisation und Workspace genamespaced, bevor die Query gebaut wird. Eine Request kommt nur an Ihre eigenen Partitionen, nie an die eines anderen Tenants, und der Graph bleibt in der EU.
Belegt und mit Quellen
Retrieval läuft von selbst, sobald die Workspace etwas zum Nachschlagen hat, und mischt Fakten, Dokumente und Collections zu einem gerankten Kontext. Die Response trägt die Quellen, die sie benutzt hat.

Wie das aussieht

Eine Request, von vorn bis hinten.

Der Support-Assistent eines Versicherers beantwortet eine Versicherungsnehmerin aus den eigenen Dokumenten des Teams. Sie schicken die Frage. Sie bekommen die Antwort, und die Passagen, auf denen sie steht.

01SchickenSie schicken eine FrageEine OpenAI-kompatible Call. Das user-Feld grenzt die persönliche Memory ab, und die Workspace und ihre Collections kommen aus dem API-Key.
02NachschlagenAkumi schlägt im Graphen nachRetrieval mischt die Memory dieser Endnutzerin, die Workspace und jede Collection darin, und rankt, was zurückkommt. Nichts zu orchestrieren.
03BelegenSie bekommen die BelegeDie Antwort kommt mit einem sources-Array, und die Request wird mit Modell, Provider und Region festgehalten, die sie bedient haben.

RequestPOST /v1/chat/completions{ "model": "mistral/mistral-small-2603", "user": "cust_8412", "messages": [ { "role": "user", "content": "Kann ich vorzeitig kündigen?" } ] }
Response200 OK{ "content": "Ja. Kündigen Sie schriftlich, die Erstattung erfolgt anteilig...", "sources": [ { "kind": "document", "title": "policenbedingungen.pdf", "relevance": 0.92, "matchCount": 2 }, { "kind": "document", "title": "kuendigung-sla.md", "relevance": 0.81 } ] }

Kein rag-Parameter, keine Retrieval-Call, keine Collection zu nennen.

Welcher Service macht was

Retrieval, und alles drumherum.

Eine echte Retrieval-Anwendung ist mehr als ein Similarity Lookup. Die Services, die sie braucht, sitzen hinter demselben Endpoint, jeder einzeln abgerechnet.

Alle neun Services auf der Plattform ansehen →

FAQ

Fragen zum Retrieval.

Betreiben wir eine Vector Database?: Nein. Legen Sie Dokumente in eine Collection, und die Plattform extrahiert, chunked und indexiert sie im Hintergrund. Es gibt keinen Store zu betreiben und keine Pipeline zu warten.
Können Inhalte des einen Teams in Antworten des anderen auftauchen?: Nein. Jede Collection ist eine eigene Partition, auf Ihre Organisation und Workspace genamespaced, bevor die Query gebaut wird.
Müssen wir Retrieval selbst aufrufen?: Nein. Retrieval läuft, sobald die Workspace etwas zum Nachschlagen hat. Es gibt keinen rag-Parameter und keine Collection, die in der Request stehen müsste.
Wie zeigen wir, woher eine Antwort kommt?: Die Response trägt ein sources-Array mit den Dokumenten und Passagen, die sie benutzt hat, und deren Relevanz.
Wo werden die Dokumente verarbeitet?: In der EU. Die Embedding-Modelle und der Graph sind EU-resident, und jede Request hält die Region fest, die sie bedient hat.

Hier anfangen

Liefern Sie Retrieval, lassen Sie die Infrastruktur aus.

Legen Sie einen Key an, legen Sie Ihre Dokumente in eine Collection, und Ihre Anwendung antwortet daraus.