PyData Prague #35 - Probably unreliable vulnerabilities

Вітаємо, екстрактори та вразливі агенти Python!

35-й мітап PyData відбудеться в офісах **Aisle** (Palác Zlatý kříž, 2 поверх). Як зазвичай, переговори розпочнуться о 18:30, але ми рекомендуємо вам прийти о **18:00**, щоб насолодитися можливістю поспілкуватися та підкріпитися (що ви можете продовжувати робити під час перерви та після переговорів).

Наша головна мета — побудувати спільноту навколо Python і даних і зробити її приємною для людей з різними навичками та рівнем досвіду.

⚡ Якщо ви зацікавлені в блискавичній доповіді (до 5 хвилин, щоб представити ідею, інструмент або результати, пов’язані принаймні певною мірою з Python та/або даними), зв’яжіться з нами перед заходом або на його початку.

**Чого навчив нас однофайловий аналізатор безпеки LLM?**
**([Станіславський форт](https://www.linkedin.com/in/stanislav-fort/), Прохід)**

Високоякісні дослідження безпеки ШІ можуть виявити реальні вразливості в критичній інфраструктурі. AISLE є одним із прикладів цього високосигнального підходу з перевіреними висновками в таких проектах, як OpenSSL і curl. У той же час низькоякісні звіти, створені штучним інтелектом, заповнюють супроводжуючих з відкритим вихідним кодом помилковими результатами.

Наскільки важко знайти помилку безпеки? Ми дослідимо це питання за допомогою наноаналізатора, навмисно простого сканера безпеки з відкритим кодом. Для багатьох класів уразливості несподіваним ядром є не складна платформа, а влучний виклик LLM, загорнутий у правильний робочий процес.

Ця простота має межі. Цей підхід може пропустити очевидні проблеми, призвести до ризикованих висновків або дати непослідовні результати під час прогону. Ось чому перевірка, сортування, бенчмаркінг і людське судження мають значення, і чому справжньою проблемою є створення надійних процесів навколо ненадійних примітивів.

**Отримання надійного тексту, коли PDF-файли брешуть, а OCR не вдається**
**([Marcela Brichtová Piptová](https://www.linkedin.com/in/marcela-brichtov%C3%A1-piptov%C3%A1-b950ba184/), Россум)**

LLM-ам потрібен текст як вхідні дані. Отже, перш ніж модель зможе міркувати про документ, ми повинні прочитати текст, крок, який часто розглядають як «просту частину» або розв’язану проблему. Але чи це так?

У цій доповіді ми дослідимо приховані складності вилучення тексту. Це особливо критично для таких моделей, як Rossum T-LLM, архітектура лише кодера, яка значною мірою покладається на високоякісний вхідний сигнал. Ви дізнаєтеся, чому транзакційні документи інколи напрочуд важко розпізнати, чому не завжди можна просто скопіювати та вставити текст із PDF-файлу та чому дослідники Rossum (та наша команда підтримки клієнтів) усе ще обговорюють вилучення тексту.