Claude Opus 4.7 für RAG: Wie ich das Modell mit echten Dokumenten getestet habe

🎯 Für wen lohnt sich Opus 4.7 in RAG überhaupt

Kurz gesagt: Nehmen Sie es nur, wenn die Kosten eines Fehlers in der Antwort hoch sind. Für ein internes FAQ ist es übertrieben, für einen juristischen Assistenten – in Ordnung, für einen Bot auf der Website eines Online-Shops – zu viel.

Ich habe Opus 4.7 am Tag nach der Veröffentlichung getestet. Daher werde ich nicht schreiben „Ich habe riesige Statistiken gesammelt“ – aber ich habe genügend reale Anfragen durchlaufen lassen, um die wichtigsten Dinge zu verstehen.

Hier ist, wem Opus 4.7 wirklich hilft:

• Anwaltskanzleien – dort, wo man klar sagen muss „Dieser Punkt ist im Vertrag nicht enthalten“, anstatt eine Antwort zu erfinden
• Finanzen und Buchhaltung – wenn ein Kunde nach einer bestimmten Zeile in einer Verordnung fragt und man darf sich nicht irren
• Medizinische Zentren – wo Antworten auf Protokollen basieren und eine Halluzination Gesundheit kosten kann
• Unternehmen, die planen, KI-Chats für öffentliche Kunden anzubieten und Angst vor Prompt Injection haben

Und hier sind diejenigen, denen ich empfehlen würde, einfach Llama 3.3 70B oder sogar etwas Einfacheres zu nehmen:

• Interne Assistenten für ein Team von 10-20 Personen
• FAQ-Bots für 30-50 typische Fragen
• Projekte, bei denen der Kunde preissensibel ist und ein oder zwei ungenaue Antworten verzeihen kann
• Alles mit strengen DSGVO-Anforderungen – Opus nur über API

Im Folgenden werde ich auf die Details eingehen – was genau das Modell in den Tests gezeigt hat, wie viel es kostet und wie ich es in meinen Dienst integriert habe. Wenn Sie die Übersicht über das Modell selbst noch nicht gelesen haben – dort finden Sie technische Spezifikationen, Benchmarks und Vergleiche mit GPT-5.4 und Gemini.

⚙️ Warum die Wahl des Modells nicht alles in RAG ist

LLMs sind nur die letzte Schicht. Wenn Sie schlechtes Chunking oder schwache Embeddings haben, wird selbst Opus 4.7 Sie nicht retten. Konfigurieren Sie zuerst die Suche, dann denken Sie über das Modell nach.

Ich schaue mir viele fremde RAG-Systeme an – und fast in jedem steckt derselbe Fehler. Der Entwickler schließt LangChain mit Standardeinstellungen an, wirft GPT-4 oder Claude hinein und fragt: „Warum halluziniert der Bot?“. Die Antwort: Weil dem Modell Müll zugeführt wird, deshalb erfindet es etwas.

In RAG gibt es drei kritische Schichten, und LLM ist die dritte, nicht die erste:

1. Wie Sie Dokumente in Stücke schneiden (Chunking). Eine Tabelle in der Mitte zerteilt – das Modell sieht den Kontext nicht. Einen juristischen Paragraphen zwischen zwei Chunks zerschnitten – Sie erhalten eine Antwort ohne Ausnahmen. Detailliert darüber habe ich in meinem Artikel über 7 Chunking-Strategien geschrieben – dort gibt es auch Forschungszahlen.
2. Welches Embedding-Modell Sie für die Suche verwenden. Hier gibt es die meisten Fehler – der Entwickler nimmt text-embedding-ada-002, weil „OpenAI eben“ und weiß nicht, dass es für denselben Preis Modelle mit doppelt so guter Qualität gibt. Ich habe die Auswahl von Embedding-Anbietern hier analysiert.
3. Das eigentliche LLM, das die Antwort aus dem Kontext generiert. Das ist dann Opus 4.7 oder eine Alternative.

Wenn die ersten beiden Schichten kaputt sind – Opus 4.7 wird das nicht beheben. Es wird stattdessen selbstbewusst eine falsche Antwort auf der Grundlage falscher Chunks liefern. Bevor Sie also über die Wahl zwischen Opus, Llama und Gemini nachdenken – überprüfen Sie, ob Ihr Retrieval überhaupt die richtigen Fragmente findet. Wenn Sie noch nie mit Vector Search zu tun hatten – beginnen Sie mit diesem Artikel für Anfänger.

📄 Was 1 Million Token Kontext in der Praxis bringt

Ja, der Kontext ist gigantisch. Nein, das bedeutet nicht, dass Sie alle Dokumente hineinwerfen und kein Chunking machen können. Großer Kontext ist kein Ersatz für Retrieval, sondern eine Unterstützung für komplexe Anfragen.

Opus 4.7 hat ein Kontextfenster von 1 Million Token. Das sind ungefähr 750 Seiten Text. Klingt verlockend: Man kann doch einfach die gesamte Wissensdatenbank in den Prompt werfen und sich keine Gedanken über Vector Search machen, oder?

Nein, so funktioniert es nicht. Deshalb verwende ich immer noch RAG:

• Kosten. 1 Million Input-Token kosten 5 $. Wenn Sie 1000 Anfragen pro Tag haben und in jeder die gesamte Datenbank übergeben – das sind 5000 $ pro Tag nur für den Input. Prompt Caching reduziert dies auf 90 %, aber es ist für die meisten Kunden immer noch teuer.
• Lost in the middle. Selbst Spitzenmodelle finden Informationen in der Mitte eines langen Kontexts schlechter. Stanford zeigte eine Verschlechterung des Recalls um bis zu 45 %. Werfen Sie 700 Seiten hinein – Sie erhalten Antworten basierend auf Anfang und Ende, und das Wichtige liegt irgendwo in der Mitte.
• Aktualisierung. In der Wissensdatenbank ändern sich Dokumente. In RAG indiziere ich einfach eine Datei neu. Bei „alles in den Kontext werfen“ – muss der gesamte Prompt neu aufgebaut werden.

Wo großer Kontext wirklich hilft – ist, wenn die Anfrage komplex ist und die Gegenüberstellung mehrerer Dokumente erfordert. Zum Beispiel fragt ein juristischer Kunde: „Vergleichen Sie die Haftungsklauseln in diesen drei Verträgen.“ Früher habe ich das über separate Retrieval-Anfragen und das Zusammenführen von Antworten gemacht. Mit Opus 4.7 kann ich alle drei Verträge vollständig hochladen und eine einzige Frage stellen. Die Qualität der Antwort ist merklich besser.

Praktische Aufteilung in AskYourDocs:

• Normale Anfragen – RAG mit Chunking und Top-K=5. Dem Modell werden nur relevante Chunks übergeben, Kontext 8-12K Token.
• Komplexe analytische Anfragen (Vergleiche, Analysen) – mehrere ganze Dokumente werden hochgeladen, Kontext 50-200K. Das ist teurer, aber der Kunde zahlt separat für „advanced query“.
• „Alles hineinwerfen“ – wird überhaupt nicht verwendet. Ich sehe kein Szenario, in dem dies gerechtfertigt wäre.

🎯 Halluzinationen: Was ich beim Vergleich mit Llama gesehen habe

Ich habe es in den Tests bemerkt. Opus 4.7 gibt ehrlich zu, wenn die Dokumente keine Antwort enthalten. Llama 3.3 70B kann eine plausible Erfindung liefern und nicht einmal zögern.

Ich habe auf einer Testdatenbank mit ca. 400 öffentlichen juristischen Dokumenten getestet – Musterverträge aus offenen Rechtsregistern, typische Verordnungen, Vorlagen von Vereinbarungen. Eine solche Sammlung verwende ich für meine eigenen Benchmarks verschiedener Modelle, da sie eine realistische Dokumentenstruktur ohne Risiko für die Vertraulichkeit anderer bietet. Ich habe ca. 30 verschiedene Anfragen geschrieben – einige mit Antworten in der Datenbank, einige absichtlich ohne.

Hier ist ein typisches Beispiel für den Unterschied:

Anfrage: „Wie lange ist die Kündigungsfrist ohne Vertragsstrafen für Kunden mit einem Firmenvertrag?“

In den Dokumenten gibt es keinen solchen Abschnitt – es gibt nur den Standardtarif und VIP.

Llama 3.3 70B: „Für Kunden mit einem Firmenvertrag beträgt die Kündigungsfrist ohne Vertragsstrafen 30 Tage ab Einreichung eines schriftlichen Antrags.“ Klingt selbstbewusst, die Zahl wirkt realistisch. Aber das ist eine vollständige Erfindung – dieser Punkt ist in keinem der 400 Dokumente enthalten.

Opus 4.7: „In den bereitgestellten Dokumenten habe ich keine gesonderten Bedingungen für Firmenverträge gefunden. Die Verträge enthalten Informationen über Standard- und VIP-Tarife – wenn Sie Details zu einem davon benötigen, kann ich antworten.“

Der Unterschied ist kritisch. Für einen Juristen ist die Llama-Antwort ein fertiges Problem: Der Kunde wird sie zitieren, dann stellt sich heraus, dass sie falsch ist. Opus sagt ehrlich, dass es nichts weiß und bietet an, zu klären.

Ich werde nicht schreiben „in 15% der Fälle hat Llama erfunden“ – das wäre bei einer so kurzen Testung irreführend. Aber die Tendenz ist bei jedem Dutzend Anfragen ohne Antwort in der Datenbank klar erkennbar. Und das stimmt mit dem überein, was Anthropic-Partner im Early Access schreiben: Hex hat diese Eigenschaft hervorgehoben – „das Modell meldet ehrlich die Abwesenheit von Daten anstelle von plausiblen Erfindungen“.

Zweitens Wichtiges: Opus 4.7 folgt dem System-Prompt buchstäblich. Wenn ich schreibe „antworte nur basierend auf dem bereitgestellten Kontext, verwende kein Allgemeinwissen“ – tut es das wirklich. Llama „schreibt bei mir regelmäßig etwas dazu“ basierend auf dem, was es aus dem Training weiß. Im juristischen Kontext ist das inakzeptabel.

💰 Was es in der Produktion wirklich kostet

Offizieller Preis 5 $/25 $ pro Million Token. Aber der neue Tokenizer hat mir 23 % mehr Kosten für dieselben Anfragen beschert. Llama 3.3 70B über OpenRouter ist 10-15 Mal günstiger. Für Massenkunden ist das ein entscheidender Unterschied.

Ich habe es auf einem typischen Kundenprofil von AskYourDocs berechnet: eine Anwaltskanzlei, ca. 20 Mitarbeiter, durchschnittliche Auslastung 1000 Anfragen pro Tag, durchschnittlicher Kontext aus dem RAG-Fenster 8-12K Token.

Die Zahlen sind ungefähre Angaben – sie hängen vom Caching, der Größe des System-Prompts, dem Anteil des Outputs ab. Aber die Größenordnung ist genau diese: Opus ist 10-15 Mal teurer als Llama.

Nun eine wichtige Details zum neuen Tokenizer von Opus 4.7. Unmittelbar nach der Ankündigung bat mich einer meiner Kunden, das neue Modell zum Testen anzuschließen – er wollte sehen, ob es die Qualität der Antworten auf seiner Datenbank verbessern würde. Ich habe ihn von 4.6 auf 4.7 umgestellt, indem ich einfach die Model-ID in der Konfiguration ausgetauscht habe – buchstäblich eine Zeile. Die Logik des Systems änderte sich nicht, die Prompts sind dieselben, die Dokumente sind dieselben. Aber die Kosten für die Verarbeitung derselben Anfragen stiegen um etwa 23 %. Derselbe Text – mehr Token. Anthropic warnt offiziell, dass es 1,0-1,35x für denselben Text sein wird, bei mir war es näher an der Obergrenze.

Was tun damit:

• Prompt Caching ist ein Muss. Wenn Sie einen stabilen System-Prompt und einen großen Kontext haben – gibt das Cache bis zu 90 % Rabatt auf gecachte Token. Bei mir hat das den Großteil des Anstiegs durch den neuen Tokenizer ausgeglichen.
• Batch API für Nicht-Echtzeit. Wenn der Kunde keine sofortige Antwort benötigt (z. B. nächtliche Dokumentenanalyse) – gibt Batch -50 % auf Input und Output.
• Task Budgets. Neue Funktion – ein harter Limit für die Token-Ausgaben für eine Aufgabe. Ein Muss, wenn Sie einen Agenten haben, der in eine Schleife geraten und das Monatsbudget in einer Stunde aufbrauchen kann.
• System-Prompt überarbeiten. Ich habe meinen um ca. 30 % gekürzt – Duplikate entfernt, ähnliche Anweisungen zusammengefasst. Für 4.7 ist das noch kritischer, da jeder zusätzliche Token teurer ist.

Mein praktischer Preset für Kunden, die von 4.6 auf 4.7 migrieren: Planen Sie für den ersten Monat +25 % zum API-Budget ein, optimieren Sie dann basierend auf realen Daten.

🔧 Mein System-Prompt für Document Q&A

Hier ist mein aktueller Prompt. Nicht perfekt, aber funktional – er hat in den letzten Tagen mehrere Iterationen durchlaufen:

Du bist ein KI-Assistent des Unternehmens [COMPANY_NAME] für interne Dokumentation.

DEINE AUFGABE:
Beantworte Fragen von Mitarbeitern ausschließlich auf Basis der Dokumente,
die ich dir im <context>-Block übergebe. Verwende keine allgemeinen
Kenntnisse über Jurisprudenz, Gesetze oder Standards – nur das,
was im bereitgestellten Kontext steht.

ANTWORTREGELN:
1. Wenn die Information im Kontext fehlt – sage es direkt:
   "In den bereitgestellten Dokumenten habe ich keine Antwort auf diese Frage gefunden."
   Erfinde nichts. "Rate" nicht. Nicht "nach allgemeinen Regeln".
2. Wenn die Antwort vorhanden ist – zitiere den Dokumentenausschnitt und gib die Quelle an
   (Dateiname, Abschnitts-/Punktnummer).
3. Wenn die Antwort teilweise ist – gib das Vorhandene an und sage klar, was fehlt:
   "Die Dokumente enthalten Informationen über X, aber nicht über Y."
4. Wenn die Frage juristisch komplex ist und eine Interpretation erfordert –
   interpretiere nicht. Sage: "Diese Frage erfordert eine Rechtsberatung,
   in den Dokumenten gibt es nur die Formulierung des Punktes: [Zitat]".

ANTWORTFORMAT:
- Zuerst eine direkte Antwort in 1-2 Sätzen.
- Dann – ein Zitat aus dem Dokument in Anführungszeichen.
- Am Ende – die Quelle im Format: [Datei.pdf, Abschnitt X.Y].

<context>
{retrieved_chunks}
</context>

Benutzerfrage: {user_question}

Warum genau so:

• Verbot der Nutzung von Allgemeinwissen – in den ersten Zeilen. Opus 4.7 folgt buchstäblich, also wenn man "vorwiegend auf Basis des Kontexts" schreibt, beginnt er, eigenes hinzuzufügen. "Nur auf Basis" – und Punkt.
• Genaues Szenario für "Ich weiß nicht". Ich gebe eine fertige Antwortphrase. Das Modell verwendet sie. Ohne dies könnte es schreiben "Leider sind die Informationen nicht ausreichend, aber ich werde versuchen zu raten" – und das ist bereits ein schlechtes Zeichen.
• Format der Zitierung. Ich verlange einen Verweis auf die Quelle – dann wird die Antwort vom Kunden manuell in Sekunden überprüft.
• Verbot juristischer Interpretation. Wichtig für den Rechtsbereich. Das Modell hat kein Recht, "Gesetze zu interpretieren" – das ist die Arbeit eines Anwalts. Es muss nur den Text zeigen.

Mit Llama 3.3 70B funktioniert derselbe Prompt schlechter. Das Modell ignoriert regelmäßig die Einschränkung "nur auf Basis des Kontexts" und fügt hinzu "nach der Standardinterpretation dieses Punktes...". Mit Opus 4.7 habe ich so etwas nicht gesehen – es gehorcht buchstäblich.

Wie das im Code auf Spring AI aussieht

Wenn Sie Spring Boot verwenden und OpenRouter für Flexibilität zwischen den Modellen nutzen – so sieht das ungefähr aus:

Ich werde nicht die gesamte Architektur des Dienstes in den Artikel aufnehmen – sie ist komplex und kommerziell sensibel. Aber zur Veranschaulichung zeige ich die Kernidee des Multi-Vendor-RAG auf Spring: Die Modellauswahl ist ein Wert in application.yml und kein Change Request im Code. Dank @ConditionalOnProperty wird der benötigte ChatClient geladen – Opus 4.7, Llama über OpenRouter oder lokales Ollama.

Modellkonfiguration über application.yml

# application.yml
rag:
  llm:
    provider: openrouter  # anthropic | openrouter | ollama
    model: anthropic/claude-opus-4.7
    temperature: 0.2
    max-tokens: 2048

  system-prompt: |
    Du bist ein KI-Assistent des Unternehmens. Antworte nur auf Basis
    des bereitgestellten Kontexts. Wenn keine Information vorhanden ist – sage "nicht gefunden".
    ...

Bedingte Anbieteranbindung

@Configuration
public class LlmProviderConfig {

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "anthropic"
    )
    public ChatClient anthropicChatClient(
        @Value("${rag.llm.model}") String model,
        AnthropicApi anthropicApi
    ) {
        var options = AnthropicChatOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new AnthropicChatModel(anthropicApi, options))
            .build();
    }

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "openrouter"
    )
    public ChatClient openRouterChatClient(
        @Value("${rag.llm.model}") String model,
        @Value("${openrouter.api-key}") String apiKey
    ) {
        // OpenRouter ist mit der OpenAI API kompatibel, daher verwenden wir OpenAiChatModel
        var openAiApi = new OpenAiApi("https://openrouter.ai/api", apiKey);
        var options = OpenAiChatOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new OpenAiChatModel(openAiApi, options))
            .build();
    }

    @Bean
    @ConditionalOnProperty(
        name = "rag.llm.provider",
        havingValue = "ollama"
    )
    public ChatClient ollamaChatClient(
        @Value("${rag.llm.model}") String model,
        OllamaApi ollamaApi
    ) {
        var options = OllamaOptions.builder()
            .model(model)
            .temperature(0.2)
            .build();

        return ChatClient.builder(new OllamaChatModel(ollamaApi, options))
            .build();
    }
}

Der RAG-Service selbst arbeitet mit jedem Anbieter

@Service
@RequiredArgsConstructor
@Slf4j
public class DocumentQaService {

    private final ChatClient chatClient;
    private final VectorStore vectorStore;

    @Value("${rag.system-prompt}")
    private String systemPromptTemplate;

    public AnswerResponse answer(String question, String companyId) {
        var filter = new FilterExpressionBuilder()
            .eq("company_id", companyId)
            .build();

        List<Document> chunks = vectorStore.similaritySearch(
            SearchRequest.builder()
                .query(question)
                .topK(5)
                .filterExpression(filter)
                .build()
        );

        if (chunks.isEmpty()) {
            return AnswerResponse.notFound();
        }

        String answer = chatClient.prompt()
            .system(buildSystemPrompt(chunks))
            .user(question)
            .call()
            .content();

        return AnswerResponse.of(answer, extractSources(chunks));
    }

    private String buildSystemPrompt(List<Document> chunks) {
        String context = chunks.stream()
            .map(doc -> "[%s]%n%s".formatted(
                doc.getMetadata().get("source"),
                doc.getText()
            ))
            .collect(Collectors.joining("\n\n"));

        return systemPromptTemplate.replace("{context}", context);
    }
}

Die Schönheit des Ansatzes liegt darin, dass der DocumentQaService selbst nicht weiß und nicht wissen will, welches Modell er aufruft. Er arbeitet mit der Abstraktion ChatClient. Wenn ich den Client von Llama auf Opus 4.7 umstellen möchte – ändere ich eine Zeile in application.yml:

rag:
  llm:
    provider: anthropic
    model: claude-opus-4-7

Container-Neustart – und der Client ist bereits auf Opus. Ohne Codeänderungen, ohne Re-Deployment des Dienstes, ohne erneute Veröffentlichung anderer Komponenten. Für eine Produktionsumgebung behalte ich diese Konfigurationen in separaten Spring-Profilen (application-client-acme.yml), sodass jeder Kunde sein Modell über externe Konfiguration erhält und nicht hartkodiert.

Im realen Dienst gibt es über diesem Basisgerüst noch Guardrails für die Eingabe (Erkennung von Prompt Injection), Re-Ranking nach der Ähnlichkeitssuche, Circuit Breaker mit Fallback auf ein Ersatzmodell, strukturiertes Logging mit Korrelations-ID und mehrere andere Schichten. Aber der Kern ist genau das: eine feine Abstraktion über dem Anbieter und die Konfiguration in yml. Das ist es, was mir erlaubt, Kunden zu versprechen: "Möchten Sie morgen ein anderes Modell – wir ändern es, ohne den Code neu zu schreiben".

Einige wichtige Details im Code, auf die man achten sollte:

• Ein DocumentQaService – drei Anbieter. Der Dienst arbeitet mit der Abstraktion ChatClient, nicht mit einer konkreten Implementierung. Spring lädt die benötigte @Bean je nach Wert von rag.llm.provider. Einen neuen Anbieter hinzuzufügen ist eine weitere Klasse mit @ConditionalOnProperty, ohne jegliche Änderungen im restlichen Code.
• OpenRouter über OpenAI API. Der Trick ist, dass OpenRouter mit dem OpenAI-Protokoll kompatibel ist. Daher verwende ich dafür OpenAiChatModel, indem ich einfach die Basis-URL austausche. Dies ermöglicht es, über einen einzigen OpenRouter-Bean Llama, Gemini, Mistral und Dutzende anderer Modelle zu verbinden – einfach durch Ändern von rag.llm.model.
• Parametrisierter Filter statt String-Konkatenation. FilterExpressionBuilder().eq("company_id", companyId) – das ist der richtige Weg, um Pre-Filtering für die Vektorsuche durchzuführen. In einem Multi-Tenant-Dienst ist dies entscheidend: Kunde A wird niemals Dokumente von Kunde B sehen. Naive Konkatenation über String.format ist eine Injection-Schwachstelle, insbesondere wenn companyId irgendwann vom Benutzereingang kommt.
• topK=5 mit Bedacht. Ich habe mich nach mehreren Iterationen für fünf Chunks entschieden. Weniger – Risiko, relevante Informationen zu verpassen, mehr – unnötiger Lärm und das Problem des "Lost-in-the-Middle", wenn das Modell Informationen in der Mitte eines langen Kontexts schlechter sieht. Stanford zeigte eine Verschlechterung des Recalls um 45 % bei mittleren Fragmenten – das ist keine Theorie, das habe ich in der Praxis gesehen.
• Modellwechsel ohne Code-Re-Deployment. Die Kundenkonfigurationen leben in separaten Spring-Profilen (application-client-acme.yml). Wenn ein Kunde das Modell wechseln möchte – ändere ich einen Wert in yml und starte den Container neu. Kompilierung, Tests, CI/CD – nichts davon ist nötig.

⚖️ Opus 4.7 vs Llama 3.3 70B für RAG: Wann was nehmen

Llama 3.3 70B – Standard für die meisten Kunden. Opus 4.7 – für Nischen mit hohen Fehlerkosten. Nicht "entweder-oder", sondern das richtige Werkzeug für die Aufgabe. Und dazwischen – noch viele Optionen für verschiedene Budgets.

Diese Frage höre ich wöchentlich von Kunden. Hier ist meine reale Entscheidungstabelle, ohne Marketing:

Realistisch biete ich Kunden im Produktivbetrieb eine breitere Auswahl an, nicht nur Llama oder Opus. Hier sind die Modelle, die ich derzeit für verschiedene Budgets und Aufgaben empfehle:

• Ultra-Budget, minimale Einstiegshürde (<$20/Monat): deepseek/deepseek-chat über OpenRouter. Unerwartet gute Qualität für wenig Geld, besonders für einfache Document Q&A mit 200-500 Anfragen pro Tag.
• Kleines Budget mit besserer Qualität (<$50/Monat): openai/gpt-4o-mini über OpenRouter. Übertrifft DeepSeek bei komplexeren Anfragen konstant, ist aber teurer.
• Mittleres Segment, Standard für die meisten Kunden (<$100/Monat): meta-llama/llama-3.3-70b-instruct. Starke Balance zwischen Qualität und Preis, offene Architektur, bei Bedarf auf Self-Hosted übertragbar.
• DSGVO + sensible Daten: Llama 3.3 70B im Self-Hosted-Modus auf dem Server des Kunden über vLLM oder Ollama. Kein externer Datenverkehr. Dies ist die Grundlage des geschlossenen Kreislaufs von AskYourDocs für medizinische und juristische Kunden.
• Juristische/medizinische Dokumente, öffentlicher Chatbot, hohe Fehlerkosten: anthropic/claude-opus-4.7. Die Mehrkosten sind durch die Ehrlichkeit des Modells und seine Resistenz gegen Prompt Injection gerechtfertigt.
• Enterprise mit Tausenden von Anfragen pro Tag: Hybrid. Einfachere Anfragen gehen an ein günstigeres Modell (GPT-4o mini oder Llama), komplexere und sensible – an Opus 4.7. Routing nach Anfrageart auf Service-Ebene.

Technisch wird dies durch eine minimale Änderung der Konfiguration realisiert. So sieht der Wechsel des Anbieters in application.yml aus – nur eine Zeile:

# application.yml

# Budget-freundliche Option: DeepSeek über OpenRouter
spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:deepseek/deepseek-chat}

# Qualitativ hochwertiger Mid-Tier: GPT-4o mini
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:openai/gpt-4o-mini}

# Standard für die meisten: Llama 3.3 70B
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:meta-llama/llama-3.3-70b-instruct}

# Premium für juristische und medizinische Aufgaben
# spring.ai.openai.chat.model=${SPRING_AI_OPENAI_CHAT_MODEL:anthropic/claude-opus-4.7}

Der Wert wird aus der Umgebungsvariable SPRING_AI_OPENAI_CHAT_MODEL mit einem Fallback auf das Modell in der Konfiguration entnommen. Das ist praktisch für verschiedene Umgebungen: in dev lasse ich DeepSeek laufen (um das Budget bei Tests nicht zu belasten), und in der Kundenproduktion – das, was wir vereinbart haben. Kein Re-Deployment des Codes bei Modellwechsel, nur die Env-Variable in Railway oder Docker-Konfiguration wird geändert.

Wenn Sie Llama 3.3 70B lokal auf Ihrer eigenen Hardware für Tests ausprobieren möchten – ich habe einen separaten Artikel darüber, welche Modelle auf 8 GB RAM laufen. Llama 70B wird dort nicht laufen – Sie benötigen mindestens 64 GB RAM für eine normale Geschwindigkeit – aber Sie können kleinere Modelle der Familie testen, um das Verhalten zu verstehen.

🏗️ Wie ich Opus 4.7 in AskYourDocs integriert habe

Kurz zur Architektur: Spring Boot + PostgreSQL mit pgvector + OpenRouter als Proxy zu LLMs. Opus 4.7 ist eines von mehreren Modellen, zwischen denen der Kunde je nach Budget und Anforderungen wechseln kann.

AskYourDocs habe ich von Anfang an mandantenfähig aufgebaut. Die Positionierung des Dienstes – „Ihre Dokumente, Ihr Modell, Ihr Server“ – ist keine Marketingphrase, sondern eine architektonische Entscheidung. Der Kunde ist nicht an einen einzigen LLM-Anbieter gebunden: Heute kann es Llama über OpenRouter sein, morgen Opus 4.7, übermorgen ein selbst gehostetes Modell auf ihrer Infrastruktur.

Schlüsselkomponenten des Stacks:

• Spring Boot + Spring AI – das Haupt-Backend. Spring AI bietet eine ChatClient-Abstraktion über LLM-Anbieter, sodass das Hinzufügen eines neuen Anbieters ein neuer Bean mit @ConditionalOnProperty ist, anstatt die Service-Schicht neu zu schreiben.
• PostgreSQL + pgvector – die Vektordatenbank. Für meine Größe reicht sie locker aus. Einen separaten Qdrant oder Pinecone hinzuzufügen, macht keinen Sinn, solange Millionen von Chunks in eine Tabelle passen und die Suchlatenz <100ms beträgt.
• OpenRouter – Proxy für externe LLMs. Über ihn verbinde ich mich mit einem einzigen API-Schlüssel mit Opus 4.7, Llama 3.3 70B, Gemini, GPT-4o mini, DeepSeek. Die Abrechnung ist eine, der Modellwechsel – die Änderung eines einzigen Wertes in einer Umgebungsvariable.
• Ollama und vLLM – für Kunden in geschlossenen Kreisläufen. Derselbe Spring AI ChatClient, nur ein anderer Anbieter-Bean.
• Railway – Deployment. Einfach, günstig, unterstützt Geheimnisse über Umgebungsvariablen, was für die mandantenfähige Konfiguration entscheidend ist.

Das Funktionsschema sieht so aus:

Kunde lädt PDF hoch
     ↓
[Indexing pipeline]
PDF → Text → Chunking → Embedding → pgvector
     ↓
(Index ist bereit, unabhängig von der LLM-Auswahl)

Kunde stellt eine Frage
     ↓
[Query pipeline]
Frage → Vektorsuche → Top-K Chunks → Prompt → ChatClient → LLM
     ↓
LLM wird über das Spring-Profil des Kunden ausgewählt
(Opus 4.7 / Llama / Gemini / anderes)
     ↓
Antwort + Quellen

Der prinzipielle Punkt ist: Die Indizierung ist unabhängig vom LLM. Der Kunde kann mit Llama beginnen, einen Monat arbeiten, feststellen, dass ein präziseres Modell benötigt wird, zu Opus 4.7 wechseln – und muss die Vektordatenbank nicht neu aufbauen. Das spart sowohl Zeit als auch Geld (das Einbetten von Dokumenten kostet nur ein paar Cent, nimmt aber bei großen Mengen Zeit in Anspruch).

Zur Indizierung – eine Standard-RAG-Pipeline: Textextraktion aus PDF, Chunking nach meiner Strategie (rekursiv + Metadaten, Parameter aus meinem Artikel über Chunking), Embedding über OpenAI, Speicherung in pgvector mit Metadaten für Vorfilterung. Die Wahl des Embedding-Modells ist ein separates Thema, und ich habe ausführlich darüber geschrieben hier.

Der Rest sind feine Schichten um diesen Kern: Guardrails, Ratenbegrenzung pro Kunde, Protokollierung mit Korrelations-IDs, Metriken des Token-Verbrauchs für die Abrechnung, ein Admin-Panel zur Dokumentenverwaltung. Aber die Kernidee ist einfach: eine dünne Abstraktion über LLMs + gut abgestimmtes Retrieval = flexibles RAG, das länger lebt als jedes spezifische Modell.

⚠️ Wann Opus 4.7 für RAG definitiv nicht benötigt wird

Ehrlich gesagt: Für die meisten RAG-Projekte ist Opus 4.7 Kanonen auf Spatzen. Ich analysiere Szenarien, in denen man ruhig eine günstigere Alternative wählen kann.

Basierend auf meinen Tests von Opus 4.7 und meiner bisherigen Erfahrung mit Opus 4.5/4.6 bei der Arbeit mit Kunden – hier sind Szenarien, in denen ich keinen Sinn darin sehe, ein Premium-Modell zu wählen:

• Internes FAQ mit 30-50 Fragen. Wenn Sie ein paar Dutzend typische Fragen haben und die Antworten in den Dokumenten direkt sind – Llama 3.3 70B wird mit 95% Qualität für 30 $/Monat auskommen. 400 $ mehr zu bezahlen, ist meiner Meinung nach sinnlos.
• DSGVO-Beschränkungen oder Betriebsgeheimnis. Opus funktioniert nur über die Anthropic API (oder AWS/Google/Azure mit deren Bedingungen). Wenn Sie medizinische, juristische, finanzielle Daten haben und die strenge Anforderung „nicht den Perimeter verlassen“ – wählen Sie Llama self-hosted. Das ist übrigens die Hauptpositionierung von AskYourDocs – Sie können einen vollständig geschlossenen Kreislauf ohne externe APIs einrichten.
• Volumen von 10.000+ Anfragen pro Tag. Bei diesem Maßstab wird Opus 4.000 $/Monat+ kosten. Selten gerechtfertigt – bei großen Volumina ist es fast immer besser, Modelle zu kombinieren (günstiger für einfache Anfragen, Opus für komplexe).
• Web-Research-Szenarien. Opus 4.7 schnitt bei BrowseComp schlechter ab als GPT-5.4 und Gemini 3.1 Pro. Wenn Ihr Agent auf der Durchsicht von Websites basiert – ich würde mich woanders umsehen.
• Retrieval ist noch nicht abgestimmt. Wenn Sie einen Recall von 50 % haben – Opus wird das nicht beheben. Zuerst Chunking, Embedding, Reranking. Dann erst über das Modell nachdenken. Das sehe ich ständig: Entwickler wechseln LLMs und erwarten Magie, aber das Problem ist, dass das Retrieval irrelevante Chunks zurückgibt.
• Wenn das Geschäft möchte, dass der Bot immer etwas antwortet. Das ist eine seltene, aber reale Anfrage – „wir brauchen, dass das Modell nicht ‚ich weiß nicht‘ sagt, sonst denken die Kunden, der Bot sei kaputt.“ Opus 4.7 mit seinem ehrlichen Verhalten wird als „schlechter“ wahrgenommen. Hier muss man entweder den Kunden umerziehen oder ein Modell mit einer höheren Neigung zur Generierung wählen. Für Opus ist das einfach nicht die richtige Aufgabe.

❓ FAQ: Claude Opus 4.7 für RAG

Kann Claude Opus 4.7 für ein RAG-System verwendet werden?

Ja, und meine ersten Tests zeigen, dass es gut funktioniert – besonders dort, wo die Ehrlichkeit des Modells wichtig ist („ich weiß nicht“ statt Halluzination) und die strikte Befolgung des System-Prompts. Die Hauptfrage ist nicht „ob es geht“, sondern „ob es sich lohnt“. Für die meisten Anwendungsfälle liefern günstigere Modelle wie Llama 3.3 70B 90 % der Qualität von Opus zum 10 % des Preises.

Wie viel kostet Opus 4.7 für ein reales RAG-System?

Nach meinen Berechnungen für ein typisches Profil (ungefähr 1000 Anfragen pro Tag, Kontext 8-12K Token) – das sind etwa 400-500 $/Monat. 10-15 Mal teurer als Llama 3.3 70B über OpenRouter. Mit Prompt-Caching kann man die Kosten um 30-40 % senken, aber es bleibt ein Premium-Segment.

Opus 4.7 oder GPT-5.4 für RAG?

Wenn man sich Benchmarks und frühe Tests ansieht – Opus 4.7 ist stärker dort, wo Ehrlichkeit und das Fehlen von Erfindungen kritisch sind. GPT-5.4 gewinnt bei Web-Research und dort, wo Wissen mit Kontext kombiniert werden muss. Für reines Dokumenten-Q&A auf einer geschlossenen Dokumentenbasis würde ich Opus wählen.

Hilft der 1 Million Token Kontext in Opus 4.7, RAG zu ersetzen?

Nein. Großer Kontext ist eine Ergänzung zu RAG, kein Ersatz. Die gesamte Basis in den Prompt zu stecken ist teuer, Modelle verschlechtern sich bei langem Kontext (Lost-in-the-Middle-Effekt), und Datenaktualisierungen werden zum Problem. RAG + selektiv großer Kontext für komplexe analytische Anfragen – das ist optimal.

Eignet sich Opus 4.7 für DSGVO-sensible Daten?

Schwierig. Opus ist nur über APIs verfügbar – Anthropic, AWS Bedrock, Google Vertex AI, Azure Foundry. Für einige Gerichtsbarkeiten und Datentypen reicht das bereits aus (Bedrock in der EU-Region), für andere nicht. Wenn Sie medizinische oder persönliche Daten mit strengen Einschränkungen haben – Llama self-hosted ist die sauberere Wahl. Opus als API kann einfach nicht „den Perimeter nicht verlassen“. Ich habe dieses Thema ausführlich in einem separaten Artikel über DSGVO und KI bei Dokumenten behandelt – dort geht es um Strafen, reale Fälle und konkrete Schritte für Unternehmen in der EU.

Wie integriert man Opus 4.7 in eine Spring Boot Anwendung?

Über Spring AI. Grundsätzlich gibt es zwei Wege: direkt über den Anthropic-Provider (spring-ai-anthropic) oder über OpenRouter als Proxy (mit spring-ai-openai, da OpenRouter mit dem OpenAI-Protokoll kompatibel ist). Der zweite Weg ist bequemer, wenn Sie zwischen Modellen wechseln möchten – ein API-Schlüssel für Opus, Llama, Gemini und Dutzende andere.

Reduzieren sich Halluzinationen in RAG, wenn man Opus 4.7 statt Llama wählt?

In meinen ersten Tests – ja, merklich. Opus 4.7 erkennt häufiger das Fehlen von Informationen im Kontext, anstatt sie zu erfinden. Aber das hängt vom System-Prompt ab – wenn man dem Modell nicht verbietet, mit allgemeinem Wissen zu „ergänzen“, wird selbst Opus das tun. Meiner Meinung nach ist der richtige Prompt in Kombination mit Opus wichtiger als die reine Modellwahl.

Kann man zwischen Opus 4.7 und Llama wechseln, ohne Dokumente neu zu indizieren?

Ja. Die Indizierung hängt vom Embedding-Modell ab, nicht vom LLM. Solange Sie das Embedding nicht ändern – bleibt die Vektordatenbank dieselbe. Sie können Opus ↔ Llama ↔ Gemini ohne jeglichen Aufwand wechseln, und genau darauf basiert die mandantenfähige Architektur von AskYourDocs.

Warum ist Opus 4.7 teurer geworden, wenn der Preis pro Token nicht gestiegen ist?

Wegen des neuen Tokenizers. Derselbe Text wird in 1,0-1,35× mehr Token abgebildet. In meinem Testlauf nach dem Austausch der Model-ID stieg die Kostensteigerung auf etwa 23 % – ohne jegliche Änderungen in der Logik. Teilweise wird dies durch Prompt-Caching und die Verkürzung des System-Prompts behoben.

Was verwendet man für die lokale Entwicklung einer RAG-System vor dem Deployment auf Opus 4.7?

Ich verwende Ollama mit kleineren Modellen (qwen2.5 7B oder llama3.2 3B) für einen schnellen Entwicklungszyklus. Das Verhalten ist nicht identisch mit Opus, aber es ermöglicht das Testen der Pipeline ohne API-Kosten. Auf Staging wechsle ich dann zum realen Modell – Llama über OpenRouter oder Opus 4.7, je nach Aufgabe.

Wenn Sie sich nicht sicher sind, welches Modell Sie wählen sollen – beginnen Sie mit der Demo von AskYourDocs. Ich helfe Ihnen, das passende für Ihr Dokumentenprofil und Budget unverbindlich auszuwählen.