Hoe Formule 1® generatieve AI gebruikt om de oplossing van problemen op de racedag te versnellen

Like
vond

Datum:

Leestijd: Min

Formule 1® (F1) races zijn zaken met hoge inzetten waarbij operationele efficiëntie van het grootste belang is. Tijdens deze live-evenementen moeten F1 IT-engineers kritieke problemen in hun services triëren, zoals netwerkdegradatie van een van hun API's. Dit heeft invloed op downstream-services die gegevens van de API gebruiken, waaronder producten zoals F1 TV, die live en on-demand verslaggeving van elke race bieden, evenals realtime telemetrie. Het bepalen van de hoofdoorzaak van deze problemen en voorkomen dat ze opnieuw gebeuren, kost veel moeite. Vanwege het evenementenschema en de periodes waarin wijzigingen worden bevroren, kan het tot 3 weken duren om een ​​kritiek probleem te triëren, testen en oplossen, wat onderzoek vereist van alle teams, waaronder ontwikkeling, operaties, infrastructuur en netwerken.

"We hadden een terugkerend probleem met het web-API-systeem, dat traag reageerde en inconsistente outputs leverde. Teams besteedden ongeveer 15 volledige engineerdagen aan het iteratief oplossen van het probleem in verschillende gebeurtenissen: logs beoordelen, anomalieën inspecteren en itereren op de oplossingen", zegt Lee Wright, hoofd IT Operations bij Formula 1. F1 zag deze uitdaging als een kans voor innovatie en ging een partnerschap aan met Amazon Web Services (AWS) om een ​​AI-gestuurde oplossing te ontwikkelen met behulp van Amazonebodem om probleemoplossing te stroomlijnen. In dit bericht laten we je zien hoe F1 een speciaal gebouwde root cause analysis (RCA)-assistent heeft gemaakt om gebruikers zoals operations engineers, softwareontwikkelaars en netwerkengineers in staat te stellen problemen op te lossen, de hoofdoorzaak te achterhalen en de handmatige tussenkomst die nodig is om terugkerende problemen op te lossen tijdens en na live-evenementen aanzienlijk te verminderen. We hebben ook een GitHub-repo geleverd voor een algemene versie van de bijbehorende chat-gebaseerde applicatie.

Gebruikers kunnen de RCA chat-based assistent vragen stellen met behulp van natuurlijke taalprompts, met de oplossing voor probleemoplossing op de achtergrond, het identificeren van mogelijke redenen voor het incident en het aanbevelen van vervolgstappen. De assistent is verbonden met interne en externe systemen, met de mogelijkheid om verschillende bronnen te bevragen, zoals SQL-databases, Amazon Cloud Watch logs en tools van derden om de status van de live-systeemgezondheid te controleren. Omdat de oplossing geen domeinspecifieke kennis vereist, kunnen zelfs engineers van verschillende disciplines en niveaus van expertise problemen oplossen.

"Met de RCA-tool kon het team de hoofdoorzaak achterhalen en binnen 3 dagen een oplossing implementeren, inclusief implementaties en testen tijdens een raceweekend. Het systeem bespaart niet alleen tijd bij actieve oplossingen, maar stuurt het probleem ook door naar het juiste team om op te lossen, zodat teams zich kunnen richten op andere taken met hoge prioriteit, zoals het bouwen van nieuwe producten om de race-ervaring te verbeteren", voegt Wright toe. Door generatieve AI te gebruiken, kunnen engineers binnen 5-10 seconden een reactie ontvangen op een specifieke query en de initiële triagetijd terugbrengen van meer dan een dag tot minder dan 20 minuten. De end-to-end-tijd tot oplossing is met maar liefst 86% teruggebracht.

Implementeren van de architectuur voor de oplossing voor root cause-analyse

In samenwerking met het AWS Prototyping-team is F1 begonnen met een prototype van 5 weken om de haalbaarheid van deze oplossing te demonstreren. Het doel was om AWS te gebruiken om het huidige handmatige probleemoplossingsproces voor twee kandidaatsystemen te repliceren en automatiseren. Als uitgangspunt heeft het team echte problemen beoordeeld en een stroomdiagram opgesteld met daarin 1) het probleemoplossingsproces, 2) de betrokken teams en systemen, 3) vereiste live checks en 4) de logonderzoeken die voor elk scenario vereist zijn. Hieronder volgt een diagram van de oplossingsarchitectuur.

architectuurdiagram voor een oplossing voor root cause-analyse

Om de loggegevens efficiënt te kunnen verwerken, werden de ruwe logs gecentraliseerd in een Amazon eenvoudige opslagservice (Amazon S3) emmer. Een Amazon EventBridge Schedule controleerde deze bucket elk uur op nieuwe bestanden en activeerde logtransformatie-extractie-, transformatie- en laadpijplijnen (ETL) die zijn gebouwd met behulp van AWS lijm en Apache Spark. De getransformeerde logs werden opgeslagen in een aparte S3-bucket, terwijl een ander EventBridge-schema deze getransformeerde logs naar Amazon Bedrock-kennisbanken, een end-to-end beheerd Ophalen Augmented Generation (RAG) workflow-mogelijkheid, waardoor de chatassistent hen efficiënt kan bevragen. Amazon Bedrock-agenten vergemakkelijkt de interactie met interne systemen zoals databases en Amazon Elastic Compute-cloud (Amazon EC2) instanties en externe systemen zoals Jira en Datadog. De Claude 3-modellen van Anthropic (het nieuwste model ten tijde van de ontwikkeling) werden gebruikt om hoogwaardige antwoorden te orkestreren en te genereren, waarbij nauwkeurige en relevante informatie van de chatassistent werd behouden. Tot slot wordt de chattoepassing gehost in een AWS Fargate voor betere Amazon Elastic Container-service (Amazon ECS)-service, die schaalbaarheid en betrouwbaarheid biedt voor het verwerken van variabele belastingen zonder dat dit ten koste gaat van de prestaties.

In de volgende paragrafen worden de belangrijkste onderdelen van de oplossing verder toegelicht: ETL-pipelines om de loggegevens te transformeren, agentische RAG-implementatie en de chattoepassing.

ETL-pijplijnen maken om loggegevens te transformeren

Het voorbereiden van uw gegevens om kwaliteitsresultaten te leveren is de eerste stap in een AI-project. AWS helpt u uw gegevenskwaliteit in de loop van de tijd te verbeteren, zodat u met vertrouwen kunt innoveren. Amazon CloudWatch geeft u inzicht in de systeembrede prestaties en stelt u in staat om alarmen in te stellen, automatisch te reageren op wijzigingen en een uniform beeld te krijgen van de operationele gezondheid.

Voor deze oplossing verwerkten AWS Glue en Apache Spark datatransformaties van deze logs en andere databronnen om de nauwkeurigheid en kostenefficiëntie van de chatbot te verbeteren. AWS Glue helpt u uw data op schaal te ontdekken, voorbereiden en integreren. Voor dit project was er een eenvoudig proces van drie stappen voor de logdatatransformatie. Hieronder ziet u een diagram van de dataverwerkingsstroom.

diagram met de stappen voor het maken van een ETL-pijplijn
  1. Gegevensstandaardisatie: schema's, typen en formaten – Door de data te conformeren aan een uniform formaat, begrijpt de chatassistent de data beter, wat de outputnauwkeurigheid verbetert. Om Amazon Bedrock Knowledge Bases in staat te stellen data te verwerken die afkomstig is van verschillende bronnen en formaten (zoals structuur, schema, kolomnamen, timestampformaten), moeten de data eerst worden gestandaardiseerd.
  2. Gegevensfiltering: onnodige gegevens verwijderen – Om de prestaties van de chatassistent verder te verbeteren, is het belangrijk om de hoeveelheid te scannen gegevens te verminderen. Een eenvoudige manier om dat te doen, is door te bepalen welke gegevenskolommen niet door de chatassistent zouden worden gebruikt. Dit verwijderde een aanzienlijke hoeveelheid gegevens in het ETL-proces, zelfs voordat deze in de kennisbank werden opgenomen. Bovendien werden de kosten van het embeddingsproces verlaagd, omdat er minder gegevens worden gebruikt om te transformeren en te tokeniseren in de vectordatabase. Dit alles helpt de nauwkeurigheid, prestaties en kosten van de chatassistent te verbeteren. De chatassistent heeft bijvoorbeeld niet alle headers van sommige HTTP-aanvragen nodig, maar wel de host en de useragent.
  3. Gegevensaggregatie: de gegevensomvang verkleinen – Gebruikers hoeven alleen per minuut te weten wanneer een probleem is opgetreden, dus het aggregeren van gegevens op minuutniveau hielp om de gegevensgrootte te verkleinen. Bijvoorbeeld, toen er 60 gegevenspunten per minuut waren met API-responstijden, werden gegevens geaggregeerd tot één gegevenspunt per minuut. Deze enkele geaggregeerde gebeurtenis bevat kenmerken zoals de maximale tijd die nodig was om een ​​verzoek uit te voeren, waardoor de chatassistent zich concentreerde op het identificeren of de responstijd hoog was, wat opnieuw de gegevens verminderde die nodig waren om het probleem te analyseren.

Het bouwen van de RCA-assistent met Amazon Bedrock Agents en Amazon Bedrock Knowledge Bases

Amazon Bedrock werd gebruikt om een ​​agentische (agent-gebaseerde) RAG-oplossing voor de RCA-assistent te bouwen. Amazon Bedrock-agenten stroomlijnt workflows en automatiseert repetitieve taken. Agents maakt gebruik van het redeneervermogen van funderingsmodellen (FM's) om door de gebruiker gevraagde taken op te splitsen in meerdere stappen. Ze gebruiken de meegeleverde instructie om een ​​orkestratieplan te maken en voeren het plan vervolgens uit door bedrijfs-API's aan te roepen en kennisbanken te openen met behulp van RAG om een ​​definitief antwoord aan de eindgebruiker te geven.

Kennisbanken zijn essentieel voor het RAG-framework, waarbij zakelijke gegevensbronnen worden opgevraagd en relevante context wordt toegevoegd om uw vragen te beantwoorden. Amazon Bedrock Agents maakt ook interactie met interne en externe systemen mogelijk, zoals het opvragen van databasestatussen om hun status te controleren, het opvragen van Datadog voor live applicatiebewaking en het aanmaken van Jira-tickets voor toekomstige analyse en onderzoek. Het Claude 3 Sonnet-model van Anthropic werd geselecteerd vanwege informatieve en uitgebreide antwoorden en het vermogen om uiteenlopende vragen te begrijpen. Het kan bijvoorbeeld correct gebruikersinvoerdatumformaten interpreteren, zoals "2024-05-10" of "10 mei 2024".

Amazon Bedrock Agents integreert met Amazon Bedrock Knowledge Bases en biedt de eindgebruiker een enkele en geconsolideerde frontend. De RCA-agent overweegt de beschikbare tools en knowledge bases en maakt vervolgens intelligent en autonoom een ​​uitvoeringsplan. Nadat de agent documenten van de knowledge base en reacties van tool-API's heeft ontvangen, consolideert hij de informatie om deze aan de groot taalmodel (LLM) en genereer de uiteindelijke respons. Het volgende diagram illustreert de orkestratiestroom.

architectuurdiagram voor een agentische rag chat-assistent

Systeembeveiliging

Met Amazon Bedrock hebt u volledige controle over de gegevens die worden gebruikt om de FM's aan te passen voor generatieve AI-toepassingen zoals RCA. Gegevens worden tijdens het transport en in rust gecodeerd. Identiteitsgebaseerde beleidsregels bieden verdere controle over uw gegevens, zodat u kunt beheren welke acties rollen kunnen uitvoeren, op welke bronnen en onder welke voorwaarden.

Om de systeemstatus van RCA te evalueren, voert de agent een reeks controles uit, zoals AWS Boto3 API-aanroepen (bijvoorbeeld boto3_client.beschrijf_beveiligingsgroepen, om te bepalen of een IP-adres toegang heeft tot het systeem) of SQL-query's in de database (SQL: sys.dm_os_schedulers, om de databasesysteemstatistieken zoals CPU, geheugen of gebruikersvergrendelingen op te vragen).

Om deze systemen te beschermen tegen mogelijke hallucinaties of zelfs prompte injecties, mogen agents niet hun eigen databasequery's of systeemgezondheidscontroles on the fly maken. In plaats daarvan werden een reeks gecontroleerde SQL-query's en API-controles geïmplementeerd, volgens het principe van de minste privileges (PoLP). Deze laag valideert ook het invoer- en uitvoerschema (zie Powertools-documentatie), en zorg ervoor dat dit aspect ook onder controle is. Raadpleeg het ArXiv-artikel voor meer informatie over het beschermen van uw applicatie. Van prompt-injecties tot SQL-injectieaanvallenDe volgende code is een voorbeeld.

"""
- Health Checks: one explicit function per Health Check, to avoid potential LLM hallucinations or risky syntax errors.
- DB is KMS-encrypted and behind private subnets. Connection uses Least-Privileges and Secrets Manager
- Schema is protected using OpenAPI, via AWS Lambda Powertools BedrockAgentResolver
"""

from typing import List, Annotated
from helpers import run_sql_query, check_ec2_port_access
from aws_lambda_powertools.event_handler.bedrock_agent import BedrockAgentResolver 
from aws_lambda_powertools.event_handler.openapi.params import Query, Body
from aws_lambda_powertools import Metrics, Tracer, Logger
from aws_lambda_powertools.metrics import MetricUnit

# Initialize Agents, Metrics, Loggers and Tracers
app = BedrockAgentResolver()
metrics = Metrics(namespace="rca-stack-api-logs", service="HealthChecks")
tracer = Tracer()
logger = Logger(level='INFO')

@tracer.capture_method
@app.get("/checkDatabaseCPUMemory", description='Checks the CPU and Memory usage, for the Database server.')
def check_db_cpu_memory() -> Annotated[List, Body(description='Returns Database CPU and Memory metrics')]:
    response = run_sql_query('db_cpu_memory')
    metrics.add_metric(name="DBCpuMemory", unit=MetricUnit.Count, value=1)
    logger.info(response)

    return response

Frontend-applicatie: de chat-assistent-UI

De gebruikersinterface van de chatassistent is ontwikkeld met behulp van de Gestroomlijnd framework, dat op Python is gebaseerd en eenvoudige maar krachtige applicatiewidgets biedt. In de Streamlit-app kunnen gebruikers hun Amazon Bedrock-agentiteraties naadloos testen door de agent-ID en alias-ID op te geven of te vervangen. In de chatassistent wordt de volledige gespreksgeschiedenis weergegeven en kan het gesprek worden gereset door te kiezen Wissen. Het antwoord van de LLM-applicatie bestaat uit twee delen. Links staat het uiteindelijke neutrale antwoord op basis van de vragen van de gebruiker. Rechts staat de trace van LLM-agentorkestratieplannen en -uitvoeringen, die standaard verborgen is om het antwoord schoon en beknopt te houden. De trace kan door de gebruiker worden bekeken en onderzocht om ervoor te zorgen dat de juiste tools worden aangeroepen en de juiste documenten worden opgehaald door de LLM-chatbot.

Een algemene versie van de chat-gebaseerde applicatie is beschikbaar via deze GitHub repo, waar u met de oplossing kunt experimenteren en deze kunt aanpassen voor aanvullende gebruiksgevallen.

In de volgende demo gaat het om klachten van gebruikers dat ze geen verbinding kunnen maken met F1-databases. Met behulp van de chatassistent kunnen gebruikers controleren of de versie van de databasedriver die ze gebruiken, wordt ondersteund door de server. Daarnaast kunnen gebruikers de netwerkconnectiviteit van EC2-instances verifiëren door de EC2-instance-ID en AWS-regio. Deze controles worden uitgevoerd door API-tools die toegankelijk zijn voor de agent. Bovendien kunnen gebruikers problemen met websitetoegang oplossen door systeemlogboeken te controleren. In de demo geven gebruikers een foutcode en datum op, en de chatassistent haalt relevante logs op uit Amazon Bedrock Knowledge Bases om hun vragen te beantwoorden en informatie te verstrekken voor toekomstige analyse.

Technische engineers kunnen nu query's uitvoeren om systeemfouten en -problemen te onderzoeken met behulp van natuurlijke taal. Het is geïntegreerd met bestaande incident management tools (zoals Jira) om naadloze communicatie en ticketcreatie te vergemakkelijken. In de meeste gevallen kan de chatassistent snel de hoofdoorzaak identificeren en aanbevelingen voor herstel doen, zelfs als er meerdere problemen zijn. Wanneer nodig worden bijzonder uitdagende problemen automatisch geëscaleerd naar het F1 engineering team voor onderzoek, waardoor engineers hun taken beter kunnen prioriteren.

Conclusie

In dit bericht hebben we uitgelegd hoe F1 en AWS een root cause analysis (RCA)-assistent hebben ontwikkeld die wordt aangestuurd door Amazon Bedrock om handmatige interventie te verminderen en de oplossing van terugkerende operationele problemen tijdens races te versnellen van weken naar minuten. De RCA-assistent stelt het F1-team in staat om meer tijd te besteden aan innovatie en het verbeteren van zijn services, wat uiteindelijk een uitzonderlijke ervaring oplevert voor fans en partners. De succesvolle samenwerking tussen F1 en AWS toont het transformatieve potentieel van generatieve AI om teams in staat te stellen meer te bereiken in minder tijd.

Ontdek hoe AWS de Formule 1 op en naast de baan helpt.


Over de auteur

Carlos Contreras is een Senior Big Data en Generative AI Architect, bij Amazon Web Services. Carlos is gespecialiseerd in het ontwerpen en ontwikkelen van schaalbare prototypes voor klanten, om hun meest complexe zakelijke uitdagingen op te lossen, en implementeert RAG en Agentic-oplossingen met Distributed Data Processing-technieken.

Hin Yee Liu is een Senior Prototyping Engagement Manager bij Amazon Web Services. Ze helpt AWS-klanten om hun grote ideeën tot leven te brengen en de adoptie van opkomende technologieën te versnellen. Hin Yee werkt nauw samen met klantenbelanghebbenden om impactvolle use cases te identificeren, vorm te geven en te leveren door gebruik te maken van Generative AI, AI/ML, Big Data en Serverless-technologieën met behulp van agile methodologieën. In haar vrije tijd houdt ze van breien, reizen en krachttraining.

Olga Miloserdova is Innovation Lead bij Amazon Web Services, waar ze directieteams in verschillende sectoren ondersteunt bij het stimuleren van innovatie-initiatieven met behulp van Amazon's klantgerichte Working Backwards-methodologie.

Ying Hou, PhD is een Senior GenAI Prototyping Architect bij AWS, waar ze samenwerkt met klanten om geavanceerde GenAI-applicaties te bouwen, gespecialiseerd in RAG- en agentische oplossingen. Haar expertise omvat GenAI, ASR, Computer Vision, NLP en time series prediction models. Wanneer ze geen AI-oplossingen ontwerpt, brengt ze graag quality time door met haar gezin, verdiept ze zich in romans en verkent ze de nationale parken van het Verenigd Koninkrijk.

Gerelateerde artikelen

spot_img

Recente artikelen

spot_img