Agentic Engineering-Intelligenz mit Amazon Nova Multimodal Embeddings und Bedrock AgentCore

Wenn ein qualifiziertes Luftfahrtbauteil veraltet oder mit langen Lieferzeiten konfrontiert ist, verbringt ein Ingenieur Tage damit, Spezifikationen über Herstellerdatenblätter, Interface Control Documents (ICDs) und Qualifikationsunterlagen hinweg abzugleichen, bevor er eine Substitutionsbegründung zur Prüfung dokumentiert. Eine fehlerhafte Substitution bei einem flugkritischen Bauteil kann zum Missionsversagen führen, dennoch ist die Nachweis hinter jeder Entscheidung oft über E-Mails und nicht dokumentiertes institutionsinternes Wissen verstreut, sodass es kein formales, wiederholbares Paket gibt, das ein Prüfer kontrollieren könnte.

Ein früherer Beitrag, Manufacturing intelligence with Amazon Nova Multimodal Embeddings, zeigte, wie das Modell Antworten findet, die in Ingenieurzeichnungen, thermischen Diagrammen und Datenblatt-Charts eingeschlossen sind und die textbasierte Pipelines übersehen. Dieser Beitrag knüpft an diese Retrieval-Arbeit an und integriert diese Fähigkeiten in ein Multi-Agent-System, das Substitutionsnachweise zusammenstellt, vom Abruf bis zu einem entworfenen Assessment.

In diesem Beitrag zeigen wir, wie man einen Multi-Agent-Ingenieurassistenten erstellt, der das manuelle Gegenprüfen hinter der Bewertung von Bauteilsubstitutionen reduziert, und zwar mit Amazon Bedrock AgentCore, Amazon Nova Multimodal Embeddings und dem quelloffenen Strands Agents SDK. Ein Planer verteilt die Arbeit auf drei Spezialisten-Agents, die eine multimodale Wissensbasis durchsuchen, Kandidaten gegen deterministische Toleranzregeln bewerten, Bauteilfotos vergleichen und Lifecycle-Aussagen in Live-Webdaten verankern. Der Ingenieur bleibt durchgehend der Entscheider, denn das System stellt Nachweise zusammen und entwirft Dokumente, ohne jemals selbst eine Substitution zu genehmigen.

Der Assistent basiert auf einer Designregel, die lautet: Der Ingenieur trifft jede Entscheidung, und das System stellt die Nachweise dafür zusammen. Diese Regel bestimmt, wo wir große Sprachmodelle (LLMs) einsetzen und wo stattdessen deterministischer Code verwendet wird.

Das folgende Diagramm zeigt die Architektur.

Abbildung 1: Architektur des Multi-Agent-Ingenieurassistenten auf Amazon Bedrock AgentCore

Amazon Bedrock AgentCore ist eine Plattform zum Erstellen, Verbinden und Optimieren von Agents im großen Maßstab, mit jedem Framework oder Modell. In dieser Lösung fließen Chat-Anfragen aus der Anwendung des Ingenieurs in einen Multi-Agent-Graphen, der auf der AgentCore-Laufzeit gehostet wird: Ein Planer (Claude Haiku 5.5) erstellt einen Routing-Plan, Spezialisten (Claude Sonnet 5.5) führen ihre Tools aus, und ein Supervisor (Claude Opus 5.5) fasst ihre Ergebnisse zusammen, wenn mehr als ein Spezialist gelaufen ist. Die Spezialisten rufen Daten aus einer verwalteten Wissensbasis ab, die wir mit Amazon Bedrock Managed Knowledge Bases unter Verwendung von Amazon Nova Multimodal Embeddings erstellt haben, geroutet über ein AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, zusammen mit dem Web Search Connector für Live-Webdaten.

Für Bild-als-Abfrage (das Hochladen eines Charts zur Identifizierung eines Bauteils) ruft der Agent einen nativen Amazon S3 Vectors Index direkt auf, da die Retrieval-API der verwalteten Wissensbasis keine Bildeingaben akzeptiert. Amazon S3 Vectors ist eine Funktion von Amazon Simple Storage Service (Amazon S3). Eine separate feste Kette (Knowledge, dann Evaluation, dann Supervisor) erzeugt das formale Dokument der Integration Impact Assessment (IIA).

Amazon Nova Multimodal Embeddings übernimmt zwei unterschiedliche Rollen:

Die folgenden Abschnitte beschreiben jeden Teil des Systems in der Reihenfolge, in der eine Abfrage ihn nutzt. Wir beginnen mit dem Bauteil-Korpus und den Spezialisten-Agents, behandeln dann Routing, deterministische Bewertung, die beiden Arten, wie der Assistent Nova Multimodal Embeddings verwendet, die feste Kette, die formale Dokumente erzeugt, und die Bereitstellung auf der AgentCore-Laufzeit.

Das vollständige Codebeispiel besteht aus fünf Jupyter-Notebooks im GitHub-Repository, und jedes Notebook läuft eigenständig. Die Notebooks importieren aus mei_core, einer in sich geschlossenen Kopie der Agent- und Tool-Module im selben Ordner, und sie enthalten eigene Bauteildaten, Chart-Ausschnitte und einen Satz von Bewertungsabfragen. Sie können jedes Snippet in diesem Beitrag aus den Notebooks ausführen, ohne weiteren Anwendungscode.

Der Beispieldatensatz besteht aus sieben Reaktionsrädern eines fiktiven Herstellers (AnyCompany) mit einem Impulsspeicher von 0,003 bis 5,0 Nms. Jedes Bauteil ist ein Ordner, der strukturierte Daten mit den Quelldokumenten kombiniert, die ein Ingenieur tatsächlich liest, und genau diese Mischung macht das Korpus multimodal. Die Datei specs.json enthält die maschinenlesbaren Felder, die die deterministische Bewertung steuern, während das ICD, das Produktfoto und die gerenderte Datenblattseite die visuellen und narrativen Details tragen, die strukturierte Felder nicht abbilden.

data/synthetic-parts-data/rw_rl_0060/ ├── specs.json # strukturierte Spezifikationen und Lifecycle-Felder ├── description.txt # flacher Text für Text-Retrieval ├── AC-ICD-00068-RW3-0.06-Interface-Control-Document-v2.2.pdf ├── datasheet_page.png # gerenderte Datenblattseite ├── datasheet_chart.png # ausgeschnittener Chartbereich (Index für Bild-als-Abfrage) └── photo.png # Produktbild (visuelle Ähnlichkeit und Chart-Abgleich) Die Datei specs.json erfasst sowohl die technischen Spezifikationen als auch ein Lifecycle-Profil, was dem Assistenten erlaubt, neben der Spezifikationspassung auch Veraltung und Lieferzeitrisiken zu kennzeichnen.

{ "name": "AnyCompany RW3 0.06", "category": "reaction_wheel", "vendor": "AnyCompany", "model": "RW3-0.06", "momentum_storage_nms": 0.06, "max_torque_mnm": 20, "mass_g": 235, "voltage_v": "28", "voltage_range_v": "7.5 to 36", "operating_temp_c": "-30 to +70", "interface": "RS-422 or Redundant RS-485", "qual_standard": "AnyCompany internal (flight heritage qualified)", "lifecycle": { "lifecycle_status": "Active", "production_status": "Full production", "estimated_years_to_eol": "10+", "last_time_buy": "Not announced", "typical_lead_time_weeks": 10, "lead_time_risk": "Low", "bathtub_region": "Useful life (highly mature)", "recommended_screening": "Standard flight acceptance" } } Das Feld vendor wird für jedes Bauteil explizit angegeben. Da Katalog-Ordner-IDs und Dateinamen über Datensätze hinweg wiederverwendet werden, behandelt jeder Spezialisten-Prompt den strukturierten Herstellerwert, den get_part_specs zurückgibt, als verbindlich, und es ist ihm untersagt, einen Hersteller aus einer ID, einem Dateinamen, einem Foto oder einem Websuchergebnis zu erraten. Den Hersteller aus strukturierten Daten zu übernehmen verhindert, dass der Assistent einem Bauteil den falschen Lieferanten zuordnet, nur weil das Modell meint, die Hardware zu erkennen.

Jeder Bauteilordner enthält außerdem zwei Assets, die eine rein textbasierte Indizierung nicht nutzen kann. Das Produktfoto speist die Bewertung visueller Ähnlichkeit, und die gerenderte Datenblattseite enthält Drehmoment- und Drehmomentkurven-Diagramme, die Leistungsfragen beantworten, die keine OCR-Textschicht erfasst. Amazon Nova Multimodal Embeddings bettet beide in denselben Vektorraum wie den Text ein, sodass eine Abfrage auf einen Spezifikationswert, einen Absatz oder ein Diagramm passen kann.

Das folgende Beispiel zeigt vier Datenblattseiten aus dem Korpus, die drei Größenordnungen des Impulsspeichers abdecken.

Abbildung 2: Vier Datenblattseiten aus dem Bauteil-Korpus, die drei Größenordnungen des Impulsspeichers abdecken

Die Vorlage wiederholt sich über die Produktfamilie, aber das Produktfoto und das Paar von Leistungsdiagrammen ändern sich mit jedem Bauteil. Diese Bereiche zeigen die Gehäusegeometrie, das Bohrbild, die Drehmomenthüllkurve und den Stromverbrauch, die die Spezifikationsfelder nicht direkt angeben, deshalb betten wir sie neben dem Text ein.

Jeder Spezialist ist ein Strands-Agent mit einem eng gefassten Prompt und nur den Tools, die er braucht. Die Begrenzung der Tools pro Spezialist hält das Verhalten vorhersehbar, denn der Knowledge-Spezialist hat keinen Zugriff auf die Katalog-Discovery-Tools und der Catalog-Spezialist hat keinen Zugriff auf die Bewertungs-Tools. Der folgende Code erstellt den Evaluation-Spezialisten.

from strands import Agent def create_evaluation_specialist() -> Agent: """Evaluation Specialist: deterministic spec-by-spec comparison and scoring.""" return Agent( name="evaluation_specialist", system_prompt="""You are the Evaluation Specialist. Your job is to run deterministic, spec-driven comparisons between parts.... RULES: - Your comparisons are deterministic (code, not opinion) - NEVER recommend or approve --- present evidence and flags; the engineer decides - Always include the disclaimer that this is evidence only""", tools=[score_substitution_fit, compare_parts, visual_similarity_score, check_qualification_status, generate_substitution_memo], model="us.anthropic.claude-sonnet-5-5", ) Das folgende Diagramm zeigt, wie der Planer eine Abfrage an die Spezialisten weiterleitet und wann der Supervisor deren Ergebnisse zusammenführt.

Die Liste danach beschreibt, was jeder Spezialist tut.

Abbildung 3: Wie der Planer Abfragen an die Spezialisten weiterleitet und wann der Supervisor deren Ergebnisse zusammenführt

Routing ist eine Klassifizierungsaufgabe ohne Tool-Aufrufe und benötigt daher kein großes Reasoning-Modell. Ein Haiku-basierter Planer liefert in wenigen Sekunden einen nummerierten Routing-Plan. Der Opus-Supervisor läuft nur, wenn zwei oder mehr Spezialisten beigetragen haben, denn die Zusammenführung der bereits vollständigen Antwort eines einzelnen Spezialisten fügt etwa 8 Sekunden Latenz ohne Qualitätszuwachs hinzu.

# Schritt 1: Der Planner (schnelles Modell) plant das Routing (möglicherweise mehrstufig). plan_response = planner(planning_prompt) ordered_specialists = _parse_specialist_plan(str(plan_response)) # Schritt 2: Spezialisten nacheinander ausführen, Kontext weiterreichen accumulated_context = "" for spec_name in ordered_specialists: specialist = specialists[spec_name] specialist_response = specialist(spec_prompt) accumulated_context += f"\n[{spec_name.upper()}]: {specialist_response}\n" # Schritt 3: Nur synthetisieren, wenn 2+ Spezialisten liefen. if len(ordered_specialists) == 1: final_text = steps["response"] else: final_text = str(supervisor(synthesis_prompt)) Die Aufteilung der Arbeit auf drei Modellklassen passt Kosten und Latenz an jede Stufe an. Haiku klassifiziert die Anfrage, Sonnet führt die Tools aus, und Opus schreibt die kombinierte Antwort, also den Schritt, bei dem die Antwortqualität am meisten zählt.

Die Spec-Fit-Evaluierung läuft als gewöhnlicher Python-Code gegen ein handgeschriebenes Anforderungsschema. Das Schema definiert die kritischen Spezifikationen und Toleranzregeln für jede Komponentenkategorie, und score_substitution_fit vergleicht jede Spezifikation, zählt Bestehungen und Markierungen und macht Lifecycle-Risiken sichtbar. Da das Urteil für ein Engineering-Review-Paket reproduzierbar sein muss, ist an diesem Schritt kein LLM beteiligt.

{ "categories": { "reaction_wheel": { "critical_specs": [ {"field": "voltage_v", "label": "Bus voltage (V)", "rule": "match", "required_from_user": true}, {"field": "mass_g", "label": "Mass (g)", "rule": "candidate_lte_reference_within_pct", "tolerance_pct": 20, "required_from_user": false} ] } } } Das Tool liefert ein strukturiertes Urteil mit einem ausdrücklichen Disclaimer:

return { "spec_results": results, # per-spec pass/flag/review status "counts": counts, "out_of_tolerance": out_of_tolerance, "lifecycle": {...}, # obsolescence and lead-time flags "summary": summary, "disclaimer": "Evidence only. This tool does not recommend or approve " "a substitution; the engineer decides.", } Der Spezialist präsentiert diese Tabelle und erläutert die Markierungen, kann aber ein Urteil nicht ändern. Der Audit-Trail folgt derselben Arbeitsteilung. Nach jeder Evaluierung liest die Orchestrierungsschicht die Tool-Aufrufhistorie des Spezialisten und schreibt den Audit-Eintrag selbst, sodass die Protokollierung nicht davon abhängt, dass sich das Modell daran erinnert.

Die Bauform spielt eine Rolle, wenn ein Ersatz in eine vorhandene Halterung passen muss. Das Tool visual_similarity_score bettet beide Teilfotos mit Nova Multimodal Embeddings ein und berechnet die Kosinusähnlichkeit, danach bittet es Claude, die konkret beobachtbaren Unterschiede zu beschreiben.

def embed_image(image_bytes): """Embed one image with Nova MME (IMAGE_RETRIEVAL) -> 1024-d vector.""" b64 = base64.b64encode(image_bytes).decode('utf-8') fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg' body = { 'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': { 'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024, 'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt, 'source': {'bytes': b64}}, }, } resp = bedrock.invoke_model( modelId='amazon.nova-2-multimodal-embeddings-v1:0', body=json.dumps(body), accept='application/json', contentType='application/json', ) result = json.loads(resp['body'].read()) return np.array(result['embeddings']['embedding']) # cosine similarity of the two photo embeddings emb_a, emb_b = embed_image(photo_a_bytes), embed_image(photo_b_bytes) similarity = float(np.dot(emb_a, emb_b) / (np.linalg.norm(emb_a) * np.linalg.norm(emb_b))) Die Embedding-Ähnlichkeit ist deterministisch und reproduzierbar und liefert etwa 0,84 für zwei Räder derselben Produktfamilie und 0,40 für Räder unterschiedlicher Klassen. Claudes Vision-Analyse erklärt anschließend, was den Unterschied ausmacht, etwa dass ein Gehäuse etwa doppelt so groß im Durchmesser ist wie das andere und ein Sechslöcher-Befestigungsmuster aufweist, während das andere vier Löcher hat.

Text- und Dokumentanfragen laufen über die verwaltete Knowledge Base, die auf Amazon Nova Multimodal Embeddings basiert und über das AgentCore Gateway geroutet wird. Bild-als-Anfrage (das Hochladen eines Diagramms oder Fotos, um passende Inhalte zu finden) nutzt einen nativen Amazon-S3-Vectors-Index, der direkt vom Agenten aufgerufen wird, weil die Retrieval-API der verwalteten Knowledge Base keine Bildeingaben akzeptiert.

Das Tool retrieve_visual_content des Knowledge-Spezialisten bietet eine einzige Schnittstelle für beide Pfade. Ein Ingenieur kann eine Leistungskurve aus einem Anforderungsdokument in den Chat einfügen und fragen, welches Teil dazu passt, oder das Diagramm stattdessen in einer Textanfrage beschreiben.

# Image-as-query: embed the uploaded image with Nova MME, exactly as the # datasheet crops and photos were embedded at indexing time. def embed_query_image(image_bytes): b64 = base64.b64encode(image_bytes).decode('utf-8') fmt = 'png' if image_bytes[:8] == b'\x89PNG\r\n\x1a\n' else 'jpeg' body = {'taskType': 'SINGLE_EMBEDDING', 'singleEmbeddingParams': { 'embeddingPurpose': 'IMAGE_RETRIEVAL', 'embeddingDimension': 1024, 'image': {'detailLevel': 'STANDARD_IMAGE', 'format': fmt, 'source': {'bytes': b64}}}} r = bedrock.invoke_model(modelId=NOVA_MME_MODEL_ID, body=json.dumps(body), accept='application/json', contentType='application/json') return json.loads(r['body'].read())['embeddings']['embedding'] Beim Bildpfad wird das Upload mit Nova Multimodal Embeddings mit 1.024 Dimensionen und dem Zweck IMAGE_RETRIEVAL eingebettet und dann gegen den S3-Vectors-Index gematcht:

# Query the native S3 Vectors index and collapse to the best vector per part. emb = embed_query_image(image_bytes) s3v = boto3.client('s3vectors', region_name=REGION) fetch_k = max(top_k * 6, 12) # each part has several vectors; dedupe below resp = s3v.query_vectors( vectorBucketName=S3_VECTOR_BUCKET, indexName=S3_VECTOR_INDEX, queryVector={'float32': emb}, topK=fetch_k, returnDistance=True, returnMetadata=True, ) best = {} for v in resp.get('vectors', []): meta = v.get('metadata', {}) or {} pid = meta.get('part_id', '') if not pid: continue sim = 1.0 - v.get('distance', 1.0) # cosine distance -> similarity if pid not in best or sim > best[pid]['score']: best[pid] = {'part_id': pid, 'score': sim} ranked = sorted(best.values(), key=lambda r: r["score"], reverse=True)[:top_k] Da ein Teil mehrere Vektoren beisteuert (sein Foto, die gesamte Datenblattseite und jede ausgeschnittene Diagrammregion), werden die Ergebnisse auf den am besten bewerteten Vektor pro Teil dedupliziert, bevor sie das Modell erreichen.

Beim Aufbau der Retrieval-Pfade haben wir drei praktische Erkenntnisse gewonnen:

Der Chat nutzt dynamisches Routing, weil die richtigen Spezialisten für eine freie Frage nicht im Voraus bekannt sein können. Die Integration Impact Assessment funktioniert anders. Wenn ein Ingenieur eine Impact-Bewertung für ein Referenz- und Kandidatenpaar anfordert, ist die benötigte Abfolge bereits bekannt, daher setzt der Dienst dieselben Spezialisten-Factory-Funktionen in fester Reihenfolge mit einem speziell gebauten Synthese-Prompt zusammen.

# 1. Knowledge Specialist --- ICD/datasheet interface detail for both parts knowledge_text = str(knowledge(knowledge_prompt)) # 2. Evaluation Specialist --- structured field delta + qualification check evaluation_text = str(evaluation(evaluation_prompt)) # Deterministic structured delta for exact summary stats comparison = compare_parts(reference_id, candidate_id) # 3.

Supervisor --- synthesize into the six-section IIA document markdown = str(supervisor(synthesis_prompt)) Das resultierende Dokument deckt Schnittstellenänderungen, mechanische Integration, elektrische Integration, thermische Integration, den Qualifikations-Delta und die Auswirkungen auf die Lieferkette ab. Die narrativen Abschnitte benötigen eine LLM-Synthese, weil die Pinout- und Protokolldetails aus ICD-Fließtext extrahiert werden müssen. Die zusammenfassenden Statistiken (Übereinstimmungen, Unterschiede, Gesamtzahl der Felder) werden direkt aus der Ausgabe von compare_parts berechnet, sodass die Zahlen, die neben dem Narrativ gezeigt werden, exakt sind.

Katalogdaten veralten, daher prüft das Tool web_search_eol des Knowledge-Spezialisten aktuelle End-of-Life-Hinweise, Anbieterankündigungen und Lieferzeiten über ein AgentCore Gateway mit dem Web-Search-Connector. Das Gateway stellt den Connector als einen regulierten Model Context Protocol (MCP)-Endpunkt bereit. Da das Gateway auch das Retrieval der verwalteten Knowledge Base übernimmt, lassen sich Richtlinien und Observability für externe und interne Datenzugriffe an einer zentralen Stelle anbinden.

Für die Produktion paketieren Sie den Agenten als ARM64-Container, pushen ihn in die Amazon Elastic Container Registry (Amazon ECR), und die AgentCore-Runtime hostet ihn serverless mit Sitzungsisolation und Auto-Scaling. Notebook 03 im GitHub-Repository führt diese Bereitstellung als Referenzrezept vor und behandelt das Dockerfile, die Build- und Push-Befehle, die Berechtigungen der Execution Role und die Cedar-Richtlinie. Das Notebook zeigt diese Schritte, ohne sie auszuführen. Sein Dockerfile paketiert Anwendungscode, der über das Beispiel hinausgeht, passen Sie es also an Ihr eigenes Anwendungslayout an, bevor Sie bauen. Das folgende Diagramm zeigt den Bereitstellungspfad vom Agenten-Code bis zu einem gehosteten AgentCore-Runtime-Endpunkt.

Abbildung 4: Bereitstellungspfad vom Agenten-Code bis zu einem gehosteten AgentCore-Runtime-Endpunkt

export TAG=mei-$(date +%Y%m%d-%H%M%S) export ACCOUNT=<your-account-id> export ECR=${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com/mfg-engineering-intelligence # Builden des Containers für ARM64 (von AgentCore Runtime benötigt) docker buildx build --platform linux/arm64 -f agentcore/Dockerfile \ -t mfg-engineering-intelligence:${TAG} --load. # Pushen des unveränderlichen Tags zu Amazon ECR aws ecr get-login-password --region us-east-1 \ | docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.us-east-1.amazonaws.com docker tag mfg-engineering-intelligence:${TAG} ${ECR}:${TAG} docker push ${ECR}:${TAG} Versehen Sie jedes Image mit einem unveränderlichen Tag. Eine Runtime, die bereits den Digest hinter einem sich bewegenden:latest-Tag aufgelöst hat, stellt nach dem Push einer neuen Version weiterhin das alte Image bereit. Änderungen an Prompt, Router und Tools erfordern jeweils ein neues Image und eine neue Runtime-Version, um wirksam zu werden.

Die Runtime-Rolle benötigt bedrock:InvokeModel, bedrock:Retrieve, bedrock-agentcore:InvokeGateway und s3vectors:QueryVectors für den Bild-als-Query-Pfad. Die in Notebook 03 gezeigte Cedar-Policy kodifiziert die Human-in-the-Loop-Regeln und verlangt eine vorherige Freigabe vor Memos sowie einen Audit-Log-Eintrag bei jeder Substitutionsentscheidung. Die Anwendung setzt diese Regeln heute in ihrer eigenen Logik durch, und die Anbindung der Policy an eine Cedar-Autorisierungs-Engine ist der nächste Schritt.

Amazon Nova Multimodal Embeddings ist jetzt in AWS GovCloud (US) verfügbar, was für Luftfahrt- und Verteidigungsprogramme relevant ist, die Anforderungen an Datenresidenz, ITAR und FedRAMP unterliegen, die regeln, wo eine Workload betrieben werden darf. Die multimodalen Retrieval-Funktionen und die visuelle Ähnlichkeitssuche, auf denen dieser Beitrag aufbaut, sind innerhalb einer AWS-GovCloud-(US)-Umgebung erreichbar. Die Verfügbarkeit von Amazon Nova Multimodal Embeddings und Amazon Bedrock AgentCore unterscheidet sich je nach AWS-Region, prüfen Sie daher AWS Services by Region, bevor Sie eine Bereitstellung planen.

Wir messen die Qualität auf zwei Arten, und zwar durch kontinuierliches Online-Scoring über AgentCore Evaluations, eine Funktion von Amazon Bedrock AgentCore, sowie durch Offline-Validierung anhand kuratierter Query-Sets.

Amazon Bedrock AgentCore Evaluations, seit März 2026 allgemein verfügbar, bewertet Agent-Traces mit LLM-as-a-judge-Techniken. Der Dienst liest die OpenTelemetry-Traces, die Strands-Agents bereits emittieren, sodass ein instrumentierter Agent für die Bewertung keine Änderungen an der Anwendung benötigt. Der Dienst bietet zwei Modi. Die Online-Evaluation zieht kontinuierlich Stichproben aus laufenden Produktions-Sessions, und die On-Demand-Evaluation führt programmatische Tests aus, die sich in eine Pipeline für Continuous Integration und Continuous Delivery (CI/CD) einfügen.

Wir nutzen die Online-Evaluation, deren Ergebnisse für Dashboards und Alarme nach Amazon CloudWatch veröffentlicht werden. Notebook 05 im GitHub-Repository erzeugt eine Online-Evaluations-Konfiguration und sendet Test-Queries an die bereitgestellte Runtime, um Sessions für das Scoring zu erzeugen.

config = eval_client.create_online_config( config_name=CONFIG_NAME, agent_id=RUNTIME_ID, sampling_rate=SAMPLING_RATE, evaluator_list=[ "Builtin.GoalSuccessRate", "Builtin.Correctness", "Builtin.Helpfulness", "Builtin.Faithfulness", "Builtin.ResponseRelevance", "Builtin.ToolSelectionAccuracy", "Builtin.ToolParameterAccuracy", ], auto_create_execution_role=True, enable_on_create=True, ) Der Dienst liefert dreizehn eingebaute Evaluatoren mit, daneben wird die Unterstützung eigener Evaluatoren unterstützt, die über einen Prompt definiert oder als AWS-Lambda-Funktion gehostet werden. Wir aktivieren sieben, die alle drei Scoring-Ebenen abdecken.

Das kurierte Query-Set umfasst 36 Queries in sechs Kategorien: Katalogsuche (8), Knowledge- und ICD-Retrieval (8), Multi-Spezialisten-Ketten (6), deterministische Auswertung (5), Text-zu-Bild-Retrieval (5) sowie Sicherheitsverweigerungen im Human-in-the-Loop (4), die prüfen, dass der Agent eine Empfehlung oder Freigabe verweigert. Jede Query enthält die erwarteten Katalog-Teile-IDs, mit Ausnahme der Sicherheits-Queries, bei denen das erwartete Ergebnis eine Verweigerung ist.

export AGENTCORE_RUNTIME_ARN=arn:aws:bedrock-agentcore:us-east-1:ACCOUNT:runtime/YOUR_RUNTIME jupyter lab 05_evaluation.ipynb Ergebnisse AgentCore zieht fortlaufend Stichproben aus laufenden Sessions, sodass der Score jedes Evaluators ein sich bewegendes Aggregat ist, das sich mit wachsendem Traffic und Änderungen am Agent verschiebt. Die folgenden Zahlen sind eine Momentaufnahme aus dem Lauf mit dem synthetischen Datensatz. Nutzen Sie sie als Baseline für das Setzen von CloudWatch-Alarm-Schwellenwerten und erwarten Sie, dass die Zahlen Ihrer eigenen Läufe abweichen.

Alle Trace-Ebene-Qualitätsmetriken erzielten Werte von mindestens 0,95, und die Extraktion der Tool-Parameter lag mit 0,980 nahe an der Perfektion. Die größte Verbesserung zwischen den Evaluationsläufen betraf die Tool Selection Accuracy, die von 0,809 auf 0,861 stieg. Drei Änderungen führten zu dem Zugewinn: die Konsolidierung auf eine einzige verwaltete Knowledge Base, die Behebung einer fehlenden Berechtigung auf dem Bild-als-Query-Pfad, die ein stilles Zurückfallen auf die Textsuche verursacht hatte, und die Straffung des Routings des Planers, um unnötige Ketten von Spezialisten zu vermeiden.

Die Goal Success Rate fällt mit 0,892 niedriger aus, und zwar aufgrund der Art, wie das Query-Set aufgebaut ist. Das Query-Set enthält Prompts aus der Sicherheitskategorie, die den Agent auffordern, eine Substitution zu empfehlen oder freizugeben. Der Agent verweigert dies korrekt, aber der Evaluator bewertet eine korrekte Verweigerung als nicht erreichtes Ziel. Wir erwarten dieses Ergebnis, denn in einem Human-in-the-Loop-System darf der Agent eine Substitution nicht eigenständig freigeben.

Der Code ist ein wiederverwendbares Muster, das auch für andere Teile-Kategorien über Reaktionsräder hinaus funktioniert. Ein Wechsel der Domäne erfordert drei Änderungen: die Teile-Daten ersetzen (eine specs.json, Beschreibung, ICD, Datenblattseite und Foto pro Teil), das Requirements-Schema anpassen, um die kritischen Spezifikationen und Toleranzregeln Ihrer Kategorie zu definieren, und die Knowledge Base auf Ihr S3-Korpus verweisen. Die Agents, Tools und die Scoring-Engine bleiben unverändert übertragbar. Da die deterministischen Tools in mei_core einfache Python-Funktionen sind, kann eine PLM- oder ERP-Integration score_substitution_fit direkt aufrufen, ohne dass ein Agent im Spiel ist.

Um laufende Kosten zu vermeiden, löschen Sie die erstellten Ressourcen:

In diesem Beitrag haben wir gezeigt, wie man einen Multi-Agenten-Assistenten für das Engineering aufbaut, der manuelle Recherchen zur Teile-Substitution durch automatisierte Beweiszusammenstellung ersetzt. Die Architektur kombiniert Amazon Nova Multimodal Embeddings, das die visuelle Ähnlichkeitsbewertung und das Chart-Retrieval übernimmt, die reine Textsysteme verfehlen, mit Amazon Bedrock AgentCore, das das Produktions-Fundament aus Runtime-Hosting, über das Gateway geregeltem Retrieval und Websuche sowie Qualitäts-Evaluationen bereitstellt. Drei Designentscheidungen sind am wichtigsten.

Deterministischer Code erzeugt jedes Bestehens- bzw. Fehlschlag-Urteil, jede Aufgabe läuft auf der kleinsten der drei Modell-Stufen, die sie gut bewältigt, und nur die Ingenieurin oder der Ingenieur kann eine Substitution freigeben.

Zum Start klonen Sie das GitHub-Repository, führen Sie die Notebooks mit Ihrem eigenen AWS-Account aus und tauschen Sie Ihren Teile-Katalog und Ihr Requirements-Schema ein. Für eine vertiefte Beschäftigung mit den Retrieval-Grundlagen lesen Sie Manufacturing intelligence with Amazon Nova Multimodal Embeddings und A practical guide to Amazon Nova Multimodal Embeddings. Für Produktionsmuster für Agents sieh die Dokumentation zu Amazon Bedrock AgentCore und das Strands Agents SDK.

Aishwarya ist Solutions Architect bei Amazon Web Services (AWS) und betreut kommerzielle Kunden aus Luftfahrt und Satelliten, von Raumfahrt-Start-ups bis zu Großkonzernen, beim Architekturieren und Bereitstellen unternehmenskritischer Cloud-Lösungen. Sie ist spezialisiert auf Retrieval-augmented-Generation-Pipelines und multimodale Agentensysteme für Fertigungs- und Engineering-Workflows und hilft Kunden in regulierten Branchen, neue KI-Fähigkeiten in praktische, produktionsreife Lösungen zu überführen.

Adewale ist Science Tech Lead bei AWS, wo er die angewandte Forschung und Evaluation für das Amazon-Bedrock- und-1P-Models-GTM-Team leitet. Seine Forschung zu Foundation Models, agentischem Retrieval und neurosymbolischer KI wurde bei COLM, EMNLP und TACL sowie auf Workshops bei NeurIPS, ICLR, ACL, KDD und AAAI veröffentlicht. Darüber hinaus hilft er globalen Kunden, generative KI-Lösungen im großen Maßstab zu entwerfen und bereitzustellen. Er hat zwei Abschlüsse in Physik und einen Doktortitel im Ingenieurwesen.