[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-offering-angebot-leistungen":3,"reazon-offering-angebot-zielgruppen":20,"reazon-angebot-subnav":21,"reazon-mainnav":22,"reazon-page-\u002Fde\u002Fwissen\u002Frag-schlechte-antworten":32,"reazon-footernav":58,"reazon-articles-\u002Fde\u002Fwissen":75},[4,8,12,16],{"title":5,"href":6,"description":7},"DGX Spark mieten","\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":9,"href":10,"description":11},"Bare Metal GPU","\u002Fde\u002Fbare-metal","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":13,"href":14,"description":15},"Managed Inference","\u002Fde\u002Fmanaged-inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":17,"href":18,"description":19},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[],[],[23,26,29],{"title":24,"href":25},"Preise","\u002Fde\u002Fpreise",{"title":27,"href":28},"Wissen","\u002Fde\u002Fwissen",{"title":30,"href":31},"Über Twentyone","\u002Fde\u002Fueber-uns",{"data":33},{"id":34,"path":35,"slug":36,"published_at":37,"page_type":38,"no_index":41,"fields":42,"blocks":57},1450,"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","2026-07-07T12:11:28.264Z",{"identifier":39,"name":40},"article","Blog Post",false,{"title":43,"summary":44,"publication_date":45,"big5_category":46,"primary_service":47,"meta_title":53,"meta_description":54,"body":55,"body_html":56},"RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.","2026-07-07T00:00:00Z","problems",{"id":48,"slug":49,"path":18,"page_type":50,"published":51,"type":52},677,"agents","service",true,"Cms::Page","RAG richtig gebaut: warum eure Wissensbasis schwächelt | Twentyone","RAG glänzt in der Demo und halluziniert in Produktion? Meist liegt es am Retrieval, nicht am Modell. Diagnose und Fixes für Chunking, Embeddings, Hybrid-Suche und top_k.","## Die Demo glänzte, die Produktion enttäuschte\n\nEin Kunde aus der Versicherungsbranche zeigte uns vor ein paar Monaten stolz seinen neuen Chatbot. Er sollte Fragen zu internen Policen-Dokumenten beantworten, mit Zugriff auf tausende PDFs voller Vertragsbedingungen. In der Demo liefen drei sorgfältig ausgewählte Fragen, der Bot antwortete druckreif, alle im Raum nickten. Zwei Wochen nach dem Rollout kam die erste Beschwerde: Ein Sachbearbeiter hatte nach der Kündigungsfrist für ein bestimmtes Gewerbeversicherungsprodukt gefragt, und der Bot nannte eine Frist, die schlicht falsch war: Sie stammte aus einem ähnlich klingenden, aber falschen Dokument. Das Modell hatte nicht im eigentlichen Sinn \"halluziniert\". Es hatte präzise wiedergegeben, was ihm im Kontext vorgelegt wurde. Nur war das die falsche Textstelle.\n\nGenau das ist die Pointe dieses Artikels, und wir sagen sie gleich zu Beginn, weil sie in praktisch jedem RAG-Debugging-Gespräch untergeht: **fast jede schlechte RAG-Antwort ist kein Modell-Problem, sondern ein Retrieval-Problem.** Wenn das richtige Snippet nicht im Kontext landet, kann selbst das beste LLM der Welt nur raten, und es rät oft überzeugend. Bevor du also über ein grösseres Modell, ein Fine-Tuning oder einen cleveren Prompt nachdenkst, lohnt sich zuerst die zentrale Frage: Kommt bei der Suche überhaupt das Richtige raus? Garbage in, garbage out gilt bei RAG gnadenlos.\n\nRetrieval-Augmented Generation klingt in der Theorie fast langweilig einfach: Anstatt ein Sprachmodell aus seinem antrainierten \"Gedächtnis\" raten zu lassen, durchsuchst du zuerst deine eigene Wissensbasis nach den relevantesten Textabschnitten und gibst diese dem Modell als Kontext mit. Das Modell muss dann nicht mehr wissen, sondern nur noch lesen und zusammenfassen. Für Unternehmen ist das der naheliegende Weg, ein LLM mit internem Wissen zu füttern, ohne es teuer nachzutrainieren und ohne dass sensible Dokumente im Modellgewicht landen. Das Prinzip ist so simpel, dass praktisch jedes Tutorial es in zwanzig Zeilen Code zeigt: Dokument einlesen, in Stücke schneiden, embedden, in eine Vektordatenbank werfen, bei einer Frage die ähnlichsten Stücke holen, dem Modell servieren.\n\nGenau diese Einfachheit ist die Falle. **Ein RAG-Prototyp lässt sich an einem Nachmittag bauen: Ein RAG-System, das in Produktion verlässlich funktioniert, ist ein Informationsretrieval-Projekt mit einem LLM am Ende, kein LLM-Projekt mit ein bisschen Suche davor.** Wer das umdreht, baut genau die Art von System, die in der Demo glänzt und im Alltag falsche Kündigungsfristen erfindet.\n\n## Chunking: der stille Killer der meisten RAG-Systeme\n\nDer häufigste Fehler passiert, bevor überhaupt ein Embedding berechnet wird: beim Zerschneiden der Dokumente. Die naive Variante (alle 500 oder 1000 Zeichen ein neuer Chunk, egal was gerade dasteht) zerschneidet gnadenlos mitten in Sätzen, reisst Tabellenzeilen von ihrer Kopfzeile ab und trennt eine Absatzüberschrift von genau dem Text, den sie einleitet. Das Embedding eines solchen Fragments repräsentiert dann weder den ursprünglichen Gedanken noch lässt es sich später sinnvoll einer Frage zuordnen. Bei zu grossen Chunks passiert das Gegenteil: Mehrere Themen landen in einem einzigen Embedding-Vektor, der dadurch \"verwässert\" wird und bei semantischer Suche zu unspezifisch matched, um bei einer präzisen Frage weit oben zu landen.\n\n**Die Faustregel liegt meist zwischen 200 und 500 Tokens pro Chunk, mit 10 bis 20 Prozent Overlap zwischen benachbarten Stücken**, damit ein Gedanke, der genau auf einer Chunk-Grenze sitzt, nicht komplett verloren geht. Wichtiger als die genaue Zahl ist aber das Prinzip: Chunk entlang der Struktur des Dokuments, nicht entlang einer starren Zeichenanzahl. Überschriften, Absätze, Tabellenzeilen und Listenpunkte sind natürliche Grenzen: Ein semantisch bewusstes Chunking, das diese respektiert, schlägt naives Fixed-Size-Splitting in fast jedem Praxistest deutlich. Und: Metadaten wie Quelldokument, Abschnittstitel, Datum oder Gültigkeitsbereich gehören an jeden Chunk drangehängt, sonst kannst du später weder filtern noch die Antwort belegen.\n\n## Embeddings: wenn das Modell dein Deutsch nicht versteht\n\nDer zweite Klassiker ist die Wahl des Embedding-Modells, und zwar meist deshalb, weil sie gar nicht bewusst getroffen wurde, sondern aus einem Tutorial übernommen ist, das mit englischen Beispieldaten funktioniert hat. Viele populäre Embedding-Modelle sind primär auf Englisch trainiert und performen bei deutschen Fachtexten spürbar schlechter: Fachbegriffe aus dem Schweizer Recht, branchenspezifisches Vokabular oder zusammengesetzte Wörter, wie sie im Deutschen ständig vorkommen, werden schlicht schlechter in den Vektorraum abgebildet. Das Ergebnis sind Embeddings, die zwei thematisch unterschiedliche Absätze als ähnlich einstufen, während der eigentlich passende Absatz weiter unten in der Trefferliste verschwindet.\n\n**Das Embedding-Modell muss zur Sprache und zur Domäne deiner Dokumente passen, nicht zur Popularität auf einem Leaderboard.** Für Schweizer Unternehmen mit viel deutschem, oft mehrsprachigem und fachspezifischem Content bedeutet das: mehrsprachige oder deutschsprachige Embedding-Modelle testen, idealerweise mit eigenen Dokumenten statt mit Benchmark-Datensätzen, und bei starker Fachterminologie (Recht, Medizin, Technik) zusätzlich prüfen, ob eine Domänenanpassung nötig ist. Wenn du dabei ohnehin über die technische Basis nachdenkst, lohnt sich ein Blick auf [offene Modelle und ihre Auswahlkriterien](\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl). Dieselben Fragen gelten für Embedding-Modelle genauso wie für das generierende LLM.\n\n## Retrieval-Strategie, top_k und das Problem der Mitte\n\nSelbst mit gutem Chunking und passendem Embedding-Modell scheitert reine Vektor-Ähnlichkeitssuche regelmässig an einer bestimmten Fragenkategorie: exakte Begriffe. Eine Kundennummer, eine Produktbezeichnung, ein Paragraf, ein Eigenname: all das sind Dinge, bei denen semantische Ähnlichkeit die falsche Metrik ist, weil zwei Textstellen mit ähnlicher Bedeutung, aber unterschiedlichem exaktem Begriff, im Vektorraum nahe beieinander liegen können, während die eine Stelle mit der exakt richtigen ID weiter weg liegt. **Hybrid-Suche, die Vektor-Ähnlichkeit mit klassischer Keyword-Suche wie BM25 kombiniert, und ein nachgeschalteter Reranker heben die Trefferqualität in unseren Projekten regelmässig deutlich**: Oft ist das der grösste Qualitätssprung, den man mit überschaubarem Aufwand erreicht, weil beide Suchparadigmen ihre jeweilige Stärke ausspielen.\n\nDie zweite Stellschraube ist top_k, also wie viele Chunks du dem Modell überhaupt mitgibst. Zu wenig, und die richtige Information fehlt schlicht im Kontext: Das Modell kann nicht antworten, was es nicht sieht. Zu viel, und du produzierst Rauschen: Modelle nutzen Informationen am Anfang und Ende eines langen Kontexts zuverlässiger als Informationen, die irgendwo in der Mitte vergraben sind (der bekannte \"Lost in the middle\"-Effekt). Ein grosszügiges top_k von 20 oder 30 Chunks wirkt auf den ersten Blick sicherer, verschlechtert die Antwortqualität in der Praxis aber oft, weil das Modell die relevante Stelle im Textbrei übersieht. **top_k zwischen 3 und 8 relevanten, gut gerankten Chunks ist in den meisten Fällen die bessere Wahl als eine grosse Zahl schlecht sortierter Treffer.**\n\n## Datenqualität, Aktualität und die fehlende Evaluation\n\nSelbst die beste Such-Pipeline liefert Müll, wenn die zugrunde liegende Wissensbasis Müll ist. Veraltete Preislisten neben der aktuellen Version, drei sich widersprechende Fassungen desselben Prozessdokuments, dupliziert über verschiedene Sharepoint-Ordner: Das ist in fast jedem Unternehmen, das wir kennenlernen, Realität, nicht Ausnahme. Ein RAG-System kann nicht wissen, welche der drei Versionen gilt, und wird im Zweifel eine davon zufällig ziehen, je nachdem, welche gerade am ähnlichsten zur Frage embedded wurde. Genauso wichtig: Wenn deine Antworten keine Quellenangabe enthalten (welches Dokument, welcher Abschnitt, welches Datum), ist das System nicht auditierbar, und niemand kann im Nachhinein prüfen, ob eine Antwort stimmte oder woher ein Fehler kam.\n\nDer zweite, fast noch häufigere Mangel ist das komplette Fehlen von Evaluation. Die meisten Teams testen ein RAG-System, indem jemand ein paar Fragen in die Chat-Oberfläche tippt und subjektiv beurteilt, ob die Antwort \"gut klingt\". **Ohne ein Golden-Set aus repräsentativen Frage-Antwort-Paaren mit bekannt korrekten Quellenbelegen lässt sich Qualität nicht messen, sondern nur erahnen**, und genau deshalb fallen Regressionen erst auf, wenn Kunden oder Mitarbeitende sie melden. Ein sauberes Setup misst Retrieval-Recall (landet das richtige Snippet überhaupt in den Top-k-Treffern?) und Antwortqualität (nutzt das Modell den gelieferten Kontext korrekt?) als zwei getrennte Kennzahlen, gemessen auf demselben Golden-Set nach jeder Änderung an Chunking, Embedding-Modell oder Prompt.\n\n## Diagnose: zwei Fragen trennen, bevor du irgendetwas änderst\n\nWenn ein RAG-System schlecht antwortet, ist der Reflex meist, am Prompt herumzubasteln oder ein grösseres Modell auszuprobieren. Das ist fast immer der falsche Hebel. Stelle stattdessen zuerst zwei Fragen sauber getrennt: Erstens, ist das richtige Snippet überhaupt im Kontext gelandet, den das Modell gesehen hat? Das prüfst du, indem du dir bei jeder fehlerhaften Antwort explizit die abgerufenen Chunks anschaust, bevor du dir die generierte Antwort überhaupt ansiehst. Zweitens, und nur wenn die erste Frage mit Ja beantwortet ist: Hat das Modell aus einem korrekten Kontext trotzdem falsch geantwortet? **In unserer Erfahrung liegt das Problem in der überwältigenden Mehrheit der Fälle bei Frage eins, nicht bei Frage zwei**: Das Retrieval liefert die falsche oder unvollständige Grundlage, und das Modell tut danach genau das, was man von ihm erwarten würde: Es macht aus unzureichendem Material eine plausibel klingende, aber falsche Antwort.\n\nDiese Trennung ist auch der Grund, warum die Frage \"Agent oder Endpoint?\" hier eine klare Antwort hat. Ein Dokumenten-Q&A-System, das Fragen zu einer Wissensbasis beantwortet, ist in den allermeisten Fällen [ein Endpoint, kein Agent](\u002Fde\u002Fwissen\u002Fagent-oder-endpoint): eine klar definierte Pipeline aus Retrieval und Generation, kein autonom planendes System mit Tool-Aufrufen und mehreren Entscheidungsschritten. Wer ein RAG-Problem mit Agent-Architektur zu lösen versucht, fügt Komplexität hinzu, ohne das eigentliche Retrieval-Problem zu beheben. Erst wenn dein System tatsächlich mehrstufig recherchieren, Tools aufrufen oder Aktionen ausführen soll, wird aus dem Q&A-Endpoint sinnvollerweise ein Agent.\n\nEin letzter Punkt, der in technischen RAG-Diskussionen oft untergeht: Deine Wissensbasis besteht aus internen Dokumenten: Verträgen, Handbüchern, Kundendaten, oft mit Personenbezug oder Geschäftsgeheimnissen. Bei jeder Anfrage wandern Ausschnitte davon durch die gesamte RAG-Pipeline, vom Embedding bis zum LLM-Aufruf. Wo diese Pipeline läuft und wer theoretisch Zugriff auf die Zwischenschritte hat, ist deshalb keine Nebensache, sondern Kern der Frage nach [Datenhoheit](\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das). Über [Managed Inference](\u002Fde\u002Fmanaged-inference) laufen sowohl das Embedding-Modell als auch das generierende LLM auf Infrastruktur, die du kontrollierst, ohne dass Dokumente zu einem US-Hyperscaler wandern, nur weil eine Bibliothek das per Default so vorsieht.\n\n## Miss zuerst das Retrieval, dann das Modell\n\nRAG ist kein Feature, das man einmal einbaut und dann vergisst: Es ist eine Such-Pipeline, die kontinuierliche Pflege, Messung und Iteration braucht, genau wie jedes andere produktionsrelevante System. **Die gute Nachricht: Die meisten Probleme sind lösbar, sobald man aufhört, sie am Modell zu suchen, und stattdessen Chunking, Embedding-Modell, Retrieval-Strategie und Datenqualität einzeln unter die Lupe nimmt.** Der Versicherungskunde von oben hat sein System nicht mit einem grösseren Modell repariert, sondern mit Hybrid-Suche, sauberem Chunking entlang der Dokumentstruktur und einem Golden-Set, das seither jede Änderung vor dem Rollout absichert. Die Kündigungsfristen stimmen seither.\n\nWenn du ein RAG-System planst oder ein bestehendes reparieren musst, hilft selten die generische Anleitung: Meistens steckt der Fehler in einer sehr konkreten Kombination aus deinen Dokumenten, deiner Sprache und deiner Fragestellung. Wir bauen und betreiben souverän gehostete RAG-Pipelines und [AI-Agents](\u002Fde\u002Fagents) für Schweizer Unternehmen, inklusive der Diagnosearbeit, die die meisten Anbieter überspringen. Sprich mit uns, bevor du das nächste Modell-Upgrade bestellst: Oft ist es gar nicht das Modell.","\u003Ch2>Die Demo glänzte, die Produktion enttäuschte\u003C\u002Fh2>\n\n\u003Cp>Ein Kunde aus der Versicherungsbranche zeigte uns vor ein paar Monaten stolz seinen neuen Chatbot. Er sollte Fragen zu internen Policen-Dokumenten beantworten, mit Zugriff auf tausende PDFs voller Vertragsbedingungen. In der Demo liefen drei sorgfältig ausgewählte Fragen, der Bot antwortete druckreif, alle im Raum nickten. Zwei Wochen nach dem Rollout kam die erste Beschwerde: Ein Sachbearbeiter hatte nach der Kündigungsfrist für ein bestimmtes Gewerbeversicherungsprodukt gefragt, und der Bot nannte eine Frist, die schlicht falsch war: Sie stammte aus einem ähnlich klingenden, aber falschen Dokument. Das Modell hatte nicht im eigentlichen Sinn \u003Cq>halluziniert\u003C\u002Fq>. Es hatte präzise wiedergegeben, was ihm im Kontext vorgelegt wurde. Nur war das die falsche Textstelle.\u003C\u002Fp>\n\n\u003Cp>Genau das ist die Pointe dieses Artikels, und wir sagen sie gleich zu Beginn, weil sie in praktisch jedem RAG-Debugging-Gespräch untergeht: \u003Cstrong>fast jede schlechte RAG-Antwort ist kein Modell-Problem, sondern ein Retrieval-Problem.\u003C\u002Fstrong> Wenn das richtige Snippet nicht im Kontext landet, kann selbst das beste LLM der Welt nur raten, und es rät oft überzeugend. Bevor du also über ein grösseres Modell, ein Fine-Tuning oder einen cleveren Prompt nachdenkst, lohnt sich zuerst die zentrale Frage: Kommt bei der Suche überhaupt das Richtige raus? Garbage in, garbage out gilt bei RAG gnadenlos.\u003C\u002Fp>\n\n\u003Cp>Retrieval-Augmented Generation klingt in der Theorie fast langweilig einfach: Anstatt ein Sprachmodell aus seinem antrainierten \u003Cq>Gedächtnis\u003C\u002Fq> raten zu lassen, durchsuchst du zuerst deine eigene Wissensbasis nach den relevantesten Textabschnitten und gibst diese dem Modell als Kontext mit. Das Modell muss dann nicht mehr wissen, sondern nur noch lesen und zusammenfassen. Für Unternehmen ist das der naheliegende Weg, ein LLM mit internem Wissen zu füttern, ohne es teuer nachzutrainieren und ohne dass sensible Dokumente im Modellgewicht landen. Das Prinzip ist so simpel, dass praktisch jedes Tutorial es in zwanzig Zeilen Code zeigt: Dokument einlesen, in Stücke schneiden, embedden, in eine Vektordatenbank werfen, bei einer Frage die ähnlichsten Stücke holen, dem Modell servieren.\u003C\u002Fp>\n\n\u003Cp>Genau diese Einfachheit ist die Falle. \u003Cstrong>Ein RAG-Prototyp lässt sich an einem Nachmittag bauen: Ein RAG-System, das in Produktion verlässlich funktioniert, ist ein Informationsretrieval-Projekt mit einem LLM am Ende, kein LLM-Projekt mit ein bisschen Suche davor.\u003C\u002Fstrong> Wer das umdreht, baut genau die Art von System, die in der Demo glänzt und im Alltag falsche Kündigungsfristen erfindet.\u003C\u002Fp>\n\n\u003Ch2>Chunking: der stille Killer der meisten RAG-Systeme\u003C\u002Fh2>\n\n\u003Cp>Der häufigste Fehler passiert, bevor überhaupt ein Embedding berechnet wird: beim Zerschneiden der Dokumente. Die naive Variante (alle 500 oder 1000 Zeichen ein neuer Chunk, egal was gerade dasteht) zerschneidet gnadenlos mitten in Sätzen, reisst Tabellenzeilen von ihrer Kopfzeile ab und trennt eine Absatzüberschrift von genau dem Text, den sie einleitet. Das Embedding eines solchen Fragments repräsentiert dann weder den ursprünglichen Gedanken noch lässt es sich später sinnvoll einer Frage zuordnen. Bei zu grossen Chunks passiert das Gegenteil: Mehrere Themen landen in einem einzigen Embedding-Vektor, der dadurch \u003Cq>verwässert\u003C\u002Fq> wird und bei semantischer Suche zu unspezifisch matched, um bei einer präzisen Frage weit oben zu landen.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Die Faustregel liegt meist zwischen 200 und 500 Tokens pro Chunk, mit 10 bis 20 Prozent Overlap zwischen benachbarten Stücken\u003C\u002Fstrong>, damit ein Gedanke, der genau auf einer Chunk-Grenze sitzt, nicht komplett verloren geht. Wichtiger als die genaue Zahl ist aber das Prinzip: Chunk entlang der Struktur des Dokuments, nicht entlang einer starren Zeichenanzahl. Überschriften, Absätze, Tabellenzeilen und Listenpunkte sind natürliche Grenzen: Ein semantisch bewusstes Chunking, das diese respektiert, schlägt naives Fixed-Size-Splitting in fast jedem Praxistest deutlich. Und: Metadaten wie Quelldokument, Abschnittstitel, Datum oder Gültigkeitsbereich gehören an jeden Chunk drangehängt, sonst kannst du später weder filtern noch die Antwort belegen.\u003C\u002Fp>\n\n\u003Ch2>Embeddings: wenn das Modell dein Deutsch nicht versteht\u003C\u002Fh2>\n\n\u003Cp>Der zweite Klassiker ist die Wahl des Embedding-Modells, und zwar meist deshalb, weil sie gar nicht bewusst getroffen wurde, sondern aus einem Tutorial übernommen ist, das mit englischen Beispieldaten funktioniert hat. Viele populäre Embedding-Modelle sind primär auf Englisch trainiert und performen bei deutschen Fachtexten spürbar schlechter: Fachbegriffe aus dem Schweizer Recht, branchenspezifisches Vokabular oder zusammengesetzte Wörter, wie sie im Deutschen ständig vorkommen, werden schlicht schlechter in den Vektorraum abgebildet. Das Ergebnis sind Embeddings, die zwei thematisch unterschiedliche Absätze als ähnlich einstufen, während der eigentlich passende Absatz weiter unten in der Trefferliste verschwindet.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Das Embedding-Modell muss zur Sprache und zur Domäne deiner Dokumente passen, nicht zur Popularität auf einem Leaderboard.\u003C\u002Fstrong> Für Schweizer Unternehmen mit viel deutschem, oft mehrsprachigem und fachspezifischem Content bedeutet das: mehrsprachige oder deutschsprachige Embedding-Modelle testen, idealerweise mit eigenen Dokumenten statt mit Benchmark-Datensätzen, und bei starker Fachterminologie (Recht, Medizin, Technik) zusätzlich prüfen, ob eine Domänenanpassung nötig ist. Wenn du dabei ohnehin über die technische Basis nachdenkst, lohnt sich ein Blick auf \u003Ca href=\"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl\">offene Modelle und ihre Auswahlkriterien\u003C\u002Fa>. Dieselben Fragen gelten für Embedding-Modelle genauso wie für das generierende LLM.\u003C\u002Fp>\n\n\u003Ch2>Retrieval-Strategie, top_k und das Problem der Mitte\u003C\u002Fh2>\n\n\u003Cp>Selbst mit gutem Chunking und passendem Embedding-Modell scheitert reine Vektor-Ähnlichkeitssuche regelmässig an einer bestimmten Fragenkategorie: exakte Begriffe. Eine Kundennummer, eine Produktbezeichnung, ein Paragraf, ein Eigenname: all das sind Dinge, bei denen semantische Ähnlichkeit die falsche Metrik ist, weil zwei Textstellen mit ähnlicher Bedeutung, aber unterschiedlichem exaktem Begriff, im Vektorraum nahe beieinander liegen können, während die eine Stelle mit der exakt richtigen ID weiter weg liegt. \u003Cstrong>Hybrid-Suche, die Vektor-Ähnlichkeit mit klassischer Keyword-Suche wie BM25 kombiniert, und ein nachgeschalteter Reranker heben die Trefferqualität in unseren Projekten regelmässig deutlich\u003C\u002Fstrong>: Oft ist das der grösste Qualitätssprung, den man mit überschaubarem Aufwand erreicht, weil beide Suchparadigmen ihre jeweilige Stärke ausspielen.\u003C\u002Fp>\n\n\u003Cp>Die zweite Stellschraube ist top\u003Cu>k, also wie viele Chunks du dem Modell überhaupt mitgibst. Zu wenig, und die richtige Information fehlt schlicht im Kontext: Das Modell kann nicht antworten, was es nicht sieht. Zu viel, und du produzierst Rauschen: Modelle nutzen Informationen am Anfang und Ende eines langen Kontexts zuverlässiger als Informationen, die irgendwo in der Mitte vergraben sind (der bekannte \u003Cq>Lost in the middle\u003C\u002Fq>-Effekt). Ein grosszügiges top\u003C\u002Fu>k von 20 oder 30 Chunks wirkt auf den ersten Blick sicherer, verschlechtert die Antwortqualität in der Praxis aber oft, weil das Modell die relevante Stelle im Textbrei übersieht. \u003Cstrong>top_k zwischen 3 und 8 relevanten, gut gerankten Chunks ist in den meisten Fällen die bessere Wahl als eine grosse Zahl schlecht sortierter Treffer.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Ch2>Datenqualität, Aktualität und die fehlende Evaluation\u003C\u002Fh2>\n\n\u003Cp>Selbst die beste Such-Pipeline liefert Müll, wenn die zugrunde liegende Wissensbasis Müll ist. Veraltete Preislisten neben der aktuellen Version, drei sich widersprechende Fassungen desselben Prozessdokuments, dupliziert über verschiedene Sharepoint-Ordner: Das ist in fast jedem Unternehmen, das wir kennenlernen, Realität, nicht Ausnahme. Ein RAG-System kann nicht wissen, welche der drei Versionen gilt, und wird im Zweifel eine davon zufällig ziehen, je nachdem, welche gerade am ähnlichsten zur Frage embedded wurde. Genauso wichtig: Wenn deine Antworten keine Quellenangabe enthalten (welches Dokument, welcher Abschnitt, welches Datum), ist das System nicht auditierbar, und niemand kann im Nachhinein prüfen, ob eine Antwort stimmte oder woher ein Fehler kam.\u003C\u002Fp>\n\n\u003Cp>Der zweite, fast noch häufigere Mangel ist das komplette Fehlen von Evaluation. Die meisten Teams testen ein RAG-System, indem jemand ein paar Fragen in die Chat-Oberfläche tippt und subjektiv beurteilt, ob die Antwort \u003Cq>gut klingt\u003C\u002Fq>. \u003Cstrong>Ohne ein Golden-Set aus repräsentativen Frage-Antwort-Paaren mit bekannt korrekten Quellenbelegen lässt sich Qualität nicht messen, sondern nur erahnen\u003C\u002Fstrong>, und genau deshalb fallen Regressionen erst auf, wenn Kunden oder Mitarbeitende sie melden. Ein sauberes Setup misst Retrieval-Recall (landet das richtige Snippet überhaupt in den Top-k-Treffern?) und Antwortqualität (nutzt das Modell den gelieferten Kontext korrekt?) als zwei getrennte Kennzahlen, gemessen auf demselben Golden-Set nach jeder Änderung an Chunking, Embedding-Modell oder Prompt.\u003C\u002Fp>\n\n\u003Ch2>Diagnose: zwei Fragen trennen, bevor du irgendetwas änderst\u003C\u002Fh2>\n\n\u003Cp>Wenn ein RAG-System schlecht antwortet, ist der Reflex meist, am Prompt herumzubasteln oder ein grösseres Modell auszuprobieren. Das ist fast immer der falsche Hebel. Stelle stattdessen zuerst zwei Fragen sauber getrennt: Erstens, ist das richtige Snippet überhaupt im Kontext gelandet, den das Modell gesehen hat? Das prüfst du, indem du dir bei jeder fehlerhaften Antwort explizit die abgerufenen Chunks anschaust, bevor du dir die generierte Antwort überhaupt ansiehst. Zweitens, und nur wenn die erste Frage mit Ja beantwortet ist: Hat das Modell aus einem korrekten Kontext trotzdem falsch geantwortet? \u003Cstrong>In unserer Erfahrung liegt das Problem in der überwältigenden Mehrheit der Fälle bei Frage eins, nicht bei Frage zwei\u003C\u002Fstrong>: Das Retrieval liefert die falsche oder unvollständige Grundlage, und das Modell tut danach genau das, was man von ihm erwarten würde: Es macht aus unzureichendem Material eine plausibel klingende, aber falsche Antwort.\u003C\u002Fp>\n\n\u003Cp>Diese Trennung ist auch der Grund, warum die Frage \u003Cq>Agent oder Endpoint?\u003C\u002Fq> hier eine klare Antwort hat. Ein Dokumenten-Q&A-System, das Fragen zu einer Wissensbasis beantwortet, ist in den allermeisten Fällen \u003Ca href=\"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint\">ein Endpoint, kein Agent\u003C\u002Fa>: eine klar definierte Pipeline aus Retrieval und Generation, kein autonom planendes System mit Tool-Aufrufen und mehreren Entscheidungsschritten. Wer ein RAG-Problem mit Agent-Architektur zu lösen versucht, fügt Komplexität hinzu, ohne das eigentliche Retrieval-Problem zu beheben. Erst wenn dein System tatsächlich mehrstufig recherchieren, Tools aufrufen oder Aktionen ausführen soll, wird aus dem Q&A-Endpoint sinnvollerweise ein Agent.\u003C\u002Fp>\n\n\u003Cp>Ein letzter Punkt, der in technischen RAG-Diskussionen oft untergeht: Deine Wissensbasis besteht aus internen Dokumenten: Verträgen, Handbüchern, Kundendaten, oft mit Personenbezug oder Geschäftsgeheimnissen. Bei jeder Anfrage wandern Ausschnitte davon durch die gesamte RAG-Pipeline, vom Embedding bis zum LLM-Aufruf. Wo diese Pipeline läuft und wer theoretisch Zugriff auf die Zwischenschritte hat, ist deshalb keine Nebensache, sondern Kern der Frage nach \u003Ca href=\"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das\">Datenhoheit\u003C\u002Fa>. Über \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> laufen sowohl das Embedding-Modell als auch das generierende LLM auf Infrastruktur, die du kontrollierst, ohne dass Dokumente zu einem US-Hyperscaler wandern, nur weil eine Bibliothek das per Default so vorsieht.\u003C\u002Fp>\n\n\u003Ch2>Miss zuerst das Retrieval, dann das Modell\u003C\u002Fh2>\n\n\u003Cp>RAG ist kein Feature, das man einmal einbaut und dann vergisst: Es ist eine Such-Pipeline, die kontinuierliche Pflege, Messung und Iteration braucht, genau wie jedes andere produktionsrelevante System. \u003Cstrong>Die gute Nachricht: Die meisten Probleme sind lösbar, sobald man aufhört, sie am Modell zu suchen, und stattdessen Chunking, Embedding-Modell, Retrieval-Strategie und Datenqualität einzeln unter die Lupe nimmt.\u003C\u002Fstrong> Der Versicherungskunde von oben hat sein System nicht mit einem grösseren Modell repariert, sondern mit Hybrid-Suche, sauberem Chunking entlang der Dokumentstruktur und einem Golden-Set, das seither jede Änderung vor dem Rollout absichert. Die Kündigungsfristen stimmen seither.\u003C\u002Fp>\n\n\u003Cp>Wenn du ein RAG-System planst oder ein bestehendes reparieren musst, hilft selten die generische Anleitung: Meistens steckt der Fehler in einer sehr konkreten Kombination aus deinen Dokumenten, deiner Sprache und deiner Fragestellung. Wir bauen und betreiben souverän gehostete RAG-Pipelines und \u003Ca href=\"\u002Fde\u002Fagents\">AI-Agents\u003C\u002Fa> für Schweizer Unternehmen, inklusive der Diagnosearbeit, die die meisten Anbieter überspringen. Sprich mit uns, bevor du das nächste Modell-Upgrade bestellst: Oft ist es gar nicht das Modell.\u003C\u002Fp>\n",[],[59,66],{"title":60,"links":61},"Leistungen",[62,63,64,65],{"title":5,"href":6},{"title":9,"href":10},{"title":13,"href":14},{"title":17,"href":18},{"title":67,"links":68},"Unternehmen",[69,70,71,72],{"title":30,"href":31},{"title":27,"href":28},{"title":24,"href":25},{"title":73,"href":74},"Kontakt","\u002Fde\u002Fkontakt",[76,87,99,108,115,123,129,136,142,144,150,157,163,169,175,181,187,194],{"path":77,"slug":78,"title":79,"summary":80,"image":81,"publication_date":82,"big5_category":83,"primary_hub":81,"cluster":81,"pillar":81,"hubs":84},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.",null,"2026-07-13T00:00:00Z","comparisons",[85],{"slug":86,"title":13},"managed-inference",{"path":88,"slug":89,"title":90,"summary":91,"image":81,"publication_date":82,"big5_category":92,"primary_hub":81,"cluster":81,"pillar":81,"hubs":93},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.","bestof",[94,97],{"slug":95,"title":96},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":98,"title":5},"dgx-spark",{"path":100,"slug":101,"title":102,"summary":103,"image":81,"publication_date":82,"big5_category":104,"primary_hub":81,"cluster":81,"pillar":81,"hubs":105},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[106],{"slug":49,"title":107},"Hermes Agents as a Service",{"path":109,"slug":110,"title":111,"summary":112,"image":81,"publication_date":82,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":113},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.",[114],{"slug":86,"title":13},{"path":116,"slug":117,"title":118,"summary":119,"image":81,"publication_date":82,"big5_category":120,"primary_hub":81,"cluster":81,"pillar":81,"hubs":121},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[122],{"slug":86,"title":13},{"path":124,"slug":125,"title":126,"summary":127,"image":81,"publication_date":45,"big5_category":83,"primary_hub":81,"cluster":81,"pillar":81,"hubs":128},"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.",[],{"path":130,"slug":131,"title":132,"summary":133,"image":81,"publication_date":45,"big5_category":134,"primary_hub":81,"cluster":81,"pillar":81,"hubs":135},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.","how-to",[],{"path":137,"slug":138,"title":139,"summary":140,"image":81,"publication_date":45,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":141},"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.",[],{"path":35,"slug":36,"title":43,"summary":44,"image":81,"publication_date":45,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":143},[],{"path":145,"slug":146,"title":147,"summary":148,"image":81,"publication_date":45,"big5_category":134,"primary_hub":81,"cluster":81,"pillar":81,"hubs":149},"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.",[],{"path":151,"slug":152,"title":153,"summary":154,"image":81,"publication_date":155,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":156},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.","2026-06-30T00:00:00Z",[],{"path":158,"slug":159,"title":160,"summary":161,"image":81,"publication_date":155,"big5_category":46,"primary_hub":81,"cluster":81,"pillar":81,"hubs":162},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":164,"slug":165,"title":166,"summary":167,"image":81,"publication_date":155,"big5_category":104,"primary_hub":81,"cluster":81,"pillar":81,"hubs":168},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":170,"slug":171,"title":172,"summary":173,"image":81,"publication_date":155,"big5_category":134,"primary_hub":81,"cluster":81,"pillar":81,"hubs":174},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":176,"slug":177,"title":178,"summary":179,"image":81,"publication_date":155,"big5_category":92,"primary_hub":81,"cluster":81,"pillar":81,"hubs":180},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.",[],{"path":182,"slug":183,"title":184,"summary":185,"image":81,"publication_date":155,"big5_category":83,"primary_hub":81,"cluster":81,"pillar":81,"hubs":186},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.",[],{"path":188,"slug":189,"title":190,"summary":191,"image":81,"publication_date":192,"big5_category":83,"primary_hub":81,"cluster":81,"pillar":81,"hubs":193},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":195,"slug":196,"title":197,"summary":198,"image":81,"publication_date":192,"big5_category":120,"primary_hub":81,"cluster":81,"pillar":81,"hubs":199},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[]]