"Hilfe! unsere KI-Modellkosten sind durch das Dach!" Während ChatGPT und seine Cousins einen Goldrush von AI-gestützten Anwendungen ausgelöst haben, ist die Realität des Aufbaus von Anwendungen auf der Grundlage von LLMs komplexer als ein API-Anruf auf eine Web-Schnittstelle zu schlagen. Jeden Tag fließt mein LinkedIn-Feed mit neuen "AI-betriebenen" Produkten. Einige analysieren rechtliche Dokumente, andere schreiben Marketing-Kopien und einige tapfere wenige versuchen sogar, die Softwareentwicklung zu automatisieren. Diese "Wrapper-Unternehmen" (wie sie manchmal abstoßend genannt werden) trainieren möglicherweise nicht ihre eigenen Modelle, aber viele lösen echte Probleme für Kunden und finden echte Produkt-Markt-Fit basierend auf den aktuellen Anforderungen der Unternehmen. Aber hier ist die Sache: Selbst wenn Sie Modelle nicht von Grund auf trainieren, ist das Skalieren einer KI-Anwendung von der Proof-of-Concept-Produktion bis zur Produktion wie das Navigieren in einem Labyrinth. Um es besser zu verstehen, lassen Sie uns das mit einem echten Beispiel zusammenbrechen. Stellen Sie sich vor, wir bauen "ResearchIt" (nicht ein echtes Produkt, aber tragen Sie mit mir), eine Anwendung, die Forschern hilft, akademische Papiere zu verdauen. Möchten Sie eine schnelle Zusammenfassung dieses dichten Methodikabschnitts? Müssen Sie die wichtigsten Erkenntnisse aus einem 50-seitigen Papier extrahieren? Version 1.0: The Naive Approach Version 1.0: Der naive Ansatz Wir fahren hoch auf dem OpenAI-Hype-Zug - Unsere erste Version ist wunderschön einfach: Forscher laden Stücke eines Papiers hoch (spezifische, relevante Abschnitte) Unser Backend übermittelt den Text an GPT-5 mit einem Anruf wie "Sie sind ein hilfreicher Forschungsassistent. Analysieren Sie den folgenden Text und liefern Einblicke streng aus dem Abschnitt, der vom Benutzer zur Verfügung gestellt wird......" Magie geschieht, und unsere Benutzer erhalten ihre Erkenntnisse Die einfachheit ist schön. die kosten? nicht so viel. Da mehr Forscher unser Tool entdecken, sehen unsere monatlichen API-Rechnungen aus wie Telefonnummern.Das Problem ist, dass wir jede Abfrage an GPT-5 senden, den Rolls-Royce der Sprachmodelle, wenn ein Toyota Corolla oft in Ordnung wäre. Ja, GPT-5 ist leistungsstark, mit seinem 128k Kontextfenster und starken Argumentationskapazitäten, aber bei 1,25 US-Dollar pro 1M-Eingangstoken und 10 US-Dollar pro 1M-Ausgangstoken steigen die Kosten schnell an. Für einfachere Aufgaben wie Zusammenfassung oder Klassifizierung liefern kleinere Modelle wie GPT-5 mini (etwa 20% der Kosten), GPT-5 nano (etwa 4%) oder Gemini 2.5 Flash-Lite (etwa 5%) große Ergebnisse zu einem Bruchteil des Preises. Open-Source-Modelle wie Meta's LLaMA (3 oder 4 Serie) oder verschiedene Modelle von Mistral oder bieten auch flexible und kosteneffiziente Optionen für allgemeine oder domain-spezifische Aufgaben, obwohl die Feinabstimmung oft unnötig für leichtere Workloads ist. Die Wahl hängt wirklich von den folgenden Dingen ab: Ausgabequalität: Kann das Modell konsequent die Genauigkeit Ihrer Anwendung benötigen? unterstützt das Modell die Sprache, mit der Sie arbeiten möchten? Reaktionsgeschwindigkeit: Warten Ihre Benutzer diese zusätzlichen Millisekunden für bessere Ergebnisse? Die typische Reaktionszeit für jede App sollte innerhalb der 10-Sekunden-Marke sein, damit Benutzer das Interesse nicht verlieren, so dass Geschwindigkeit definitiv zählt. Datenintegrität: Wie sensibel sind Ihre Daten und was sind Ihre Datenschutzanforderungen? Ressourcenbeschränkungen: Was ist Ihr Budget, sowohl für Kosten als auch für Engineering-Zeit? Für unseren Forschungspapier-Analysator brauchen wir keine Poesie über Quantenphysik; wir brauchen eine zuverlässige, kosteneffiziente Zusammenfassung. Bottom Line: Know Your Application Needs Bottom Line: Kennen Sie Ihre Anwendungsbedürfnisse Wenn Sie eine schnelle Einrichtung benötigen, können proprietäre Modelle die Kosten rechtfertigen. Wenn Erschwinglichkeit und Flexibilität mehr zählen, sind Open-Source-Modelle eine starke Wahl, insbesondere wenn kleine Qualitätskompromisse akzeptabel sind (obwohl es einige Infrastrukturüberschüsse geben kann). Forscher lieben, wie es dichte akademische Papiere zusammenfasst, und unsere Benutzerbasis wächst schnell. Aber jetzt wollen sie mehr; anstatt nur die Abschnitte zu zusammenfassen, die sie hochladen, wollen sie die Flexibilität, gezielte Fragen über das gesamte Papier auf effektive Weise zu stellen. Klingt einfach, richtig? Senden Sie einfach das gesamte Dokument an GPT-5 und lassen Sie es seine Magie arbeiten. Nicht so schnell. Akademische Papiere sind lang. Selbst mit GPT-5s großzügigem 128K-Tokenlimit ist das Senden vollständiger Dokumente pro Abfrage ein teurer Overkill. , was bei der Durchführung von Spitzenforschung schädlich ist. Degradieren Degradieren Also, was ist die Lösung? Version 2.0: Smarter chunking and retrieval Version 2.0: Smarter Chunking und Retrieval Die Schlüsselfrage hier ist, wie skalieren wir, um diese Anforderung zu erfüllen, ohne unsere API-Rechnung in Brand zu setzen und auch die Genauigkeit im System zu erhalten? **Answer is: \ (RAG). Instead of dumping the entire document into the LLM, we intelligently retrieve the most relevant sections before querying. This way we don’t need to send the whole document each time to the LLM to conserve the tokens but also make sure that relevant chunks are retrieved as context for the LLM to answer using it. This is where Retrieval-Augmented Generation (RAG) comes in. Retrieval erhöhte Generation Retrieval erhöhte Generation There are 3 important aspects to consider here: Chunking Speicherung und Chunk Retrieval Verfeinerung mit fortgeschrittenen Recovery-Techniken. Schritt 1: Chunking – Teilen Sie das Dokument intelligent auf Bevor wir die relevanten Abschnitte abrufen können, müssen wir das Papier in verwaltbare Stücke brechen. Ein naiver Ansatz könnte den Text in festgestellte Segmente aufteilen (sagen, alle 500 Wörter), aber dies riskiert, den Kontext in der Mitte des Denkens zu verlieren. Stellen Sie sich vor, wenn ein Stück endet mit: "Das Experiment zeigte eine 98-prozentige Erfolgsrate in..." ...und das nächste Stück beginnt mit: "...die Reduzierung falscher Positiven bei der Erkennung von Lungenkrebs im frühen Stadium." Section-basiertes Chunking: Verwenden Sie die Dokumentstruktur (Titel, Abstracts, Methodik usw.) um logische Spalten zu erstellen. : Overlap chunks slightly (e.g., 200-token overlap) to preserve context across boundaries. Sliding window chunking Adaptive Chunking: Dynamische Anpassung der Stückgrößen basierend auf Satzgrenzen und Schlüsselthemen. Section-based chunking Fenster schieben Chunking Adaptive Chunking Schritt 2: Intelligente Speicherung und Wiederherstellung Once your document chunks are ready, the next challenge is storing and retrieving them efficiently. With modern LLM applications handling millions of chunks, your storage choice directly impacts performance. Traditional approaches that separate storage and retrieval often fall short. Instead, the storage architecture should be designed with retrieval in mind, as different patterns offer distinct trade-offs for speed, scalability, and flexibility. Die konventionelle Unterscheidung zwischen der Verwendung von relationalen Datenbanken für strukturierte Daten und NoSQL für unstrukturierte Daten gilt immer noch, aber mit einer Wendung: LLM-Anwendungen speichern nicht nur Text, sondern semantische Repräsentationen (Embeddings). In einer traditionellen Einrichtung können Dokumentstücke und ihre Embeddings in PostgreSQL oder MongoDB gespeichert werden.Dies funktioniert für kleine bis mittelständische Anwendungen, hat jedoch klare Einschränkungen, da Daten- und Abfragevolumen zunehmen. Die Herausforderung hier ist nicht Speicher, es ist der Abrufmechanismus.Traditionelle Datenbanken übertreffen bei exakten Übereinstimmungen und Bereichsanfragen, aber sie wurden nicht für semantische Ähnlichkeitssuchen erstellt. um Vektor-Ähnlichkeits-Suchen zu ermöglichen. Dies ist, wo Vektor-Datenbanken wirklich leuchten - sie sind gezielt für das Speicher-und-Retrieve-Muster gebaut, das LLM-Anwendungen verlangen - Embeddings als das primäre Attribut für das Abfragen zu behandeln, Optimierung speziell für nächste Nachbarn-Suchen. Die wahre Magie liegt in der Art und Weise, wie sie Ähnlichkeitsberechnungen handhaben. Während traditionelle Datenbanken oft komplexe mathematische Operationen zur Abfragezeit erfordern, verwenden Vektor-Datenbanken spezielle Indexierungsstrukturen wie (hierarchisch navigierbare kleine Welt) oder Inverted File Index) um ähnlichkeitssuche blitzschnell zu machen. PgVektor HNSW IVF PgVektor HNSW IVF Sie unterstützen typischerweise zwei primäre Ähnlichkeitsmetriken: Euklidische Entfernung: Besser geeignet, wenn die absoluten Unterschiede zwischen Vektoren von Bedeutung sind, besonders nützlich, wenn Einbettungen hierarchische Beziehungen kodieren. Cosine Ähnlichkeit: Standardwahl für die semantische Suche - es konzentriert sich auf die Richtung der Vektoren statt der Größe. Dies bedeutet, dass zwei Dokumente mit ähnlichen Bedeutungen, aber unterschiedlichen Längen immer noch effektiv übereinstimmen können. Die Wahl der richtigen Vektordatenbank ist entscheidend für die Optimierung der Abrufleistung in LLM-Anwendungen, da sie Skalierbarkeit, Abfrageeffizienz und operative Komplexität beeinflusst. und bieten schnelle ANN-Suche mit effizientem Rückruf - sie bewältigen das Skalieren automatisch, was sie ideal für dynamische Workloads mit minimaler Betriebsüberlastung macht. (IVF-basiert) bieten mehr Kontrolle und Kosteneffizienz im Maßstab, erfordern aber sorgfältige Tuning. pgvector mit Postgres integriert ermöglicht hybride Suche, obwohl es unter hohen Durchsatz-Workloads Grenzen treffen kann. Pinzette Weaviate Milus Pinzette Weaviate Milus Schritt 3: Fortgeschrittene Retrieval Strategien Während dichte Embeddings leistungsstarke semantische Übereinstimmungen ermöglichen, erfordern reale Anwendungen oft zusätzliche Schichten der Verfeinerung, um Genauigkeit, Relevanz und Effizienz zu verbessern. Keyword-basierte Suche (z.B. BM25, TF-IDF) ist ausgezeichnet für die Suche nach genauen Begriffen, aber kämpft mit semantischem Verständnis. Um dies zu überwinden, kombiniert eine Hybrid-Recovery-Strategie die Stärken beider Methoden. Das beinhaltet: Candidate Retrieving – Führen Sie sowohl eine Keyword- als auch eine Vektorähnlichkeitssuche parallel durch. Verschmelzungsergebnisse – Steuerung des Einflusses jeder Abrufmethode basierend auf der Abfrageart und den Anwendungsbedürfnissen. Reranking for optimal ordering – ensuring the most relevant information appears at the top based on semantic requirements. Eine weitere Herausforderung ist, dass die traditionelle Vektorsuche die nächstgelegenen Top-K-Embeddings abruft. LLMs verlassen sich auf Kontextfenster, was bedeutet, dass die blinde Auswahl der Top-K-Ergebnisse irrelevante Informationen einführen oder wichtige Details verpassen kann. Eine Lösung für dieses Problem ist die Verwendung des LLM selbst zur Verfeinerung. Einige Techniken, die für die Verfeinerung von LLM verwendet werden, sind wie folgt: Semantische Kohärenzfilterung: Anstatt rohe Top-K-Ergebnisse zu füttern, bewertet der LLM, ob die abgerufenen Dokumente einer logischen Progression im Zusammenhang mit der Abfrage folgen. Relevanzbasierte Neubewertung: Modelle wie Cohere Rerank, BGE oder MonoT5 können abgerufene Dokumente neu bewerten, fein gesäumte Relevanzmuster erfassen und Ergebnisse über Roh-Ähnlichkeits-Score hinaus verbessern. Kontext Erweiterung mit iterativem Abrufen: Statisches Abrufen kann indirekt relevante Informationen verpassen. LLMs können Lücken identifizieren, Nachfolgeabfragen generieren und die Abrufsstrategie dynamisch anpassen, um fehlende Kontexte zu sammeln. Semantische Kohärenzfilterung Relevance-Based Reranking Context Expansion with Iterative Retrieval Mit diesen Updates ist unser System besser ausgerüstet, um komplexe Fragen in mehreren Abschnitten eines Papiers zu bearbeiten und gleichzeitig die Genauigkeit aufrechtzuerhalten, indem die Antworten streng in den angegebenen Inhalten zugrunde gelegt werden. Version 3.0 - Building a Comprehensive and Reliable System Version 3.0 - Building a Comprehensive and Reliable System Zu diesem Zeitpunkt hat sich "ResearchIt" von einem einfachen Fragen-Antwort-System zu einem fähigen Forschungsassistenten entwickelt, der Schlüsselabschnitte aus hochgeladenen Papieren extrahiert, Methoden hervorhebt und technische Inhalte präzise zusammenfasst. What began as a system designed to summarize or interpret a single paper has now become a tool researchers want to use for deep, cross-domain reasoning. Researchers want it to reason across multiple sources, not just read one paper at a time. Die neue Welle der Fragen sieht aus wie: "Welche Optimierungstechniken für Transformatoren zeigen die besten Effizienzverbesserungen, wenn sie Einblicke aus Benchmarks, Open-Source-Implementierungen und jüngsten Forschungsarbeiten kombinieren?" “How do model compression results reported in this paper align with performance reported across other papers or benchmark datasets?” Dies sind keine einfachen Wiederherstellungsaufgaben mehr. sie fordern - die Fähigkeit, komplexe Informationen zu integrieren und zu interpretieren, zu planen und anzupassen, Werkzeuge effektiv zu verwenden, sich von Fehlern zu erholen und fundierte, evidenzbasierte Synthese zu produzieren. Multi-Source Argumentation Trotz seiner starken Verständnisfähigkeiten kämpft „ResearchIt“ 2.0 mit zwei großen Einschränkungen bei der Argumentation über verschiedene Informationsquellen: Cross-Sectional Analysis: Wenn Antworten sowohl Interpretation als auch Berechnung erfordern (z. B. FLOPs oder Genauigkeit aus Tabellen extrahieren und sie unter Bedingungen vergleichen). Cross-Source-Synthese: Wenn relevante Daten über mehrere Systeme leben - PDFs, Experimentallogs, GitHub-Repos oder strukturierte CSVs - und das Modell muss das Abrufen koordinieren, widersprüchliche Ergebnisse verschmelzen und eine kohärente Erklärung liefern. Diese Probleme sind nicht nur theoretisch, sie spiegeln die Herausforderungen der realen Welt in der Skalierbarkeit von KI wider.Da Datenökosysteme komplexer werden, müssen Organisationen über das grundlegende Abrufen hinausgehen in Richtung rationaler Orchestrierung - Systeme, die planen, handeln, bewerten und sich kontinuierlich anpassen können. Nehmen wir die erste Frage rund um die Analyse von Transformator-Optimierungstechniken - wie würden wir dieses Problem als Menschen lösen? A group of researchers or students would work on “literature review, i.e, collating papers on the topics, researching open source github repos, and identifying benchmark datasets. They would then extract data and metrics like FLOPs, latency, accuracy from these resources, normalize and compute aggregations and validate the results produced. This is not a one-shot process; it’s iterative, involving multiple rounds of refinement, data validation, and synthesis, after which an aggregated summary of verified results would be generated. So, what exactly did we do here? Break down the overarching question into smaller, focused subproblems - which sources to search, what metrics to analyze, and how comparisons should be run. Konsultieren Sie Domain-Experten oder vertrauenswürdige Quellen, um Wissenslücken zu schließen, Messwerte zu überprüfen und Kompromisse zu interpretieren. Schließlich synthetisieren Sie die Erkenntnisse in eine kohärente, evidenzbasierte Schlussfolgerung, vergleichen Sie die Ergebnisse und unterstreichen Sie konsistente oder einflussreiche Ergebnisse durch Iterationen. Dies ist im Wesentlichen vernünftige Orchestrierung - der koordinierte Prozess der Planung, Sammlung, Analyse und Synthese von Informationen über mehrere Systeme und Perspektiven. Schritt 1: Kette des Denkens / Planung Um den ersten Aspekt anzugehen, die Fähigkeit, mehrere Schritte durchzuführen, bevor man antwortet, das Konzept der (CoT) wurde eingeführt. CoT erlaubt Modellen, vor der Ausführung zu planen, was strukturierte Argumentation hervorruft, die ihre Interpretabilität und Konsistenz verbessert. Zum Beispiel würde ein CoT-Modell bei der Analyse von Transformator-Optimierungstechniken zuerst seinen Argumentationsweg beschreiben - den Umfang definieren (Training Effizienz / Modellleistung / Skalierbarkeit), relevante Quellen identifizieren, Bewertungskriterien und die Methode des Vergleichs auswählen und eine Ausführungssequenz erstellen. Kette des Denkens Kette des Denkens Als Fragen immer komplexer wurden, entwickelte sich eine einzige „Kette“ der Argumentation zu Tree of Thought (ToT) oder Graph of Thought (GoT) -Ansätzen - ermöglichen verzweigtes Argumentation und „Future Thinking“ Verhaltensweisen, bei denen Modelle mehrere mögliche Lösungswege erforschen, bevor sie auf das Beste konvergieren. Of course, adopting these reasoning-heavy models introduces practical considerations - primarily, cost. Running multi-step reasoning chains is computationally expensive, so model choice matters. Current options include: Closed-source models like OpenAI’s o3 and o4-mini, which offer high reasoning quality and strong orchestration capabilities. Open-source alternatives such as DeepSeek-R1, which provide transparent reasoning with more flexibility/ engineering effort for customization. Während nicht-denkende LLMs (wie LLaMA 3) immer noch Argumentation durch CoT-Prompting emulieren können, führen echte CoT- oder ToT-Modelle inhärent strukturierte Argumentation nativ aus. Schritt 2: Multi-Source-Workflows – Funktion Calling to Agents Das System muss sich dann über verschiedene spezialisierte Tools koordinieren – jedes als „Experte“ –, um Unterfragen zu beantworten, Aufgaben auszuführen, Daten zu sammeln und sein Verständnis durch iterative Interaktion mit seiner Umgebung zu verfeinern. OpenAI eingeführt Funktion Calling / Tools gaben den LLMs ihre erste wirkliche Fähigkeit, Sie stellen dem Modell ein Toolkit zur Verfügung – zum Beispiel Funktionen wie oder and the model decides which one to call, when to call it, and in what order. Let’s take a simple example: function calling take action search_papers(), extract_table( oder extract_table) Erzählung von Statistiken() function calling Aufgabe: "Die durchschnittliche gemeldete Genauigkeit für die BERT-Fine-Tuning berechnen." Ein Modell, das Funktionsaufruf verwendet, könnte antworten, indem es eine lineare Kette wie folgt ausführt: search_papers("BERT Fine-Tuning Genauigkeit") extract_table() für jedes Papier calculate_statistics() to compute the mean Dieses dumme Beispiel einer einfachen deterministischen Pipeline, in der ein LLM und eine Reihe von Tools durch vordefinierte Codewege orchestriert werden, ist einfach und effektiv und kann oft dem Zweck für eine Vielzahl von Anwendungsfällen dienen. und Wenn mehr Komplexität gerechtfertigt ist, eine might be the better option when flexibility, better task performance and model-driven decision-making are needed at scale (with the tradeoff of latency and cost). linear non-adaptive Agentischer Workflow Agentischer Workflow Iterative agentische Workflows sind Systeme, die nicht nur einmal ausgeführt werden, sondern . Like a human researcher, the model learns to recheck its steps, refine its queries, and reconcile conflicting data before drawing conclusions. Reflektieren, überprüfen und neu laufen Denken Sie an es als ein gut koordiniertes Forschungslabor, in dem jedes Mitglied eine unterschiedliche Rolle spielt: Retrieval Agent: The information scout. It expands the initial query, runs both semantic and keyword searches across research papers, APIs, github repos, and structured datasets, ensuring that no relevant source is overlooked. Es analysiert PDFs, Tabellen und JSON-Ausgänge, standardisiert dann die extrahierten Daten - normalisiert Metriken, vereint Einheiten und bereitet saubere Eingänge für die nachgelagerte Analyse vor. Computation Agent: The analyst. It performs the necessary calculations, statistical tests, and consistency checks to quantify trends and verify that the extracted data makes sense. Es identifiziert Anomalien, fehlende Einträge oder widersprüchliche Ergebnisse, und wenn etwas aussieht, löst es automatisch Re-Runs oder zusätzliche Suchanfragen aus, um die Lücken zu füllen. Synthesis Agent: The integrator. It pulls together all verified insights and composes the final evidence-backed summary or report. Each one can request clarifications, rerun analyses, or trigger new searches when context is incomplete, essentially forming a self-correcting loop - an evolving dialogue among specialized reasoning systems that mirror how real research teams work. Um dies in ein konkreteres Beispiel zu übersetzen, wie diese Agenten für unsere Transformator-Effizienzfrage eintreten würden: Initial Planning (Reasoning LLM): The orchestrator begins by breaking the task into sub-objectives discussed before. First Retrieval Loop: The Retrieval Agent executes the plan by gathering candidate materials — academic papers, MLPerf benchmark results, and open-source repositories related to transformer optimization. During this step, it detects that two benchmark results reference outdated datasets and flags them for review, prompting the orchestrator to mark those as lower confidence. Extraction & Computation Loop: Next, the Extraction Agent processes the retrieved documents, parsing FLOPs and latency metrics from tables and converting inconsistent units (e.g., TFLOPs vs GFLOPs) into a standardized format. The cleaned dataset is then passed to the Computation Agent, which calculates aggregated improvements across optimization techniques. Meanwhile, the Validation Agent identifies an anomaly - an unusually high accuracy score from one repository. It initiates a follow-up query and discovers the result was computed on a smaller test subset. This correction is fed back to the orchestrator, which dynamically revises the reasoning plan to account for the new context. Iterative Refinement: Following the Validation Agent’s discovery that the smaller test set introduced inconsistencies in the reported results - the Retrieval Agent initiates a secondary, targeted search to gather additional benchmark data and papers on quantization techniques. The goal is to fill missing entries, verify reported accuracy-loss trade-offs, and ensure comparable evaluation settings across sources. The Extraction and Computation Agents then process this newly retrieved data, recalculating averages and confidence intervals for all optimization methods. An optional Citation Agent could examine citation frequency and publication timelines to identify which techniques are gaining traction in recent research. Final Synthesis: Once all agents agree, the orchestrator compiles a verified, grounded summary like - “ ” Across 14 evaluated studies, structured pruning yields 40–60 % FLOPs reduction with < 2 % accuracy loss (Chen 2023; Liu 2024). Quantization maintains ≈ 99 % accuracy while reducing memory by 75 % (Park 2024). Efficient-attention techniques achieve linear-time scaling (Wang 2024) with only minor degradation on long-context tasks (Zhao 2024). Recent citation trends show a 3× rise in attention-based optimization research since 2023, suggesting a growing consensus toward hybrid pruning + linear-attention approaches. What’s powerful here isn’t just the end result - it’s the . Prozess Jeder Agent trägt, fordert Herausforderungen und verfeinert die Arbeit der anderen, bis eine stabile, multi-source-Schlussfolgerung entsteht. and MCP standardisiert, wie Modelle und Werkzeuge strukturierte Informationen austauschen – wie abgerufene Dokumente, analysierte Tabellen oder berechnete Ergebnisse –, um sicherzustellen, dass jeder Agent die Ergebnisse der anderen verstehen und aufbauen kann. Ergänzend ermöglicht die A2A-Kommunikation Agenten, unmittelbar miteinander zu koordinieren – Zwischenstaaten zu teilen, Klärungen anzufordern oder Folgemaßnahmen ohne Eingriff auszulösen. Das Modellkontextprotokoll (MCP) Agent zu Agent (A2A) Das Modellkontextprotokoll (MCP) Agent zu Agent (A2A) Step 3: Ensuring Groundedness and Reliability In dieser Phase haben Sie jetzt ein Agentensystem, das in der Lage ist, relativ komplexe und abstrakte Forschungsfragen in logische Schritte zu brechen, Daten aus mehreren Quellen zu sammeln, Berechnungen oder Transformationen durchzuführen, wenn nötig, und die Ergebnisse in eine kohärente, evidenzbasierte Zusammenfassung zusammenzustellen. facts - they predict the next most likely token based on patterns in their training data. That means their output is fluent and convincing, but not always Während verbesserte Datensätze und Trainingsziele helfen, kommt der wahre Schutz durch das Hinzufügen von Mechanismen, die überprüfen und korrigieren können, was das Modell in Echtzeit produziert. know Richtig Here are a few techniques that make this possible: Regelbasiertes Filtern: Definieren Sie domain-spezifische Regeln oder Muster, die offensichtliche Fehler erfassen, bevor sie den Benutzer erreichen.Zum Beispiel, wenn ein Modell eine unmögliche Metrik, ein fehlendes Datenfeld oder eine falsch geformte Dokument-ID herausgibt, kann das System es markieren und regenerieren. Cross-Verifizierung: Automatisch neu abfragen vertrauenswürdige APIs, strukturierte Datenbanken oder Benchmarks, um wichtige Zahlen und Fakten zu bestätigen. Wenn das Modell sagt "strukturiertes Schneiden reduziert FLOPs um 50%", überprüft das System diese gegen Benchmark-Daten, bevor es akzeptiert. Halluzinierte Details neigen dazu, zwischen den Läufen zu variieren, während die tatsächlichen Ergebnisse stabil bleiben - so behält das Modell nur die Mehrheits-konsistenten Schlussfolgerungen. Together, these layers form the final safeguard - closing the reasoning loop. Every answer the system produces is not just well-structured but . verified Und hier ist - was als ein einfaches abrufbasiertes Modell begann, hat sich nun zu einem robusten Forschungsassistenten entwickelt: Einer, der nicht nur grundlegende Fragen und Fragen beantwortet, sondern auch tiefe analytische Fragen anspricht, indem er Multi-Source-Daten integriert, Berechnungen ausführt und zugrunde liegende Erkenntnisse produziert, während er sich aktiv gegen Halluzinationen und Fehlinformationen verteidigt.
