Alle Notizen
20. Mai 202613 Min. Lesedauerragstructured-retrievaldataverseenterprise-agentsaiengineering

Structured Retrieval schlägt Vector RAG für Enterprise Agents

Kernaussagen

  • Vector RAG scheitert still mit einem selbstbewussten Cosinus-Score; Structured Retrieval scheitert laut mit einer zurückgegebenen Zeile, keiner Zeile oder einem Error. Diese Asymmetrie entscheidet die Architektur für auditierte Workflows.
  • Anthropics eigener Benchmark setzt vanilles Top-20-Vector-Retrieval auf 5,7 % Miss-Rate, eine von siebzehn Abfragen, bevor irgendeine Cleverness greift. Strukturierte Queries gegen ein typisiertes Schema sind konstruktiv deterministisch.
  • Governance für Vector-Stores lebt in deinem Retrieval-Code; für strukturierte Stores in der Datenbank. Compliance kann nur eines davon auditieren.
  • Kosten skalieren bei Vector RAG mit Korpusgröße und bei Structured Retrieval mit Abfragevolumen. Wähl die Wachstumskurve, die zu deinem Geschäft passt, nicht die zum Pitch-Deck des Anbieters.
  • Microsoft, Salesforce, Snowflake und Databricks sind innerhalb eines Jahres alle auf Structured-First plus Vector-Fallback konvergiert. Diese Vier-Anbieter-Konvergenz ist das Signal, nicht irgendein einzelnes Webinar.

2014 wurde dasselbe Argument über Microservices gemacht: ein cleveres Muster aus einer anderen Domäne ausliefern, Unternehmen es übernehmen sehen, dann fünf Jahre später still wieder rausbauen sehen, als das Audit-Team auftauchte. Vector RAG hat gerade diesen Moment. Ich verbrachte einen Dienstag in einem Microsoft-Webinar namens „When Copilot Studio meets Dataverse" und erwartete einen weiteren Anbieter-Pitch. Bekommen habe ich den Moment, in dem sich für mich eine Rahmung kristallisierte. Der Vortrag selbst ist okay. Das Argument darunter ist schärfer als der Vortrag: Für Enterprise Agents innerhalb von Microsoft 365 ist Vector Retrieval der falsche Default. Structured Retrieval gegen einen typisierten Tabellen-Store gewinnt auf den drei Achsen, die im Audit zählen: Genauigkeit, die du messen kannst; Governance, auf die du zeigen kannst; und eine Kostenlinie, die nicht mit Token-Zahl wächst.

Das ist kein „RAG ist tot"-Stück. RAG ist nicht tot. RAG ist ein Werkzeug, und für die spezifische Arbeit, die Enterprise Agents leisten (CRM-Lookups, HR-Fragen, Bestandsabfragen, Ticket-Triage), greifst du zuerst zu einem anderen. Der Vector-Store behält seine Aufgabe für unstrukturierte Korpora und explorative Abfragen. Für alles andere schlagen das typisierte Schema, die Row-Level-Security und der deterministische Query-Plan den Cosinus-Score, bevor du den Prompt zu Ende geschrieben hast.

In diesem Artikel

Structured Retrieval schlägt Vector RAG für Enterprise Agents

Warum jetzt: vier Anbieter konvergierten auf dieselbe Form

Auf einen einzelnen Vortrag würde ich mich nicht stützen. Der Grund, dass ich das schreibe: Vier große Anbieter haben innerhalb eines Jahres etwa dieselbe Architektur ausgeliefert. Microsofts Dataverse MCP Server ging am 15.12.2025 GA und legt Query, Knowledge-and-Search, Create und Update als MCP-Primitive frei. Salesforce lieferte Agentforce auf Data Cloud mit demselben Strukturplus-Vector-Retriever-Interface. Snowflakes Cortex Analyst kombiniert mit Cortex Search als „better together"-Muster. Databricks' Genie sitzt auf Unity Catalog und greift nur dann auf den Vector-Index zu, wenn die strukturierte Abfrage nicht antworten kann.

Das ist kein Zufall. Das ist Enterprise-Gravitation. Die Form, auf die diese Anbieter konvergiert sind, hat einen typisierten, governcten Tabellen-Store als primäre Retrieval-Oberfläche und Vector Retrieval als Fallback für die unstrukturierten Spalten. Der Grund ist nicht akademisch. Es ist derselbe Grund, aus dem jedes dieser Unternehmen ein Compliance-Team hat: Strukturierte Stores erlauben dir ein Bild davon, wer was lesen darf. Vector-Stores erlauben dir ein Bild davon, wie dicht die Embedding-Wolke in 1.536 Dimensionen ist, was für niemanden im Audit-Komitee nützlich ist.

Der Gegenstrang ist real und benennenswert. Anthropics Forschung zu Contextual Retrieval zeigt, dass ein Kontextualisierungs-Pass über einem vanilla Embedding-Store Top-20-Retrieval-Failure von 5,7 % auf 1,9 % drückt, zu rund 1,02 US-Dollar pro Million Dokument-Token mit Prompt-Caching. Der Akita-Beitrag „RAG is dead, long context won" argumentiert weiter, dass Claude Code Files-on-Disk plus grep nutzt, keine Vector DB, und dass 1M-Token-Fenster viele Internal-Tool-Retrieval-Probleme verschwinden lassen. Beide sind legitim. Keines löst, was ich gleich argumentiere.

Der Fehlermodus, den Vector RAG nicht zugibt

Reines Vector Retrieval hat eine messbare Untergrenze bei Faktenabfragen, und es scheitert still. Anthropics eigener Benchmark auf Claude mit Top-20-Chunks liegt bei 5,7 % Retrieval-Failure-Rate vor Contextual Retrieval. Das ist eine One-in-seventeen-Miss-Baseline auf einem Korpus, den Anthropic so engineered hat, dass die eigenen Embeddings gut aussehen. Anthropics Kontextualisierungs-Tricks drücken sie auf 1,9 %, was großartig klingt, bis du es auf einem HR-Agent rechnest, der 50.000 Urlaubsfragen pro Quartal beantwortet. 1,9 % von fünfzigtausend sind neunhundertfünfzig falsche Antworten pro Quartal. In einer regulierten Umgebung ist jede einzelne ein Incident.

Das tiefere Problem ist nicht die Rate. Es ist die Asymmetrie. Eine SQL-Abfrage gegen eine typisierte Tabelle gibt entweder eine Zeile zurück, gibt keine Zeile zurück oder wirft. Alle drei Ausgänge sind laut und strukturiert. Eine Vector-Abfrage gibt einen plausiblen Textblob mit hohem Cosinus-Score zurück, ob es der richtige Blob ist oder nicht. Das halluzinierte Retrieval sieht exakt aus wie das korrekte. Der Agent handelt identisch danach. Du findest es erst ein Jahr später raus, wenn eine interne Auditorin eine falsche Antwort durch die Logs zurückverfolgt und einen selbstbewussten Cosinus-Score von 0,81 findet, der auf das falsche Policy-Dokument zeigt.

Diesen Teil hat das Microsoft-Webinar konkret gemacht. Der Vortragende fragte einen Copilot Studio-Agent live, „Anlagen im selben Bezirk" zu listen, über Vector-Knowledge-Retrieval. Der Agent trunkte auf das Top-Result und gab drei Zeilen zurück, wo acht standen. Der Schwenk auf der Bühne ging zum Dataverse-List-Rows-Tool, das eine OData-Query erzeugt, die der Agent als strukturierten Text emittiert, und er bekam die vollen acht Zeilen zurück. Das ist kein Anbieter-Demo-Flex. Das ist der Fehlermodus. RAG gibt konstruktiv die Top-N zurück. Wenn deine Frage „gib mir alles, was X matcht" ist, ist die Architektur falsch, bevor das Modell falsch ist.

Der ehrliche Gegeneinwand: Das ist eine Tooling-Entscheidung, keine Architektur-Entscheidung. Du kannst nachverarbeiten. Du kannst Hybrid BM25 plus Rerank nutzen, um die Failure-Rate Richtung null zu treiben. Du kannst aggressiver vorindizieren. Jede dieser Bewegungen ist real. Keine ändert die Tatsache, dass die strukturierte Abfrage deterministisch und die Vector-Abfrage probabilistisch war, und dass „deterministisch" ein Feature ist, das das Security-Team buchstabieren kann.

Substrat und Governance, die du auf Datenbankebene auditieren kannst

Das Substrat ist interessanter, als der Vortrag klingen ließ. Richtest du einen Copilot Studio-Agent auf eine Dataverse-Tabelle als Wissensquelle, bekommst du bis zu fünfzehn Tabellen pro Quelle, verpflichtende Entra-ID-Authentifizierung (kein anonymer Modus erlaubt) und ein Spaltenglossar, das der Orchestrator nutzt, um Nutzerformulierung in typisierte Filter zu übersetzen. Der Agent schreibt kein OData; der Orchestrator tut es, mit den Spaltensynonymen als Wörterbuch. Das ist dasselbe Muster, das Snowflake Semantic Model nennt und Databricks Unity-Catalog-Metadaten. Es ist konvergiert, weil es funktioniert.

Der Hebel, den der Vortrag nur angedeutet hat, ist der Dataverse MCP Server, der am 15.12.2025 GA ging. Vier Primitive: Query, Knowledge-and-Search, Create, Update. Das Query-Primitiv emittiert OData gegen typisierte Spalten. Das Knowledge-and-Search-Primitiv läuft eine Relevance Search über indizierte Text-Spalten, gibt IDs zurück, die du dann per Query rehydrierst. Create und Update schließen den agentischen Loop: Ein Agent kann nicht nur strukturierte Daten lesen, er kann über denselben auditierten Pfad zurückschreiben.

Hier sieht ein voll typisierter Retrieval-Call aus, geschrieben zur Klarheit, nicht für Produktion:

from anthropic import Anthropic
import os

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

response = client.messages.create(
    model="claude-sonnet-4-7",
    max_tokens=1024,
    tools=[{
        "name": "dataverse_query",
        "description": "Retrieve facility rows from Dataverse by district and status.",
        "input_schema": {
            "type": "object",
            "properties": {
                "district": {"type": "string", "enum": ["north", "south", "east", "west"]},
                "status": {"type": "string", "enum": ["active", "closed"]},
                "limit": {"type": "integer", "maximum": 100}
            },
            "required": ["district"]
        }
    }],
    messages=[{"role": "user", "content": "List active facilities in the west district."}]
)

Zwei Dinge zu beachten. Das Tool-Schema ist der Retrieval-Vertrag: Der Agent kann nicht nach district = "west-ish" fragen, weil das Enum es verbietet. Und das Retrieval ist auditierbar: Das Chain-of-Thought-Log im Activity-Tab von Copilot Studio zeigt exakt, welchen Filter der Orchestrator emittiert hat, bevor die Zeile die Datenbank verlässt. In einem Vector-Store loggst du die Query, das Embedding, die Top-K-Ergebnisse und hoffst, rekonstruieren zu können, was der Agent tatsächlich gesehen hat. In Dataverse loggst du den OData-Ausdruck und die Zeilen-IDs, und das Audit-Bild schreibt sich selbst.

💡 In einem Vector-Store lebt die Sicherheitsgrenze in deinem Retrieval-Code. In einem strukturierten Store lebt sie in der Datenbank. Das eine ist von einem Compliance-Team auditierbar; das andere durch Lesen jedes PR.

Hier erwarte ich Pushback, daher präzise. Drei verschachtelte Behauptungen, in der Reihenfolge ihrer Bedeutung.

Dataverse erbt Entra ID, Purview und Business-Unit-Row-Level-Security per Default. Wenn ein Copilot Studio-Topic User-Authentifizierung an hat, reicht der Agent die Identität der angemeldeten Nutzerin an Dataverse, das die Standard-Security-Rollen und Record-Level-Permissions anwendet. Der Business-Unit-Tree bedeutet, Zugriff fließt entlang einer Hierarchie, die deine IT einmal gezeichnet hat. Der Agent bekommt kein eigenes Berechtigungsmodell; er borgt sich das der Nutzerin. Das ist, was „die Sicherheitsgrenze lebt in der Datenbank" praktisch meint.

Zweite Behauptung, die ehrliche: RLS ist nicht magisch. SQL Server und Postgres RLS haben dokumentierte Side-Channel-Lecks über Timing, Fehlermeldungen und Aggregation. Das ACM-SIGMOD-2023-Paper zu RLS-Seitenkanälen geht die Angriffsfläche detailliert durch. Strukturiertes RLS hat bekannte, begrenzte Fehlermodi, die du patchen und auditieren kannst. Das ist die Asymmetrie. Vector Retrieval hat unbegrenzte Fehlermodi, die erst ans Licht kommen, wenn ein falsches Embedding spurlos an die falsche Nutzerin leakt.

Dritte Behauptung, die tragende: Reine Vector-Stores haben keine native Tenant-Grenze. Wie Sonatype klar sagt: „Embeddings einer Nutzergruppe können unbeabsichtigt in den Abfrageergebnissen einer anderen auftauchen, wenn Zugriffskontrollen nicht auf Vector-Ebene durchgesetzt werden." Du kannst Per-Tenant-Namespaces anbauen. Du kannst jeder Query in deinem Retrieval-Code ein Tenant-Filter voranstellen. Beides funktioniert, bis zu dem Tag, an dem ein Junior eine Bugfix-PR liefert, die den Namespace-Check auf einem Pfad umgeht. Die Datenbank erzwingt keine Row-Ownership; dein Retrieval-Code tut das. Das ist eine Klasse Bug, kein Feature.

Hier der Chain-of-Thought-Trace eines echten Dataverse-basierten Agent, auditiert auf Row-Ebene:

{
  "user_principal": "alice@contoso.com",
  "business_unit": "EMEA-Finance",
  "tool_call": "dataverse_query",
  "filter": "district eq 'west' and statuscode eq 1",
  "rows_returned": 8,
  "row_ids": ["fa-001", "fa-007", "fa-012", "fa-019", "fa-024", "fa-031", "fa-038", "fa-044"],
  "rls_applied": true,
  "rls_predicate": "owningbusinessunit_id eq alice.bu_id or sharing.grant exists"
}

Du kannst dieses Log nach rls_applied: false greppen und jedes Retrieval finden, das ohne Row-Level-Enforcement lief. Versuch das Äquivalent gegen ein Pinecone-Query-Log. Das grep ist nicht der Punkt. Der Punkt ist, dass das Structured Retrieval das Audit emittiert, das du wolltest; das Vector Retrieval emittiert einen Cosinus-Score und eine Chunk-ID.

Das Kosten- und Latenzargument

Ich halte das kurz, weil die Zahlen die Arbeit tun. Eine Vector RAG-Pipeline kostet dich Embeddings (einmalig pro Chunk, wiederkehrend pro Reindex), Retrieval (pro Abfrage, billig) und den LLM-Call (pro Abfrage, teuer). Anthropics Contextual Retrieval ergänzt 1,02 US-Dollar pro Million Dokument-Token für den Kontextualisierungs-Pass plus die Rerank-Kosten. Für einen Korpus von einer Milliarde Dokument-Token sind das tausend Dollar, bevor du eine einzige Abfrage bedienst. Die Kosten skalieren mit Korpusgröße, nicht mit Abfragevolumen.

Ein Structured-Retrieval-Call gegen Dataverse kostet dich die OData-Query (Copilot Studio-Nachrichten werden unter deiner Power-Platform-Lizenz gezählt; nicht gratis, aber als separate Per-Message-Position), den LLM-Call zur Intent-Übersetzung (ein Orchestrator-Pass, typischerweise ein paar hundert Token Tool-Schema je nach Enum-Kardinalität) und den LLM-Call zur Antwortformulierung (ein zweiter Pass über die zurückgegebenen Zeilen, typischerweise ein paar tausend Token für 10 bis 50 Zeilen). Die Kosten skalieren mit Abfragevolumen, nicht mit Korpusgröße. Für ein CRM mit zehn Millionen Zeilen und hunderttausend Queries pro Monat zahlt die Vector-Pipeline für die Indizierung von zehn Millionen Zeilen. Die strukturierte Pipeline zahlt für hunderttausend Tool-Calls. Die Arithmetik ist nicht subtil.

Latenz erzählt dieselbe Geschichte. Der Akita-Beitrag berichtet, dass Gemini 2.0 Flash bei 600k Tokens Kontext rund 60 Sekunden trifft für den Long-Context-frisst-RAG-Ansatz. Eine typisierte Abfrage gegen eine indexierte Dataverse-Spalte kehrt in niedrigen zweistelligen Millisekunden zurück. Der LLM-Call zur Antwortformulierung ist der Long Pole, und der ist es in jedem Ansatz. Structured Retrieval macht das Modell nicht schneller. Es stoppt nur, dass du auf dem Weg zum gleichen Modell für Embeddings, Top-K-Reranking und Kontextfenster-Inflation zahlst.

| Kostenachse | Vector RAG | Structured (Dataverse) | |---|---|---| | Indizierungskosten | Skaliert mit Korpusgröße | Null (DB-Index existiert) | | Per-Query-LLM-Token | Top-K-Chunks + Antwort | Tool-Definition + Antwort | | Retrieval-Latenz | 50 bis 500 ms (Vector) | 5 bis 50 ms (indexiert) | | Reindex-Frequenz | Bei jeder Korpusänderung | Nie (Live-DB) | | Audit-Kosten | Custom-Logging nötig | Built-in |

Der ehrliche Vergleich: Structured Retrieval kostet dich etwas anderes, nämlich die Engineering-Zeit, um ein Schema zu bauen und das Glossar zu kuratieren. Das ist echte Kosten. Sie taucht nur in deinem Sprint-Planning auf, nicht in deiner AWS-Rechnung.

Wo Structured Retrieval ehrlich verliert

Ein Stück, das seine Tradeoffs nicht benennt, ist ein Sales-Deck. Hier sind vier Stellen, an denen ich weiterhin zuerst zu Vector Retrieval greife.

Unstrukturierte Korpora. PDF-Policy-Dokumente, Meeting-Transkripte, Knowledge-Base-Artikel, interne Wikis. Alles, wo die Retrieval-Einheit ein Absatz ist, keine Zeile. Die strukturierte Pipeline kann dir hier nicht helfen, weil es kein Schema zum Abfragen gibt. Vector Retrieval mit Contextual Chunking (Anthropics 5,7-zu-1,9-Prozent-Verbesserung) ist das richtige Werkzeug. Dataverse anerkennt das: Multiline-Text-Spalten und Datei-Anhänge werden im Hintergrund in semantische Indizes verarbeitet. Selbst Microsoft tut nicht so, als bewältige Structured Retrieval ein PDF.

Explorative Abfragen ohne bekanntes Schema. Wenn die Nutzerin nicht weiß, wonach sie sucht, und der Agent Muster entdecken soll, scheitert Structured Retrieval, weil es nichts zu filtern gibt. Das Fuzzy-Discovery-Primitiv im MCP-Server von Dataverse existiert genau dafür: Es macht zuerst eine Relevance Search über indexierten Text, gibt Kandidaten-IDs zurück und übergibt erst dann an typisiertes Retrieval. Das Muster ist hybrid. Wer „immer structured" oder „immer vector" sagt, verkauft dir etwas.

Realistische Enterprise-Schemata in Größe. Text-to-SQL ist schwer. Spider 2.0 benchmarkt GPT-Klasse-Modelle gegen Enterprise-Schemata mit 3000+ Spalten und mehreren Dialekten, und o1-preview kommt auf 17,0 % Execution-Accuracy versus 91,2 % auf dem kuratierten Spider-1.0-Benchmark. Die strukturierte Pipeline unterstellt, dass du Tool-Beschreibungen schreiben kannst, die das Schema einschränken. Auf einem CRM mit tausend Tabellen und überlappenden Foreign Keys wird diese Annahme schnell teuer. Snowflakes Cortex Analyst bei 90 % versus GPT-4o bei 51 % ist auf einem 150-Fragen-Internen-Benchmark, das anbieterfreundlich ist. Greif zur Richtungsaussage, nicht zur Absolutzahl.

Cross-Org-Public-Data-Q&A. Wenn dein Agent Fragen über einen öffentlichen Korpus beantwortet (Rechtsprechung, wissenschaftliche Papers, öffentliche Filings), gibt es keinen Tenant zum Durchsetzen, kein Schema, das du kontrollierst, und kein Dataverse, auf das du zeigen kannst. Vector Retrieval über einen öffentlichen Index, ggf. ergänzt um grep-artige lexikalische Suche wie sie Claude Code nutzt, ist die korrekte Architektur.

Die ehrliche Lesart: Structured Retrieval ist der richtige Default innerhalb der Enterprise-Mauer. Außerhalb ändert sich die Rechnung. Die vier Fälle oben sind keine Edge Cases; sie sind häufig. Sie sind auch nicht das, was Enterprise-M365-Agents die meiste Zeit tun.

Was sich daran ändert, wie du Agents dieses Quartal baust

Fünf konkrete Moves, in Prioritätenfolge.

Auditiere deine drei wichtigsten Agent-Use-Cases auf Retrieval-Form. Für jeden: Liegen die zugrundeliegenden Daten bereits in einem typisierten Store mit Schema und Zugriffskontrollen? Wenn ja, default auf Structured Retrieval und weiter. Wenn nein, frage, ob du sie dort hinbekommst, bevor du die Vector-Pipeline baust. Die meisten „wir brauchen RAG"-Gespräche lösen sich an diesem Schritt auf.

Lebst du in Microsoft 365, modelliere deinen Agent zuerst gegen Dataverse. Nutze den Knowledge-Source-Pfad fürs schnelle Prototyping und das List-Rows-Tool mit Natural-Language-Input-Descriptions für Produktions-Retrieval. Behandle den MCP-Server als Prototyping-Oberfläche, nicht als Produktions-Primitiv: Wie der Vortragende des Webinars einräumte, defaultet MCP auf Equality-Filter und kann Fuzzy-Intent ohne Supervision verfehlen.

Bau das Glossar vor dem Agent. Spaltensynonyme und Term-Definitionen sind das entscheidende Artefakt im Structured-Retrieval-Stack. Sie sind es, womit der Orchestrator „west" in district eq 'W' übersetzt. Ohne sie kann der Agent nicht routen. Updates an Glossar-Termen in Dataverse propagieren in bis zu fünfzehn Minuten, operativ in Ordnung, aber vor der ersten Live-Demo wissenswert.

Logge das Retrieval, nicht nur die Antwort. Jede strukturierte Abfrage, die der Agent emittiert, sollte mit Nutzer-Principal, Filter-Ausdruck, zurückgegebenen Row-IDs und angewandtem RLS-Prädikat erfasst werden. Das ist die Audit-Oberfläche, die du gekauft hast, als du strukturiert gewählt hast. Sie zu erfassen ist nicht optional; sie ist der Grund, weshalb du diese Architektur gewählt hast.

Plan den Hybridpfad. Wähl einen Use Case, in dem die Daten echt unstrukturiert sind (PDFs, Transkripte, KB-Artikel), und bau ihn auf Vector Retrieval mit Contextual Chunking. Du brauchst beide Pipelines am Ende. Zu wissen, zu welcher du greifst, ist wichtiger als einen Sieger zu küren.

Offene Fragen

Drei Stücke, an denen ich updaten erwarte, etwa in der Reihenfolge, in der ich korrigiert zu werden erwarte.

Der Dataverse MCP Server ist bei GA sechs Monate alt. Ich habe keine unabhängigen Benchmarks zu seiner Retrieval-Accuracy gegen ein Held-out-Enterprise-Schema gesehen. Microsofts Aussagen dazu sind intern. Das erste Mal, dass ein Dritter Spider 2.0 mit den MCP-Primitiven als Tool-Oberfläche neu fährt, weiß ich, ob meine „Structured gewinnt"-Behauptung realistische Schema-Komplexität übersteht oder ob sie auf den Stapel anbieterkuratierter Benchmarks wandert, die die VLDB-2026-BIRD-Kritik bereits abgefackelt hat.

Das Long-Context-Gegenargument wird stärker. Wenn 10M-Token-Fenster mit vernünftiger Latenz und Kosten in Produktion landen, wird „leg einfach das ganze CRM ins Kontextfenster" eine reale Option, und die Retrieval-Architektur zählt weniger. Die LightOn-Erwiderung und die akademische RAG-Verteidigung halten dagegen, aber die Ökonomie bewegt sich. Ich würde die nächsten drei Jahre Architekturentscheidungen nicht darauf setzen, dass Kontextfenster teuer bleiben.

Die dritte Unsicherheit ist operativ. Wie verhält sich die Structured-Retrieval-Pipeline, wenn das Schema driftet? Wenn eine neue Spalte hinzukommt, ein Synonym veraltet, ein RLS-Prädikat sich ändert? Ich habe keine guten Antworten auf Schema-Drift-Detection für agentische Stacks gesehen. Der Microsoft-Power-Platform-Blogbeitrag zu Dataverse als Agent Data Platform wedelt das weg. Ich hätte gern eine echte Kriegsgeschichte, bevor ich dem in Produktion traue.

Wenn du in eine Version dieses Problems läufst und deine Tradeoffs anders aussehen als meine, will ich davon hören. Ich erwarte, dass Teile dieses Arguments schlecht altern, besonders die Long-Context-Ökonomie. Wenn du denkst, Structured Retrieval sei der falsche Default innerhalb der M365-Mauer, ist der schnellste Weg, mich umzustimmen, ein konkretes Gegenbeispiel. Schreib mir.