Scoring Methodology

Die RAG-vs-Fine-Tuning-Decision-Engine bewertet vier Architekturklassen — RAG, Fine-Tuning, Long-Context und Hybrid — gegen neun Dimensionen Ihres Anwendungsfalls. Diese Seite erklärt, wie jede Dimension gewichtet wird, wie Kostenschätzungen abgeleitet werden und wie Konfidenz und Risiko berichtet werden.

1. Die neun Scoring-Dimensionen

Jede Dimension trägt positive oder negative Punkte zu einer oder mehreren Architekturklassen bei. Punkte sind keine Prozentsätze — sie sind additive Signale. Die Klasse mit dem höchsten Gesamtwert gewinnt. Der Abstand zwischen erster und zweiter Klasse bestimmt die Konfidenz.

• Datenaktualität

  Wie häufig sich Ihre Quelldaten ändern. Echtzeitdaten (1) bevorzugen RAG stark, weil fine-tuned Modelle ohne Retraining-Zyklus keine neuen Informationen aufnehmen können. Statische Daten (5) entfernen den Hauptvorteil von RAG.

• Dokumentenvolumen

  Die Größe Ihres Wissenskorpus. Winzige Korpora (<10K Dokumente, Score 1) können in ein Long-Context-Fenster passen. Massive Korpora (>10M Dokumente, Score 5) schließen Long-Context aus und bevorzugen vektor-basierte Retrieval stark.

• Monatliches Anfragevolumen

  Gesamte Inferenzaufrufe pro Monat. Bei sehr hohen Volumina (>1M/Monat) summieren sich Retrieval-Kosten pro Anfrage und können Fine-Tuning kostengünstiger machen. Bei niedrigen Volumina (<10K/Monat) kippt der Infrastruktur-Overhead die Balance zu Long-Context.

• Zitiergenauigkeit

  Ob Ihr Anwendungsfall verifizierbare Quellenverweise erfordert. Audit-taugliche Zitierung (4) bevorzugt RAG oder Hybrid stark, weil fine-tuned Modelle Provenienz halluzinieren — sie können keine Quellen zitieren, die sie zur Trainingszeit nicht gesehen haben.

• Latenz-SLA

  Ihr End-to-End-Latenzbudget in Millisekunden. RAG fügt einen Retrieval-Sprung von 100–400 ms hinzu. Wenn Ihr SLA unter 500 ms liegt, kann Fine-Tuning (kein Retrieval) notwendig sein. Long-Context fügt TTFT-Overhead bei großen Token-Anzahlen hinzu.

• Datensensibilität

  Regulatorische und Vertraulichkeitsklassifikation Ihrer Daten. Hohe Sensibilität (4–5) begrenzt, welche gehosteten API-Anbieter Sie für Retrieval nutzen können, und kann selbst-gehostete Embedding- und Inferenz-Infrastruktur erfordern.

• Domänenspezifität

  Wie spezialisiert Ihr Domänen-Vokabular und Ausgabeformat sind. Hochspezialisierte Domänen (4–5) mit proprietärem Jargon, Ausgabeschemata oder Markenstimme profitieren mehr von der Gewichtsanpassung des Fine-Tunings als von Retrieval allein.

• ML-Fähigkeit

  Ihre interne ML-Engineering-Reife (1 = kein ML-Team, 5 = Weltklasse). Fine-Tuning- und Hybrid-Architekturen erfordern ML-Expertise zum Entwerfen, Trainieren, Bewerten und Warten. Teams mit niedriger Fähigkeit sollten standardmäßig RAG oder Long-Context wählen.

• Budget-Obergrenze

  Maximaler monatlicher Aufwand. Wenn die geschätzten Kosten des führenden Ansatzes 120 % Ihrer Obergrenze überschreiten, wendet die Engine eine Strafe an. Budget < 2K $ schließt im Allgemeinen Hybrid aus; <5K $ kann Fine-Tuning ausschließen, wenn Training amortisiert wird.

2. Zusammengesetzte Signale

Über individuelle Dimensions-Scores hinaus wendet die Engine zusammengesetzte Signale an, die Wechselwirkungen zwischen Dimensionen erfassen:

• Hohes Volumen + strenge Zitate: Wenn monatliche Anfragen ≥ 1M und Zitate = 4, erhält Hybrid zusätzliche +20, weil RAFT die Trainingskosten amortisiert und gleichzeitig die Zitiergenauigkeit bewahrt.
• Niedriges Volumen + niedriges Budget + nicht air-gapped: Long-context erhält +15, weil der Aufbau einer Vektor-Infrastruktur wirtschaftlich nicht gerechtfertigt ist.
• On-Premises oder air-gapped: Fine-Tuning und Hybrid erhalten +15/+10, weil sie selbst-gehostet bereitgestellt werden können, während long-context (das gehostete API-Aufrufe erfordert) mit −20 bestraft wird.
• Budget-Strafe: Wenn die geschätzten monatlichen Kosten eines Ansatzes 120 % Ihrer angegebenen Obergrenze überschreiten, erhält dieser Ansatz −15 Punkte.

3. Kostenschätzungs-Methodik

Kostenschätzungen werden aus Ihrem monatlichen Anfragevolumen, durchschnittlichen Token-Anzahlen und Live-LLM-Preisdaten aus unserer Modelldatenbank abgeleitet. Die Formel für jede Klasse:

Vector-DB-Preise sind nach Korpus-Volumen gestaffelt (1–5-Skala mappt auf 70–3.000 $/Mon.), basierend auf beobachteten Preisen von pgvector, Pinecone, Weaviate und Qdrant ab Q1 2026. LLM-Token-Preise werden live aus unserer Modelldatenbank gezogen und fallen auf konservative Defaults zurück (3 $/1M Eingabe, 12 $/1M Ausgabe), wenn die Datenbank nicht verfügbar ist.

4. Konfidenzabstand

Die Konfidenz wird durch den Punkteabstand zwischen Gewinnerklasse und Zweitplatzierter bestimmt:

• Hohe Konfidenz: Abstand ≥ 25 Punkte — ein Ansatz dominiert klar.
• Mittlere Konfidenz: Abstand 10–24 Punkte — ein klarer Anführer, aber der Zweitplatzierte ist tragfähig.
• Niedrige Konfidenz: Abstand < 10 Punkte — mehrere Ansätze sind eng beieinander; ein Proof-of-Concept mit beiden wird empfohlen.

Wenn der Gewinnerwert unter 40 liegt, setzt die Engine auch eine „Rescope-Flagge“, die anzeigt, dass kein einzelner Ansatz dominiert — typischerweise ein Zeichen, dass der Anwendungsfall-Umfang vor einer Infrastrukturverpflichtung eingeengt werden sollte.

5. Risikoregister

Die Engine bewertet sieben Risiko-Auslöser gegen Ihre Eingaben und die Gewinnerempfehlung. Jedes Risiko hat einen Schweregrad (hoch, mittel oder niedrig) und eine Minderungsempfehlung:

• Risiko halluzinierter Zitate (hoch): Fine-Tuning empfohlen + Zitate ≥ 3.
• Budget-Obergrenze gefährdet (mittel): Geschätzte Kosten > 90 % Ihrer angegebenen Obergrenze.
• Risiko Datenresidenz-Verletzung (hoch): EU-Residenz oder hohe Sensibilität + Long-Context empfohlen.
• ML-Kapazitätslücke (mittel): Kapazität ≤ 2 + Fine-Tuning oder Hybrid empfohlen.
• Veraltete Preisdaten (niedrig): Vector-DB-Preisdaten älter als 90 Tage.
• Korpus-Drift-Risiko (mittel): Frische ≤ 2 + Fine-Tuning empfohlen.
• Latenzbudget gefährdet (hoch): Latenz-SLA < 500 ms + RAG oder Hybrid empfohlen.

6. Einschränkungen und Annahmen

• Kostenschätzungen sind nur indikativ. Tatsächliche Kosten hängen von Anbieter, Modellgröße, Infrastrukturkonfiguration und ausgehandelten Preisen ab.
• Das Scoring-Modell ist absichtlich meinungsstark und basiert auf beobachteten Produktionsmustern bei Buzzi-Kunden ab Q1 2026. Es ersetzt keine Architekturüberprüfung durch einen erfahrenen ML-Ingenieur.
• Die Engine modelliert keine Multi-Tenancy, A/B-Test-Overhead, Evaluationspipeline-Kosten oder Datenmarkierungskosten für Fine-Tuning.
• Hybrid-/RAFT-Kosten gehen von einem einzigen Retraining-Zyklus pro 6-Monats-Fenster aus. Teams mit häufigeren Retraining-Anforderungen sollten den Trainings-Amortisationsdivisor erhöhen.