Referenzarchitektur für produktionstaugliche Unternehmens-Agents-KI-Systeme
Erlernen Sie die grundlegenden Schichten, Merkstrategien, Abrufmethoden sowie Sicherheitsmaßnahmen, die erforderlich sind, um agierende KI-Systeme vom Prototypen zu zuverlässigen Unternehmensproduktionsystemen zu entwickeln.
Zusammenfassung
Der Übergang von zustandslosen Anwendungen mit großen Sprachmodellen (LLM) hin zu produktionsreifen agierenden KI-Systemen stellt einen bedeutenden Wandel in der Art und Weise dar, wie Unternehmen Software entwickeln. Frühe Bemühungen im Bereich Unternehmens-KI stützten sich stark auf grundlegende Retrieval-Augmented Generation (RAG)-Methoden – dabei wurden Dokumente in Embeddings umgewandelt und in das Kontextfenster einer Anfrage eingefügt. Dieser Ansatz funktioniert gut für einfache Frage-Antwort-Szenarien, reicht jedoch nicht aus für autonome Entscheidungsfindung, mehrstufiges, zustandsbasiertes Planen, widerstandsfähige Aufrufung von Tools sowie die Fähigkeit zur Selbstkorrektur im Laufe eines Workflows.
Enterprise Agentic AI schließt diese Lücke, indem sie Grundmodellien neu positioniert: Anstelle als direkte Schnittstelle zum Benutzer zu fungieren, wird das Modell zu einem reasoning-Komponenten, der in einer deterministischen Softwareumgebung integriert ist. Solche Systeme können ihre Umgebung wahrnehmen, große Ziele in kleinere Schritte aufteilen, interne Unternehmensdienste aufrufen und den Ausführungszustand über mehrstufige Transaktionen hinweg beibehalten. Um jedoch von einem funktionsfähigen Prototypen zu etwas zu gelangen, das in der Produktion eingesetzt werden kann, müssen instabile, nicht-deterministische Steuerungsschleifen, ein Kontextverlust über lange Sitzungen, Risiken der Berechtigungssteigerung sowie unkontrollierter Tokenverbrauch behoben werden.
Dieser Artikel stellt eine End-to-End-Referenzarchitektur vor, die sich an Architekten und Leiter der KI-Entwicklung richtet, die für Unternehmens-Agentensysteme verantwortlich sind. Er behandelt die grundlegenden Schichten, die jedes Agent benötigt, vergleicht Multi-Agent-Topologien, geht auf Integrationsmuster für unternehmensreife Suchfunktionen ein – mit besonderem Fokus auf Amazon Kendra – und enthält funktionierende Python-Beispiele, die für den Produktivbetrieb geeignet sind.
Abschnitt 1: Die kanonische Unternehmens-Agentenarchitektur
Kernschichten: Wahrnehmung, Reasoning, Planung, Speicher und Toolausführung
Ein für den Produktivbetrieb bereites Agentensystem trennt das probabilistische Grundmodell vom deterministischen Ausführungszeitraum, der es umgibt. In der Regel bestehen diese Architekturen aus fünf Kernschichten, die alle innerhalb eines verwalteten Laufzeitcontainers ausgeführt werden:
- Wahrnehmungsschicht: Sie wandelt rohe Unternehmenssignale – Telemetriedaten, Benachrichtigungen der Nutzer, webhook-Beispiele sowie API-Antworten – in saubere, typisierte Eingaben um, die der Rest des Systems verarbeiten kann. Dazu gehören die Reinigung der Eingaben, das Limitieren der Aufrufhäufigkeit sowie frühzeitige Prüfungen des Schemas, wobei all dies bereits vor dem Aufruf des LLM durchgeführt wird.
- Logikmotor: Das kognitive Zentrum, das von einem zugrunde liegenden LLM angetrieben wird (zum Beispiel Anthropic Claude 3.5 Sonnet oder AWS Bedrock-Modelle). Anstatt selbst Aktionen auszuführen, interpretiert dieser Motor den aktuellen Kontext, bewertet mögliche Vorgehensweisen und gibt strukturierte Angaben zu den Absichten ab.
Orchestrierungsmuster: Einzel-Agenten-Schleifen gegen Mehr-Agenten-Topologien
Die Wahl des richtigen Orchestrierungsmusters hängt stark davon ab, wie komplex das Zielgebiet ist:
- Einzel-Agenten ReAct-Schleifen: Eine Denk-Schleife, die durch die Phasen Gedanke, Handlung und Beobachtung läuft. Dies eignet sich für einfache, lineare Arbeitsabläufe, die mit weniger als 5 bis 8 verschiedenen Tools arbeiten. Bei komplexeren Fällen führt ein einzelner Agent oft zu überfüllten Kontextfenstern, unklaren Anweisungen und Unsicherheit bezüglich der Auswahl des richtigen Tools.
Zur Nutzung in unternehmensweiten Produktionsumgebungen ist die Supervisor Multi-Agent Topologie aufgrund ihrer klaren Zustandsgrenzen, der besseren Überprüfbarkeit sowie vorhersehbarerer Kontextkosten die empfohlene Standardlösung.
Abschnitt 2: Unternehmensweises Speichermanagement und Kontexthygiene
Speicherhierarchie: Arbeitsgedächtnis, kurzfristige Entwicklung und Langzeitgedächtnis
Betrachten Sie das Speichermanagement von Agenten als ein Problem der Ressourcenplanung. Ein unkontrolliertes Wachstum des Speichers erhöht die Inferenzkosten, verursacht Verzögerungen und führt dazu, dass das Modell den Überblick verliert, wenn der Kontext verschlechtert wird. Ein gut konzipierter Unternehmensagent benötigt eine schichtweise Speicherverstrukturung:
- Arbeitsgedächtnis (Scratchpad): Das aktuelle Kontextfenster – die derzeit gültigen Systemanweisungen, der Zustand der aktiven Aufgabe sowie die neuesten Tool-Ausgaben.
Strategien zur Komprimierung des Kontexts, Zurückhaltung von Daten und Isolation des Zustands
Damit der Kontext nicht unkontrolliert wächst, muss die Laufzeit aktiv Hygieneregeln durchsetzen:
- Abschneiden von Beobachtungen: Rohdaten der Tool-Antworten – wie beispielsweise ein JSON-Datensatz mit 500 Einträgen – dürfen niemals direkt in den Arbeitsmemory gelangen. Die Laufzeit muss die von einem Tool zurückgegebenen Daten vor dem Erreichen des Reasoning-Engines bereinigen, abschneiden oder zusammenfassen.
- Rolling-Window-Kompaktion: Sobald der Scratchpad einen festgelegten Budgetschwellenwert überschreitet (zum Beispiel 20 Prozent der gesamten Kontextgrenze des Modells), konsolidiert ein Kompaktionsschritt frühere Gesprächsschritte zu kompakten semantischen Zusammenfassungen und entfernt die ursprünglichen Rohaustausche.
- Isolement des Sub-Tasks-Zustands: Wenn der Supervisor eine Aufgabe an einen Sub-Agenten weiterleitet, erstellt er für diesen einen neuen Kontext, der nur das spezifische Ziel sowie die benötigten Parameter enthält – kein Teil der eigenen Überlegungshistorie des Supervisors dringt durch.
Abschnitt 3: Einführung in die tiefe Nutzung: Enterprise Retrieval Grounding über Amazon Kendra
Amazon Kendra als Produktions-Erkennungsschicht
Das Aufbauen eines Abrufpipelines in einer generischen Vektordatenbank bedeutet in der Regel, dass man eigenständig Logiken für die Dokumenteinholung, das Aufteilen in Blöcke, die Erzeugung von Embeddings sowie eine hybride Suchfusionsschicht von Grund auf entwickeln muss. Amazon Kendra hingegen bietet einen vollständig verwalteten Unternehmenssuchmaschinenanbieter, der all das bereits vorinstalliert bereitstellt. Er verfügt über eine integrierte, mehrstufige Verarbeitung natürlicher Sprache, eine strukturelle Analyse, die Tabellen, Überschriften und Fußnoten berücksichtigt, sowie ein hybrides Ranking-Modell, das lexikalische und semantische Signale miteinander verbindet.
In einem Unternehmensagenten-Stack fungiert Kendra in der Regel als Kern des Knowledge Grounding Subsystems – das Komponente, die es den Agenten ermöglicht, überprüften faktischen Kontext aus verschiedenen internen Datenquellen abzurufen, ohne das Risiko der Fragmentierung durch naive Aufteilung in Vektordatenspeicher.
Fortgeschrittene Anpassung der Relevanz und dynamisches Trimmen von Metadaten
Zur sicheren Unterstützung autonomer Entscheidungsfindung benötigen unternehmensreife Suchsysteme eine präzise Handhabung von Berechtigungen sowie anpassbare Kontrollmechanismen für die Relevanz:
- Eingebettete Zugriffssteuerungslisten (ACLs): Kendra zieht automatisch die auf Dokumentenebene in den Quellsystemen definierten ACLs heran und ordnet sie zu – unabhängig davon, ob es sich um SharePoint, Confluence oder S3 handelt. Wenn ein Agent eine Abfrage sendet, leitet er die Identität des authentifizierten Benutzers als
UserContext-Token weiter, und Kendra wendet ein Sicherheits-Trimmen auf Indexebene an, sodass kein Fragment, das der anfragende Benutzer nicht sehen darf, jemals beim Agenten ankommt.
_last_updated_at nach Aktualität, nach Geschäftskategorie oder durch exakte Übereinstimmungen in benutzerdefinierten Feldern wie Department oder ProjectCode eine Erhöhung vornehmen.Retrieve-API der allgemein einsetzbaren Query-API vorgezogen werden. Die Retrieve-API überspringt vollständig die auf die Benutzeroberfläche ausgerichteten Suchmetadaten und liefert stattdessen dichte, auf Absatzebene basierende Auszüge, die speziell dafür konzipiert sind, direkt in das Kontextfenster eines LLMs eingespeist zu werden.Abschnitt 4: Deterministische Schutzmechanismen, Tool-Validierung und Circuit Breakers
Vor- und Nachausführungskontrollen (Feedforward und Feedback)
Autonome Agenten benötigen klare Grenzen auf Softwareebene, um eine Erhöhung von Berechtigungen, fehlerhafte Aufrufe von Tools oder endlose Ausführungsläufe zu verhindern:
- Vorwärtsvalidierung (vor der Ausführung): Bevor ein Toolaufruf ein nachgelagertes Unternehmenssystem erreicht, überprüft die Laufzeitumgebung seine Argumente anhand strenger Pydantic-Schemata – um sicherzustellen, dass erforderliche Felder vorhanden sind, numerische oder Enum-Werte innerhalb der zulässigen Bereiche liegen und das Autorisierungstoken des Aufrufers tatsächlich diese Aktion erlaubt.
Fehler: Die Datenbanktabelle ‘users_v2’ wurde nicht gefunden. Verfügbare Tabellen: ['users', 'orders'] – wodurch dem Agenten handlungsrelevante Informationen zur Verfügung gestellt werden, die er nutzen kann, um seinen nächsten Schritt anzupassen.Sandboxing, Schrittbudgets und automatische Circuit Breaker
- Isoliertes Sandboxing: Jeder dynamisch generierte Code – beispielsweise Python, der von einem Datenanalyse-Agenten erzeugt wird – sollte in verwendbaren, isolierten Sandboxes wie Docker-Containern oder gVisor-Mikro-VMs ausgeführt werden, wobei der Ausgangsnetzzugriff streng eingeschränkt ist.
- Schritt- und Kostenbudgets: Jede Agentenaufgabe sollte durch eine feste Obergrenze für die Anzahl der Tool-Aufrufe (zum Beispiel maximal 10) sowie eine maximale Tokenausgabe begrenzt werden. Überschreitet man eine dieser Grenzen, muss das System die Ausführung stoppen und die Aufgabe an einen menschlichen Operator weiterleiten.
- Tool-Circuit-Breaker: Wenn eine Backend-API oder Datenbank bei aufeinanderfolgenden Wiederholungsversuchen weiterhin fehlschlägt, sollte das System einen Circuit-Breaker aktivieren und dieses Tool im Tool-Katalog des Agents als
UNAVAILABLEkennzeichnen, damit die Planungsschicht auf alternative Lösungswege ausweichen kann, anstatt immer wieder versuchen, von einer fehlerhaften Abhängigkeit auszugehen.
Abschnitt 5: Entwurf für die Produktionsimplementierung
Das untenstehende Beispiel ist eine vollständige, ausführbare Python-Anwendung, die eine für die Produktion geeignete Supervisor Multi-Agent Architecture veranschaulicht. Sie kombiniert Werkzeugvalidierung auf Basis von Pydantic, Budgetierung der Schritte, deterministische Fehlerbehandlung sowie ein Wrapper-Werkzeug für die Abfragen bei Amazon Kendra.
import os
import json
import time
from typing import List, Dict, Any, Optional
from pydantic import BaseModel, Field, ValidationError
# =====================================================================
# 1. TOOL SCHEMAS & ENTERPRISE INTEGRATION CONTRACTS
# =====================================================================
class KendraRetrieveInput(BaseModel):
"""Input contract for the Amazon Kendra retrieval tool."""
query_text: str = Field(..., description="The natural language query string to search across corporate documentation.")
department_filter: Optional[str] = Field(None, description="Optional department metadata filter (e.g., 'Engineering', 'HR').")
user_id: str = Field(..., description="Authenticated user ID used for native Kendra ACL security trimming.")
class DatabaseQueryInput(BaseModel):
"""Input contract for enterprise relational database lookups."""
query_type: str = Field(..., description="Must be 'SELECT'. Data mutation operations are strictly prohibited.")
table_name: str = Field(..., description="Target database table name.")
limit: int = Field(default=5, ge=1, le=20, description="Number of records to return.")
# =====================================================================
# 2. MOCK ENTERPRISE SERVICES & KENDRA TOOL ENGINE
# =====================================================================
class MockAmazonKendraClient:
"""Simulates Amazon Kendra's high-density Retrieve API with ACL security trimming."""
def __init__(self):
self._mock_index = [
{
"doc_id": "KENDRA-DOC-001",
"content": "Production deployment requires dual sign-off from Engineering and Security leads.",
"department": "Engineering",
"acl_users": ["user_eng_101", "admin_007"]
},
{
"doc_id": "KENDRA-DOC-002",
"content": "Standard employee travel stipend is capped at $150/day for domestic lodging.",
"department": "HR",
"acl_users": ["user_hr_201", "user_eng_101", "admin_007"]
}
]
def retrieve(self, query_text: str, user_id: str, department_filter: Optional[str] = None) -> List[Dict[str, Any]]:
results = []
for doc in self._mock_index:
# Enforce Document-Level ACL Security Trimming
if user_id not in doc["acl_users"]:
continue
# Apply Optional Metadata Department Filtering
if department_filter and doc["department"].lower() != department_filter.lower():
continue
results.append({
"DocumentId": doc["doc_id"],
"ContentSnippet": doc["content"],
"Department": doc["department"]
})
return results
class MockEnterpriseDatabase:
"""Simulates a secure internal enterprise database."""
def __init__(self):
self._tables = {
"deployments": [
{"id": 1, "service": "auth-service", "status": "COMPLETED", "env": "prod"},
{"id": 2, "service": "payment-api", "status": "PENDING_APPROVAL", "env": "prod"}
]
}
def execute_select(self, query_type: str, table_name: str, limit: int) -> List[Dict[str, Any]]:
if query_type.upper() != "SELECT":
raise ValueError(f"Security Alert: Unauthorized operation '{query_type}'. Only 'SELECT' is permitted.")
if table_name not in self._tables:
raise KeyError(f"Database Error: Table '{table_name}' does not exist. Available tables: {list(self._tables.keys())}")
return self._tables[table_name][:limit]
# =====================================================================
# 3. PRODUCTION AGENT HARNESS & RUNTIME ENGINE
# =====================================================================
class ProductionAgentRuntime:
"""
Deterministic software harness surrounding probabilistic reasoning models.
Enforces budgets, schema validation, sandboxing, and error recovery loops.
"""
def __init__(self, user_id: str, max_step_budget: int = 4):
self.user_id = user_id
self.max_step_budget = max_step_budget
self.kendra_service = MockAmazonKendraClient()
self.db_service = MockEnterpriseDatabase()
def execute_task(self, task_goal: str) -> Dict[str, Any]:
print(f"=== [Harness Started] Initiating Task: '{task_goal}' for User: '{self.user_id}' ===")
step_count = 0
scratchpad_history: List[str] = []
# Simulated dynamic model trajectory outputs (demonstrating multi-step execution & self-correction)
simulated_llm_turns = [
# Turn 1: Attempt invalid database deletion (Caught by Feedforward Schema/Guardrail)
{
"thought": "I will clean up old deployment logs before checking security compliance.",
"action": "execute_db_query",
"args": {"query_type": "DELETE", "table_name": "deployments", "limit": 5}
},
# Turn 2: Corrected database lookup
{
"thought": "I will check active deployment statuses in the enterprise database.",
"action": "execute_db_query",
"args": {"query_type": "SELECT", "table_name": "deployments", "limit": 2}
},
# Turn 3: Ground task using Amazon Kendra Retrieve API
{
"thought": "Now I need to query enterprise policies regarding production deployment sign-off.",
"action": "kendra_retrieve",
"args": {"query_text": "production deployment sign-off rules", "department_filter": "Engineering"}
}
]
while step_count < self.max_step_budget:
step_count += 1
print(f"\n--- [Step {step_count}/{self.max_step_budget}] ---")
# Fetch current simulated model decision turn
turn_data = simulated_llm_turns[min(step_count - 1, len(simulated_llm_turns) - 1)]
print(f"Agent Thought: {turn_data['thought']}")
action = turn_data.get("action")
args = turn_data.get("args", {})
# --- TOOL EXECUTION BRANCH: DATABASE ---
if action == "execute_db_query":
try:
# 1. Pre-execution Feedforward Schema Validation
validated_args = DatabaseQueryInput(**args)
# 2. Tool Execution
db_results = self.db_service.execute_select(
query_type=validated_args.query_type,
table_name=validated_args.table_name,
limit=validated_args.limit
)
observation = f"Database Query Success: {json.dumps(db_results)}"
print(f"[Observation]: {observation}")
scratchpad_history.append(observation)
except ValidationError as ve:
error_msg = f"Schema Validation Blocked Action: {ve.errors()[0]['msg']}"
print(f"[Harness Feedforward Intercept]: {error_msg}")
scratchpad_history.append(error_msg)
except (ValueError, KeyError) as exec_err:
error_msg = f"Tool Execution Failure: {str(exec_err)}"
print(f"[Harness Feedback Sensor Catch]: {error_msg}")
scratchpad_history.append(error_msg)
# --- TOOL EXECUTION BRANCH: AMAZON KENDRA RETRIEVE ---
elif action == "kendra_retrieve":
try:
# Inject authenticated context
args["user_id"] = self.user_id
# 1. Pre-execution Schema Validation
validated_kendra_args = KendraRetrieveInput(**args)
# 2. Execute Kendra Retrieve Call
kendra_passages = self.kendra_service.retrieve(
query_text=validated_kendra_args.query_text,
user_id=validated_kendra_args.user_id,
department_filter=validated_kendra_args.department_filter
)
observation = f"Amazon Kendra Retrieved {len(kendra_passages)} Grounding Snippets: {json.dumps(kendra_passages)}"
print(f"[Observation]: {observation}")
scratchpad_history.append(observation)
# Successful multi-step completion condition reached
return {
"status": "SUCCESS",
"completed_in_steps": step_count,
"trajectory": scratchpad_history
}
except ValidationError as ve:
error_msg = f"Kendra Schema Error: {ve.errors()[0]['msg']}"
print(f"[Harness Intercept]: {error_msg}")
scratchpad_history.append(error_msg)
return {"status": "FAILED", "reason": "Step budget exhausted without completing task goals."}
# =====================================================================
# 4. EXECUTION DRIVER
# =====================================================================
if __name__ == "__main__":
# Instantiate runtime for an authorized engineering user
agent_runtime = ProductionAgentRuntime(user_id="user_eng_101", max_step_budget=4)
# Run Agentic Workflow
final_execution_summary = agent_runtime.execute_task(
task_goal="Verify pending production deployments and confirm authorization policies."
)
print("\n================ FINAL SYSTEM SUMMARY ================")
print(json.dumps(final_execution_summary, indent=2))
Abschnitt 6: Produktionsbetrieb, Telemetrie und Governance
Beobachtbarkeit: Verfolgung von Abläufen mit OpenTelemetry
Der Betrieb agenter Systeme in der Produktion erfordert ein Ausmaß an Verfolgung von Abläufen, das herkömmliche APM-Dashboards nicht bieten können. Da Agenten variable, nicht-deterministische Ausführungspfade folgen, muss Ihr Telemetriesystem den gesamten Ablaufbaum rekonstruieren, den ein Agent durchlaufen hat – und nicht nur ein einzelnes Anfrage-Antwort-Paar:
- Span-Granularität: Jeder Agentenschritt sollte eine Reihe von verschachtelten OpenTelemetry-Spans erzeugen, wobei einzelne Spans dafür zuständig sind, den Systemprompt zu erstellen, die Reaktionszeit des Modells zu messen, zu überprüfen, ob die Tool-Argumente dem erwarteten Schema entsprechen, den tatsächlichen Toolaufruf zu zeitlich erfassen sowie jegliche während dieses Schritts stattfindende Speicherkompaktion durchzuführen.
- Aufzeichnung des Trajektorienzustands: Die Spans müssen die Anzahl der Eingabetoken, die Anzahl der Ausgabetoken, die für Tool-Parameter verwendeten Schemata sowie die Rohlänge der zurückgegebenen Beobachtungen protokollieren. Genau diese Detailstufe ermöglicht eine genaue Kostenzuordnung und zeigt genau an, welcher Schritt in der Trajektorie zu einem Engpass wurde.
Operative Richtlinien und Bewertung (Die agente Triade)
Das Erhalten der Gesundheit eines Agenten in der Produktion bedeutet, kontinuierlich automatisierte Bewertungen in drei Schlüsseldimensionen durchzuführen:
- Zielerreichungsrate: der Anteil an Agentenaufrufen, die einen erfolgreichen Endzustand erreichen, ohne ihr Schrittbudget aufzubrauchen oder eine unverarbeitete Tool-Exception auszulösen.
- Kontextbezuglichkeit, oder Halluzinationsscore: dabei wird überprüft, ob die endgültige zusammengefasste Antwort des Agenten tatsächlich durch Fakten gestützt wird, die aus seinen Abrufwerkzeugen stammen (zum Beispiel Auszüge von Amazon Kendra), anstatt aus dem parametrischen Speicher des Modells generiert zu werden.
Fazit mit praktischen Erkenntnissen
Beim Aufbau von agentbasierten KI-Systemen im Unternehmensumfeld muss das zugrundeliegende Grundmodell als probabilistisches Reasoning-Element betrachtet werden, das innerhalb eines deterministischen, streng regulierten Software-Frameworks agiert. Die Organisationen, denen es gelingt, ihre Agenten vom Prototyp in die Produktion zu bringen, sind jene, die klare architektonische Trennlinien zwischen Wahrnehmung, Planung, Speicherung und Tool-Ausführung ziehen, anstatt dem Modell zu erlauben, alle Aspekte gleichzeitig frei zu steuern.
Praktischer Leitfaden für Architekturteams
- Trennung von Logik und Ausführung: Jeder durch einen LLM ausgelöste Toolaufruf sollte über ein deterministisches Framework laufen, das vor der Ausführung die Argumente anhand eines Pydantic-Schemas überprüft und anschließend Fehler sauber auffängt.
- Nutzen Sie Amazon Kendra für die Grundlegung: Rufen Sie Kendras
Retrieve-API auf, um dem Agenten dichten, textabschnittsweisen Kontext zur Verfügung zu stellen, und verlassen Sie sich gleichzeitig auf die automatische Sicherheitsüberwachung durch die Dokument-ACLs auf Indexebene. - Begrenzen Sie die Speichernutzung explizit: Wenden Sie eine schrittweise Komprimierung des Kontexts an und isolieren Sie den Kontext von Unteraufgaben, damit bei lang andauernden Sitzungen kein Kontextverfall, Anweisungsverschiebungen oder unkontrollierter Tokenverbrauch entstehen.
Zusätzliche Literatur
- Warum die Kosten für agierende KI in die Höhe schießen: Ein kostenorientiertes Architekturmodell – Erklärt, warum die Kosten für LLM-Agents nach abgeschlossenen Aufgaben und nicht nach einzelnen Aufrufen gemessen werden müssen, und skizziert architektonische Ansätze wie Modellroutierung, Kontextbudgets und Caching zur Kostenkontrolle.
- Neun architektonische Säulen für Produktionssysteme mit agiler KI — Lernen Sie ein Architekturmodell mit neun Säulen – das Zero-Trust-Netzwerke, Datenschichten sowie evidenzbasierte Ansätze umfasst – zur Erstellung prüfbarer, unternehmensreifer Systeme mit agiler KI.
- Entwurf von Arbeitsumgebungen für agile KI, die der tatsächlichen Arbeitsweise von Teams entsprechen — Erklärt zehn Kernprinzipien für den Aufbau solcher Arbeitsumgebungen, die Kontext, Wissen, Autonomie, Tool-Zugriff sowie Workflow-Automatisierung zu einem integrierten System verbinden.
- Auswahl und Anpassung von Embedding-Modellen für Produktions-RAG-Systeme — Erfahren Sie, wie Embedding-Modelle Text in suchbare Vektoren umwandeln, warum ein Domänenwortschatz die semantische Suche stört und wie man Modelle für Produktions-RAG auswählt, komprimiert und feinabstimmt.