PyData Prague #35 - Probably unreliable vulnerabilities

Ciao estrattori Python e agenti vulnerabili,

Il 35° incontro PyData si svolgerà presso gli **uffici del corridoio** (Palác Zlatý kříž, 2° piano). Come di consueto, le conferenze inizieranno alle 18:30, ma vi invitiamo a venire non appena alle **18:00** per godere dell'opportunità di socializzare e rinfrescarvi (cosa che potrete continuare a fare durante la pausa e dopo le conferenze).

Il nostro obiettivo principale è costruire la comunità attorno a Python e ai dati e renderla accogliente per persone con diverse competenze e livelli di esperienza.

⚡ Se sei interessato a tenere un discorso lampo (fino a 5 minuti per presentare un'idea, uno strumento o risultati correlati almeno in una certa misura a Python e/o ai dati), contattaci prima dell'evento o all'inizio.

**Cosa ci ha insegnato l'analizzatore di sicurezza LLM a file singolo?**
**([Forte Stanislav](https://www.linkedin.com/in/stanislav-fort/), Corridoio)**

La ricerca di alta qualità sulla sicurezza dell’intelligenza artificiale può scoprire vulnerabilità reali nelle infrastrutture critiche. AISLE è un esempio di questo approccio dal segnale più elevato, con risultati convalidati in progetti come OpenSSL e curl. Allo stesso tempo, i report di bassa qualità generati dall’intelligenza artificiale stanno inondando i manutentori open source di falsi positivi.

Quanto è difficile trovare un bug di sicurezza? Esploreremo questa domanda attraverso il nano-analizzatore, uno scanner di sicurezza open source volutamente semplice. Per molte classi di vulnerabilità, il nucleo sorprendente non è una piattaforma complessa, ma una chiamata LLM ben mirata inserita nel giusto flusso di lavoro.

Questa semplicità ha dei limiti. L'approccio potrebbe non cogliere problemi ovvi, creare allucinazioni su risultati rischiosi o produrre risultati incoerenti tra le esecuzioni. Ecco perché la validazione, il triage, il benchmarking e il giudizio umano sono importanti, e perché la vera sfida è costruire processi affidabili attorno a processi primitivi inaffidabili.

**Ottenere testo affidabile quando i PDF mentono e l'OCR fallisce**
**([Marcela Brichtová Piptová](https://www.linkedin.com/in/marcela-brichtov%C3%A1-piptov%C3%A1-b950ba184/), Rossum)**

Gli LLM necessitano di testo come input. Quindi, prima che un modello possa ragionare su un documento, dobbiamo leggere il testo, un passaggio spesso considerato la "parte facile" o un problema risolto. Ma lo è?

In questo discorso esploreremo le complessità nascoste dell'estrazione del testo. Ciò è particolarmente critico per modelli come T-LLM di Rossum, un'architettura esclusivamente codificatrice che fa molto affidamento su input di alta qualità. Imparerai perché i documenti transazionali a volte sono sorprendentemente difficili per l'OCR, perché non è sempre possibile semplicemente copiare e incollare il testo da un PDF e perché l'estrazione del testo è ancora un argomento per i ricercatori Rossum (e il nostro team di assistenza clienti).