// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

Come Jefferies ha costruito un trade assistant agentico su AWS

Jefferies ha costruito un trade assistant agentico su AWS con Strands Agents, Amazon Bedrock e MCP: dai una domanda in linguaggio naturale, l’agente genera la SQL e interroga le sorgenti di trading.

I trader di front office hanno bisogno di insight in tempo reale su comportamento dei clienti, pattern di trading e trend di mercato, ma raramente hanno il tempo o le competenze di coding per costruirsi i sistemi che li producono. Jefferies, banca d’investimento globale, ha affrontato il problema con un trade assistant agentico costruito su AWS, e il post ne descrive architettura e scelte tecniche.

Al centro c’è un agente domain-specific che dialoga con i trader in linguaggio naturale. È costruito su Strands Agents, un SDK open source per orchestrare chiamate a foundation model e tool esterni, e usa Amazon Bedrock con Anthropic Claude, le Bedrock Knowledge Bases e il Model Context Protocol (MCP) per collegarsi alle sorgenti dati. Quando un trader pone una domanda, Bedrock interpreta l’intento, genera la SQL corrispondente e la esegue sulle sorgenti sottostanti, mantenendo il contesto della conversazione per drill-down successivi.

Come funziona

Il flusso passa per otto step, a partire dal widget integrato nell’interfaccia di trading GFM. Un servizio di autenticazione su Amazon EKS verifica chi può accedere ai dati sensibili; un bot service gestisce la sessione; il Query Agent basato su Strands interroga le Knowledge Bases (con Amazon Titan Embeddings) per recuperare schemi, relazioni tra tabelle e pattern di query, poi Claude genera la SQL e sceglie il tool giusto tra quelli MCP — dalla in-memory grid per le posizioni real-time allo storico per le analisi time-series. Un Query Executor inietta filtri SQL per la row-level security prima di eseguire. Sul fronte sicurezza il sistema usa Bedrock Guardrails per moderazione e filtro PII, oltre al logging delle conversazioni per gli audit trail.

Le lezioni dichiarate sono utili a chi progetta soluzioni simili. Per contenere le hallucination, il team ha deliberatamente evitato di far generare le visualizzazioni all’LLM: il modello si occupa di comprensione del linguaggio e generazione della query, mentre engine dedicati disegnano grafici e tabelle. Ha usato database in-memory per la latenza minima richiesta dal trading, ha investito in observability aspettandosi comportamenti utente in evoluzione, e ha diviso i linguaggi — Python per le interazioni con l’LLM, Java per il processing ad alto throughput. L’impatto di business è descritto in termini qualitativi: più tempo per le relazioni con i clienti e meno lavoro IT per dashboard ripetitive, senza cifre puntuali.

In sintesi

  • Un agente su Strands Agents + Amazon Bedrock (Claude) traduce domande in linguaggio naturale in SQL sulle sorgenti di trading.
  • MCP per collegare le fonti, Knowledge Bases per lo schema, Guardrails e row-level security per compliance e dati sensibili.
  • Scelte chiave: visualizzazioni fuori dall’LLM, database in-memory per la latenza, Python per l’AI e Java per il throughput.

Fonte: Building trade assistant: How Jefferies optimized front office trading operations with AI — https://aws.amazon.com/blogs/machine-learning/building-trade-assistant-how-jefferies-optimized-front-office-trading-operations-with-ai/

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma