In diesem Beitrag
Parallel Decisions API: RAG für Entscheidungsmodelle in der Praxis
Ein Anbieter führt am Montag eine Funktion ein. Am Freitag stuft dein Prüfprozess sie noch als nicht verfügbar ein, weil das Modell die Ankündigung nie erhalten hat. Auch eine formal korrekte JSON-Antwort kann auf veralteten Informationen beruhen.
Parallel Decisions API verbindet Websuche und klar begrenzte Fragen in einer Anfrage. Du übergibst Kontext und die Antwortoptionen, die deine Anwendung verarbeiten kann. Die API sucht öffentliche Belege und liefert typisierte Antworten. Bevor deine Anwendung daraus eine Entscheidung ableitet, prüft sie, ob die Quellen zum konkreten Produkt, Tarif und Zeitpunkt passen.
Parallel hat die API am 25. Oktober 2026 angekündigt. Der Launch-Beitrag zur Decisions API beschreibt den kombinierten Ablauf. Quellen geprüft: . Wir haben Dokumentation und API-Schema geprüft und das beigefügte Beispiel mit künstlichen Testantworten offline getestet. Wie genau und schnell die API live antwortet, haben wir dabei nicht gemessen.
Was bedeutet RAG für Entscheidungsmodelle?
RAG für Entscheidungsmodelle bedeutet, vor der Antwort auf eine festgelegte Frage passende Belege abzurufen. Das Ergebnis kann eine Kategorie, eine Wahrscheinlichkeit oder ein Wert auf einer geordneten Skala sein. Parallel übernimmt die Recherche innerhalb der Anfrage. Deine Anwendung kann die Entscheidung direkt anfordern.
Der offizielle Decisions-Quickstart beschreibt den gemeinsamen state, benannte questions und typisierte Antworten. Recherche und Klassifizierung werden über eine gemeinsame API angeboten.
Jev bewertet typisierte Fragen anhand des übergebenen Zustands. Das erläutert TypeSafes Einführung. Du kannst aktuelle Belege selbst abrufen und als Teil dieses Zustands übergeben. Unser Leitfaden zum Entscheidungsmodell Jev erklärt die Schnittstelle. Parallel bündelt die Recherche mit dem Entscheidungsdienst.
Wann lohnt sich Parallel statt einer separaten Recherche?
Nutze den integrierten Endpunkt, wenn du eine kurze Antwort zu öffentlichen Informationen brauchst und seine Recherchefunktionen zur Aufgabe passen. Eine separate Retrieval-Schicht ist sinnvoll, wenn du den Datenbestand selbst auswählen, Zugriffsrechte durchsetzen oder genau festlegen musst, welche Textstellen das Modell erhält.
| Ansatz | Herkunft der Belege | Geeignet für | Deine verbleibende Aufgabe |
|---|---|---|---|
| Entscheidungsmodell mit übergebenem Zustand | Deine Anwendung liefert die relevanten Fakten | Support-Tickets oder bekannte Datensätze klassifizieren | Den übergebenen Zustand aktuell und vollständig halten |
| Separate Recherche plus Entscheidungsmodell | Ein von dir konfigurierter Retriever, anschließend das gewählte Modell | Interne Dokumente, Vorgaben zu Herausgebern oder genaue Herkunftsnachweise | Recherchequalität, Zugriffsprüfung, Modellintegration und Auswertung |
| Parallel Decisions API | Öffentliche Webquellen, die der Dienst selbst abruft | Anbieterfunktionen prüfen, Unternehmen einordnen und aktuelle Fakten verifizieren | Fragen formulieren, Belege prüfen und Regeln für Folgeaktionen festlegen |
Bei internem Unternehmenswissen müssen Zugriffsrechte geprüft werden, bevor die Belege an das Modell gehen. Unser Leitfaden zu RAG mit Berechtigungen für SharePoint, Confluence und Drive erklärt diese Architektur.
Was liefert die Parallel Decisions API zurück?
Parallel liefert für jede benannte Frage eine typisierte Antwort und für die gesamte Anfrage eine gemeinsame Quellenliste. Der Typ für eine Ja-Nein-Bedingung heißt noul. Eine Choice wählt eine vorgegebene Option; ein Score bewertet anhand geordneter Kriterien. Jede Frage kann auch eine Antwortverweigerung zurückgeben. Prüfe deshalb zuerst den Antworttyp und danach den Wert.
| Typ | Definition der Frage | Antwort | Bedeutung |
|---|---|---|---|
noul | Eine Bedingung in instructions | noul zwischen 0 und 1 | Geschätzte Wahrscheinlichkeit, dass die Bedingung zutrifft |
choice | Ein criteria-Objekt mit benannten Optionen | choice und probabilities | Eine ausgewählte Kategorie samt Wahrscheinlichkeitsverteilung |
score | Ein geordnetes criteria-Array | score, legend und probabilities | Nach Wahrscheinlichkeit gewichteter Mittelwert der bei null beginnenden Stufenindizes |
refusal | Bei jeder Frage möglich | Kein Entscheidungswert und keine Wahrscheinlichkeiten | Ein eigener Ausgang, den die Anwendung behandeln muss |
Die Dokumentation der Fragetypen empfiehlt eine ausdrückliche unknown-Option, wenn Belege fehlen können. Das ist etwas anderes als eine Antwortverweigerung, die etwa durch nachgelagerte Filter entstehen kann. Fehlende Dokumentation darf nicht stillschweigend zur sicheren Aussage werden, eine Funktion sei nicht verfügbar.
Im veröffentlichten OpenAPI-Schema ist confidence bei Choice- und Score-Antworten optional und darf null sein. Die noul-Antwort hat kein separates Konfidenzfeld. Speichere die Wahrscheinlichkeit der ausgewählten Option getrennt von einem zurückgegebenen Konfidenzwert. Das übergeordnete citations-Array kann leer sein und ordnet Quellen keiner einzelnen Antwort zu.
Parallel und OpenAI bieten beide ein Produkt namens Decisions API an. Prüfe deshalb Host und Anfrageformat, bevor du Code zwischen ihnen übernimmst. Unser Routing-Leitfaden zur OpenAI Decisions API behandelt deren Schnittstelle. Das folgende Beispiel ruft api.parallel.ai auf.
Wie prüfst du einen Anbieter, ohne seine Produkte zu verwechseln?
Nenne in jeder Funktionsfrage das konkrete Produkt, den Tarif und den Zeitpunkt. Eine Ankündigung des Anbieters kann nur für eine seiner APIs gelten. Stelle die Produktfragen im gemeinsamen Anbieterkontext und biete eine unknown-Option für fehlende, unklare oder widersprüchliche Belege an.
Angenommen, du prüfst, für welche Parallel-APIs eine Verarbeitung in der EU im Rahmen einer Enterprise-Vereinbarung dokumentiert ist. Das Beispiel fragt getrennt nach Search im basic-Modus und nach Decisions. Beide Fragen betreffen Produkte unter derselben Vereinbarung.
Sende dieses JSON an POST https://api.parallel.ai/v1/decisions, mit Content-Type: application/json und deinem serverseitigen x-api-key:
{
"mode": "fast",
"state": {
"company": "Parallel",
"website": "https://parallel.ai",
"agreement": "Enterprise agreement",
"as_of": "2026-11-03"
},
"questions": {
"search_eu": {
"type": "choice",
"instructions": "Does Parallel document EU processing for Search API in basic mode (POST /v1/search) under an enterprise agreement, as of state.as_of? Evaluate this endpoint only; do not transfer a claim about another product.",
"criteria": {
"documented_yes": "Official documentation explicitly supports this endpoint, mode and agreement.",
"documented_no": "Official documentation explicitly excludes this endpoint or requires processing outside the EU.",
"unknown": "Evidence is missing, conflicting, ambiguous, outdated or applies to a different endpoint."
}
},
"decisions_eu": {
"type": "choice",
"instructions": "Does Parallel document EU processing for Decisions API (POST /v1/decisions) under an enterprise agreement, as of state.as_of? Evaluate this endpoint only; do not transfer a claim about another product.",
"criteria": {
"documented_yes": "Official documentation explicitly supports this endpoint, mode and agreement.",
"documented_no": "Official documentation explicitly excludes this endpoint or requires processing outside the EU.",
"unknown": "Evidence is missing, conflicting, ambiguous, outdated or applies to a different endpoint."
}
}
},
"advanced_settings": {
"include_excerpts": true
}
}Der Praxisleitfaden zu Decisions empfiehlt, verwandte Fragen mit gemeinsamen Belegen zu bündeln. Die Aufforderung, offizielle Dokumentation zu verwenden, lenkt das Modell, setzt aber keine technische Quellen-Allowlist durch. Das Feld as_of liefert Kontext für die Aufgabe. Historische Momentaufnahmen und Vorgaben zum Abrufzeitpunkt benötigen eigene Unterstützung.
Node.js-Beispiel für die Anbieterprüfung herunterladen, für Node.js ab Version 22. Es enthält den Request-Builder, die Timeout-Behandlung und die Antwortprüfung. Das JSON oben entspricht seinem Standarddatum, dem 3. November 2026. Der folgende Aufruf setzt ausdrücklich das heutige UTC-Datum ein. Speichere das Modul neben einer Datei run-example.mjs mit diesem Inhalt:
import {
buildRequest, requestDecision, reviewAnswer
} from "./parallel-decisions-vendor-screen.mjs";
const request = buildRequest(new Date().toISOString().slice(0, 10));
const response = await requestDecision(request, {
apiKey: process.env.PARALLEL_API_KEY
});
for (const name of Object.keys(request.questions)) {
console.log(name, reviewAnswer(response, name));
}Führe node run-example.mjs aus und hinterlege deinen Schlüssel als Umgebungsvariable. Der Aufruf sendet eine API-Anfrage zum veröffentlichten Tarif. Der Import des Moduls allein sendet keine Anfrage. Die Offline-Tests prüfen das Verhalten der Anwendung mit künstlichen Antworten, nicht die Qualität der Webrecherche.
Wie sollte deine Anwendung gemeinsame Quellen nutzen?
Behandle Parallels Quellenliste als gemeinsame Belege, die noch geprüft werden müssen. Bevor du eine Funktion als bestätigt übernimmst, prüfe eine passende Textstelle auf Endpunkt, Vereinbarung, Region und Datum. Ordne diese Textstelle dann der einzelnen Aussage in deinem Workflow zu. Eine Quelle in der gemeinsamen Liste kann nur eine der Fragen belegen.
| Beobachtetes Ergebnis | Bedeutung | Nächster Schritt |
|---|---|---|
| Dokumentiertes Ja oder Nein, gültige Verteilung, nutzbare Quellenauszüge | Eine formal vollständige Klassifizierung mit möglichen Belegen | Prüfen, ob eine Textstelle genau diese Aussage stützt |
unknown | Die vorgegebene Belegkategorie bleibt ungeklärt | Bessere Belege anfordern oder den Anbieter kontaktieren |
refusal | Der Dienst hat die Beantwortung dieser Frage verweigert | Die Verweigerung erfassen und zur Prüfung weiterleiten |
| Fehlende Antwort, fehlerhafte Verteilung oder Transportfehler | Der Integration liegt keine nutzbare Antwort vor | Den Datensatz ungeklärt lassen; Fehler untersuchen oder begrenzt erneut versuchen |
| Leere Quellenliste oder keine nutzbaren Auszüge | Dem Beispiel fehlen prüfbare Belege | Belege separat abrufen, bevor die Aussage übernommen wird |
Das Hilfsmodul verlangt HTTPS-Quellen ohne eingebettete Zugangsdaten und mindestens einen nicht leeren Auszug. Das sind lokale Prüfregeln, die wir für dieses Beispiel gewählt haben. Sind sie erfüllt, lautet der Status evidence_review. Er kennzeichnet einen Eintrag zur Quellenprüfung. Einen späteren Schwellenwert für automatische Entscheidungen solltest du anhand beschrifteter Anwendungsfälle festlegen.
Bewahre die ursprüngliche Verteilung, den optionalen Konfidenzwert, decision_id, die Anfrageversion und den Empfangszeitpunkt der Antwort auf. Erfasse Veröffentlichungs- und Abrufzeitpunkte der Quellen separat, soweit verfügbar. Eine Seite zur EU-Verarbeitung von Search könnte beide Klassifizierungen begleiten und nur eine davon stützen. Die Zuordnung zu einzelnen Feldern braucht eine eigene Prüfung.
Was kostet das Bündeln mehrerer Fragen?
Parallel nennt für Decisions einen Preis von 1 US-Dollar je 1.000 Anfragen mit bis zu 100 Fragen pro Anfrage. Verwandte Prüfungen zum selben Anbieter zu bündeln, kann die Anfragekosten senken. Prüfe vor der Budgetplanung den aktuellen Tarif.
Die offizielle Preisseite nennt diesen Tarif zum Prüfdatum 3. November 2026. Beispielrechnung: Bei 10.000 Anbietern mit jeweils drei verwandten Fragen ergibt eine Anfrage pro Anbieter 10.000 × 0,001 US-Dollar = 10 US-Dollar an ausgewiesenen Anfragekosten. Drei Anfragen pro Anbieter ergeben 30.000 × 0,001 US-Dollar = 30 US-Dollar.
Diese Rechnung berücksichtigt weder Wiederholungen noch Infrastruktur, weitere Recherche oder menschliche Prüfung. Erfasse neben den API-Ausgaben auch die Kosten je akzeptiertem Datensatz mit belegten Aussagen.
Bündle verwandte Fragen zur selben Entität. Teile Anfragen auf, sobald sich die Belege nur schwer zuordnen lassen oder eine Frage erst mit dem Ergebnis einer anderen formuliert werden kann.
Kannst du aktuelle Quellen oder EU-Verarbeitung erzwingen?
Die geprüfte Decisions-Schnittstelle dokumentiert weder eine garantierte Quellenaktualität noch eine Verarbeitung in der EU. Ihre erweiterten Einstellungen bieten Suchregion und Auszüge. Technisch durchgesetzte Herausgeber-Allowlists, Filter für Veröffentlichungsdaten und Abrufrichtlinien sind für diesen Endpunkt nicht dokumentiert.
Parallels Source-Policy-Leitfaden dokumentiert Domain- und Aktualitätsvorgaben für andere APIs. Wenn solche Vorgaben zu deinen Abnahmekriterien gehören, rufe die Belege über eine passende API ab und übergib sie einem separaten Entscheidungsschritt.
Die Dokumentation zur Datenresidenz in der EU umfasst Search im basic-Modus und Extract unter einer Enterprise-Vereinbarung. Für Decisions brauchst du eine gesonderte Bestätigung. Das Feld advanced_settings.location bestimmt die geografische Ausrichtung der Suche. Der Verarbeitungsort ist eine eigene Anforderung.
Halte bei zeitbezogenen Prüfungen fest, was die Quelle aussagt und wann die Aussage gilt. Historische Entscheidungen benötigen aufbewahrte Belege oder ein geeignetes Archiv. Prüfe Anbieter und Datenfluss, bevor du private Kundendokumente in einen Test aufnimmst.
Was belegen die Benchmarks?
Parallels Benchmark vergleicht vollständige API-Konfigurationen mit unterschiedlichem Zugang zu Webquellen. Die Ergebnisse helfen dir, einen Vergleichsaufbau für die eigene Aufgabe zu wählen. Die Genauigkeit der zugrunde liegenden Klassifikatoren lässt sich daraus nicht isoliert ableiten.
Die veröffentlichte Methodik von PWS-Decisions beschreibt 300 Fragen, davon 100 öffentlich und 200 nicht öffentlich. Die anderen nativen Entscheidungsendpunkte erhielten denselben Zustand und dieselben Fragen, aber keine zusätzlich abgerufenen Webbelege. Berücksichtige diese Konfiguration beim Lesen des Vergleichs.
Für drei Durchläufe vom 29. Oktober 2026 mit jeweils 300 Fragen berichten Parallels dokumentierte Ergebnisse eine Genauigkeit von 76,22 % für den eigenen Endpunkt und 97,33 % für eine separate Luna-Konfiguration mit nativer Websuche. Für die Konfiguration mit Websuche wurden höhere Kosten und Latenzen berichtet. Das sind Anbietermessungen auf diesem Testdatensatz. Vergleiche vollständige Abläufe, wenn du deinen Referenzaufbau auswählst.
Wie würden wir das vor dem Rollout prüfen?
Wir würden prüfen, ob jede Klassifizierung durch die richtigen Belege gestützt wird, bevor sie einen geschäftlichen Datensatz verändert. Beginne mit einem Entscheidungstyp und datierten Referenzfällen. Nimm klare positive und negative Fälle auf, aber auch solche, die ungeklärt bleiben müssen. Lass den Kandidaten parallel zum bestehenden Ablauf laufen, bis du seine Fehler nachvollziehen kannst.
| Testfall | Was die Prüfung erkennen soll |
|---|---|
| Eine kürzlich eingeführte oder gestrichene Funktion | Ob die Klassifizierung die maßgebliche Quelle und den gültigen Zeitpunkt berücksichtigt |
| Dasselbe Unternehmen, anderer Tarif oder Endpunkt | Ob aus einer allgemeinen Ankündigung eine unbelegte Produktaussage entsteht |
| Fehlende oder widersprüchliche Dokumentation | Ob der Ablauf Unsicherheit erhält, statt eine negative Antwort zu erfinden |
| Eine plausible Quelle zu einer anderen Entität | Ob die Quellenprüfung eine glaubwürdig klingende Antwort mit falschem Beleg erkennt |
| Quellen in jeder Sprache des Produktivbetriebs | Ob übersetzte Produktnamen und Einschränkungen zur gleichen Entscheidung führen |
Beschrifte die erwartete Antwort und ihre stützende Textstelle getrennt. Berichte, wie oft akzeptierte Datensätze korrekt und belegt sind, wie viele eine Prüfung benötigen und welche falschen Datensätze ungeprüft durchgehen. Miss die Latenz des gesamten Ablaufs und die Kosten bis zum fertigen Datensatz, einschließlich Nacharbeit.
Wir würden mit einer klar begrenzten Anbieterprüfung oder Datenanreicherung und einer ausdrücklichen Quellenprüfung starten. Lege zuerst die Entscheidung und die Kosten einer Fehlentscheidung fest. Wenn du daraus einen Produktablauf entwickeln möchtest, ist unsere KI-Produkt- und Agentenentwicklung der passende nächste Schritt.
Fragen zur Parallel Decisions API
Kann ich Parallel Decisions über MCP ausprobieren?
Der geprüfte Quickstart nennt das Tool web_decisions im MCP-Server von Parallel unter https://mcp.parallel.ai/mcp. Die Nutzung ist ohne Konto oder API-Schlüssel kostenlos möglich; nach Anmeldung oder Authentifizierung gelten höhere Limits. Das ist ein Zugang für MCP-Clients. Das direkte HTTP-Beispiel in diesem Artikel benötigt deinen API-Schlüssel und verwendet den veröffentlichten Anfragetarif.
Kann ich eine noul-Wahrscheinlichkeit als Boolean verwenden?
Eine noul-Antwort ist eine Zahl zwischen 0 und 1. In JavaScript gilt selbst ein kleiner Wert ungleich null als truthy. Eine if-Abfrage über den Rohwert ist deshalb ungeeignet. Definiere und prüfe eine ausdrückliche Entscheidungsregel. Wenn bei Dokumentationsprüfungen fehlende Belege relevant sind, bildet eine Choice mit unknown-Option die Aufgabe meist klarer ab.
Kann eine Frage von einer anderen Antwort derselben Anfrage abhängen?
Bündle Fragen, wenn sich jede anhand des gemeinsamen Zustands formulieren lässt. Braucht Frage B erst den Rückgabewert von Frage A, empfehlen wir: auf A warten, die Antwort prüfen und B in einer Folgeanfrage formulieren. Behandle das questions-Objekt nicht wie ein sequenzielles Programm. Die Reihenfolge der Schlüssel begründet keine Abhängigkeit.
Kann Parallel Decisions mein CRM automatisch aktualisieren?
Die Antwort liefert Daten für deine Anwendung. Eine separate Integration muss die CRM-Änderung autorisieren und ausführen. In unserem Beispiel ist evidence_review ein Status zur Prüfung der Belege, keine Erlaubnis, einen Anbieter als freigegeben zu markieren. Verknüpfe eine spätere Änderung mit der geprüften Aussage und genau der Datensatzversion, die du ändern wolltest.
Entspricht ein Score immer genau einer Bewertungsstufe?
Nein. Ein Score ist der nach Wahrscheinlichkeit gewichtete Mittelwert der bei null beginnenden Stufenindizes. Er kann zwischen Stufen liegen. Wahrscheinlichkeiten von 0,25 und 0,75 für die Stufen 0 und 1 ergeben beispielsweise 0,75. Interpretiere den Wert anhand deiner Kriterien. Nutze Choice, wenn die Anwendung eine einzelne Kategorie statt eines Durchschnitts benötigt.
Sollte ich deutsche, spanische und chinesische Quellen getrennt testen?
Wir empfehlen Tests für jede Sprache, die dein Workflow verarbeitet. Ein Produkt kann je nach Sprache andere Tarifnamen verwenden oder eine Änderung zuerst in einer Sprache veröffentlichen. Verknüpfe Referenzantworten mit datierten Belegen und prüfe Einschränkungen, deren Bedeutung sich bei der Übersetzung verändern kann. Gute Ergebnisse mit englischen Testdaten belegen nicht dieselbe Quellenqualität in einer anderen Sprache.