Девять подводных камней LLM: как модели ошибаются и что с этим делать

Ловушки разбиты по этапам работы с LLM:

ЭТАП 1: Сбор данных - P1: Отравление данных через веб-скрапинг - P2: Неточность меток от LLM (LLM-as-judge)

ЭТАП 2: Предобучение - P3: Утечка данных (модель видела тест при обучении)

ЭТАП 3: Дообучение - P4: Коллапс модели от синтетических данных - P5: Ложные корреляции (модель учит неважные паттерны)

ЭТАП 4: Промптинг - P6: Обрезка контекста (текст не влезает) - P7: Чувствительность к формулировкам

ЭТАП 5: Оценка - P8: Ошибка замены (выводы о другой модели) - P9: Неопределённость модели (неясная версия)

Проблема: LLM обрабатывает только фиксированное окно токенов (обычно 4k–32k в зависимости от модели). Если ваш промпт + контекст длиннее — модель обрезает текст, часто с начала или конца, теряя критическую информацию.

Как проявляется: - Вставили код 2000 строк → модель видит только начало функции - Загрузили документ → модель пропустила последние разделы - В исследовании: 49% уязвимых функций не влезали в 512 токенов, 29% не влезали даже в 1024 токена

Что делать:

Перед отправкой длинного текста:

Проверь сколько токенов в моём тексте:
[вставить текст]

Если больше {лимит твоей модели} — раздели на части или сократи.

Практический чеклист: - GPT-4o: лимит 128k токенов (~96k слов) — но лучше держать в пределах 32k для стабильности - Claude 3.5: лимит 200k токенов — но качество падает на дальних концах - Для кода: одна функция на запрос, не весь файл сразу - Для документов: передавайте summary важных частей, не весь текст целиком

Проблема: Мелкие изменения в промпте дают совершенно разные результаты. Порядок слов, формальность тона, наличие примеров — всё влияет. Модель "настроена" на определённый стиль инструкций из дообучения (RLHF), и другие стили работают хуже.

Как проявляется: - "Найди баги в коде" vs "Проверь код на уязвимости" → разные находки - С примером vs без примера → разная точность - "Дай список" vs "Опиши подробно" → разная структура ответа

Что делать:

Техника А: A/B тест формулировок

У меня задача: {опиши задачу}.

Вот три варианта промпта:
1. [вариант 1]
2. [вариант 2]  
3. [вариант 3]

Прогони все три, покажи результаты. Какой сработал лучше и почему?

Техника Б: Попроси модель улучшить промпт

Вот моя задача: {задача}
Вот мой промпт: {текущий промпт}

Предложи 3 альтернативных формулировки, которые дадут более точный результат.
Объясни какие элементы промпта влияют на качество ответа.

Когда особенно важно: - Сложные задачи (код, анализ, рассуждения) - Когда результат критичен (безопасность, деньги, репутация) - При переходе между моделями (GPT → Claude → Llama)

Проблема: "GPT-4" или "Claude" — это не одна модель, а семейство версий. Модели обновляются без предупреждения, меняются токенизаторы, системные промпты, веса. Результат вчера ≠ результат сегодня. В исследовании: разные снапшоты GPT-4 дают разную точность на джейлбрейках и разные precision/recall на задачах классификации.

Как проявляется: - Вчера промпт работал отлично → сегодня не работает - Коллега не может воспроизвести ваш результат (у него другая версия) - Непонятно какую модель использовали в статье → нельзя повторить

Что делать:

В ChatGPT/Claude: Указывайте точную модель в заметках: - ✅ GPT-4o (gpt-4o-2024-08-06) — фиксированная версия - ✅ Claude 3.5 Sonnet, дата обращения: 15 марта 2025 - ❌ "GPT-4" — неясно какая версия

Для API:

# Фиксируйте снапшот, не общее имя модели
model="gpt-4o-2024-08-06"  # ✅ точная версия
# НЕ "gpt-4o" — будет брать latest

Для open-source (Huggingface): Указывайте commit ID или дату скачивания:

llama-3.1-8b-instruct, commit: a2cb1b9, quantization: 4-bit

Практический чеклист: - Сохраняйте версию модели в начале проекта - Если модель обновилась — перепроверьте критические промпты - В документации пишите точную версию, не общее название

Проблема: Когда LLM оценивает результаты работы другой (или своей же) LLM — это удобно, но неточно. LLM-судья может ошибаться, быть предвзятым к определённому стилю, пропускать тонкие ошибки. В исследовании: 15.3% работ использовали LLM-as-judge, но только 60% из них обсудили эту проблему.

Как проявляется: - Попросили ChatGPT оценить качество своего же кода → он переоценил - LLM оценивает креатив — но судит по формальным признакам (длина, структура), не по смыслу - Модель пропускает фактические ошибки, но хвалит стиль

Что делать:

Техника: Кросс-проверка моделями

Вот задача: {задача}
Вот решение: {решение}

Оцени качество решения по критериям: {критерии}.

Затем попроси вторую модель (другую) оценить то же решение.
Сравни оценки — где расхождения? Почему?

Для критических задач: - Используйте несколько моделей для оценки (GPT + Claude) - Финальную проверку делайте вручную или автотестами (для кода) - Просите модель обосновать оценку, не только число

Когда LLM-судья ОК: - Массовая фильтрация (отсеять явно плохое) - Черновая оценка (потом человек перепроверит) - Формальные критерии (длина, структура, формат)

Когда LLM-судья НЕ ОК: - Фактическая точность (цифры, факты, логика) - Безопасность кода (уязвимости) - Тонкие смысловые различия

Проблема: Если использовать выход LLM как вход для следующей генерации (рекурсивно) — качество падает. Модель начинает усиливать свои же ошибки, терять разнообразие, генерировать шаблонные ответы. Это называется Model Collapse. В исследовании: рекурсивная генерация кода повышает perplexity (модель становится менее уверенной), результаты деградируют.

Как проявляется: - Цикл: генерируй текст → улучши его → улучши ещё раз → ... → текст становится шаблонным - Используете AI-generated примеры для обучения AI → качество падает - Iterative refinement без внешнего контроля → модель "зацикливается" на своих паттернах

Что делать:

Правило: После 2-3 итераций AI→AI вводите внешнюю проверку.

Плохо (без контроля):

1. Сгенерируй черновик
2. Улучши черновик
3. Улучши ещё раз
4. Улучши финально
→ риск деградации

Хорошо (с контролем):

1. Сгенерируй черновик
2. [ЧЕЛОВЕК проверяет] — выделяет слабые места
3. Улучши с учётом feedback
4. [ТЕСТЫ или критерии] — проверка формальная
→ стабильное качество

Для кода:

1. LLM генерит код
2. [АВТОТЕСТЫ] — работает ли?
3. LLM фиксит ошибки
4. [ПОВТОРИТЬ тесты]
→ итерации с внешним критерием

Когда итерации OK: - Короткие циклы (1-2 итерации) - Есть внешняя проверка (человек, тесты, формальный критерий) - Задача узкая (форматирование, рефакторинг)

Когда осторожно: - Длинные цепочки AI→AI без проверок - Креативные задачи (риск шаблонности) - Обучение на AI-generated данных

Проблема: LLM обучены на огромных корпусах из интернета (GitHub, Wikipedia, Reddit, etc.). Если ваша задача или данные были доступны публично до даты обучения модели — модель могла их "видеть". Результат выглядит впечатляюще, но это не обобщение, а запоминание. В исследовании: утечка 20% тестовых данных повышает F1 на 0.08–0.11, рост почти линейный.

Как проявляется: - Модель идеально решает задачи из известного бенчмарка - GPT-4 отлично пишет код для популярной библиотеки (видела документацию в тренировке) - Модель "вспоминает" данные вместо того чтобы рассуждать

Что делать:

Правило: Если данные были в интернете до 2021-2023 (зависит от модели) — считайте что модель могла их видеть.

Проверка на утечку:

Вот задача: {задача}

Мог ли этот датасет быть в твоих тренировочных данных?
- Когда он был опубликован?
- Где он был доступен (GitHub, Kaggle, etc.)?
- Какие признаки что ты его "помнишь" vs "решаешь заново"?

Для своих задач: - ✅ Используйте свежие данные (после cutoff модели) - ✅ Используйте внутренние данные компании (не публичные) - ✅ Модифицируйте известные задачи (измените числа, контекст) - ❌ Не полагайтесь на бенчмарки которые модель могла видеть

Датасеты высокого риска: - GitHub repos (особенно популярные) - Wikipedia - Kaggle competitions - Известные CTF/security challenges

Модели — это паттерн-матчеры, не мыслители. LLM обучены предсказывать следующий токен на основе предыдущих. Это делает их чувствительными к формулировкам (разные слова → разные паттерны активации) и зависимыми от тренировочных данных (если видели в тренировке → работает лучше).

Контекст = оперативная память. LLM не имеют состояния между запросами. Всё что модель знает о задаче — это текущий промпт. Если текст не влезает в окно → модель работает с неполными данными, как человек который видит только часть картины.

Версии модели меняются постоянно. Провайдеры обновляют модели для улучшения качества, безопасности, скорости. Но каждое обновление — это новая модель с другими весами. Prompt engineering — это настройка под конкретную версию, и она не переносится автоматически.

LLM-судья наследует bias. Когда LLM оценивает текст, она применяет паттерны из своего обучения: длинный = хороший, формальный = правильный, похожий на её стиль = качественный. Она не проверяет факты и логику так как человек, а сравнивает с паттернами "хорошего текста" из тренировки.

Итерации AI→AI усиливают ошибки. Каждая генерация LLM немного отклоняется от реального распределения данных. Если использовать этот output как input — следующая генерация отклоняется ещё сильнее. Без внешнего "якоря" (проверка человеком, тесты, реальные данные) система дрейфует к шаблонным, менее разнообразным ответам.

Data leakage маскируется под обобщение. Когда модель видела данные в тренировке, она не "решает" задачу, а "вспоминает" паттерн. Это работает отлично на тесте (если тест тоже утёк), но проваливается на новых данных. Пользователь видит высокую точность и думает что модель обобщает, но это иллюзия.

Перед началом работы: - [ ] Зафиксировал точную версию модели (не "GPT-4", а "GPT-4o-2024-08-06") - [ ] Проверил длину промпта (влезает ли в context window?) - [ ] Понимаю какие данные модель могла видеть в тренировке

При создании промпта: - [ ] Протестировал 2-3 разных формулировки - [ ] Добавил примеры (few-shot) если задача сложная - [ ] Указал формат вывода явно (JSON, список, текст)

При итеративной работе: - [ ] После 2-3 итераций AI→AI ввожу внешнюю проверку - [ ] Для кода: использую автотесты между итерациями - [ ] Для текста: сам читаю промежуточные версии

При оценке результатов: - [ ] Если LLM оценивает результат — перепроверяю критические моменты - [ ] Использую несколько моделей для кросс-проверки - [ ] Не доверяю только численной оценке, смотрю на обоснование

При работе с кодом: - [ ] Передаю одну функцию/модуль за раз, не весь файл - [ ] Проверяю что все важные части кода попали в контекст - [ ] Запускаю код и тесты, не доверяю только объяснению модели

⚠️ Это не техники, а awareness: Чеклисты и принципы выше требуют вашего активного контроля. LLM не "исправит себя" автоматически — вы должны структурировать работу так чтобы обходить ловушки.

⚠️ Некоторые ловушки неизбежны: Data leakage в публичных датасетах, prompt sensitivity, версионность моделей — это фундаментальные ограничения LLM. Нельзя полностью избежать, можно только осознавать и минимизировать риск.

⚠️ Для исследователей больше чем для практиков: Многие ловушки (data poisoning, model collapse, spurious correlations) критичны для научных работ, но менее актуальны для ежедневного использования ChatGPT в задачах типа "напиши письмо" или "объясни концепцию". Фокус этого списка — на критичных применениях (код, безопасность, анализ).

Команда из 15 исследователей проанализировала все 72 работы про LLM и безопасность, опубликованные в топовых конференциях (IEEE S&P, NDSS, ACM CCS, USENIX Security, ICSE, FSE, ISSTA, ASE) за 2023-2024 годы. Это не выборка — это полный охват leading venues в Security и Software Engineering.

Сначала определили девять типов ловушек на основе структуры LLM pipeline: от сбора данных до оценки результатов. Затем разработали детальные guidelines для reviewers — как именно искать каждую ловушку в тексте работы. Каждую статью читали два человека независимо, потом обсуждали расхождения, а сложные случаи выносили на группу из 10 человек.

Результаты оказались неожиданными: 100% работ содержат минимум одну ловушку. Более того, пять ловушек (Data Leakage, Context Truncation, Prompt Sensitivity, Surrogate Fallacy, Model Ambiguity) встречаются в более чем 20% работ каждая. Но только 15.7% случаев авторы явно обсудили проблему — большинство ловушек остаются незамеченными.

Чтобы показать реальное влияние, провели четыре case study. Проверили как quantization и версии модели влияют на robustness к джейлбрейкам (Model Ambiguity), как утечка 20% данных повышает F1 на 0.08-0.11 (Data Leakage), как 49% уязвимых функций не влезают в 512 токенов (Context Truncation), и как рекурсивная генерация кода повышает perplexity и ведёт к деградации (Model Collapse).

Логика исследования: LLM research развивается быстро, но методология отстаёт. Старые гайдлайны для ML (типа Sculley et al. 2015) не покрывают специфику LLM — web-scale данные, prompt engineering, API versions, synthetic data. Авторы заполняют этот пробел систематическим анализом и дают actionable guidelines для каждой ловушки. Поддерживают living appendix на https://llmpitfalls.org с обновляемыми best practices.

Инсайт для практики: Если даже peer-reviewed работы в топовых конференциях содержат эти ловушки (часто неосознанно), то обычные пользователи LLM тем более подвержены этим проблемам. Awareness — первый шаг к более надёжной работе с моделями.

Chasing Shadows: Pitfalls in LLM Security Research

Jonathan Evertz, Niklas Risse, Nicolai Neuer, Andreas Müller, Philipp Normann, Gaetano Sapia, Srishti Gupta, David Pape, Soumya Shaw, Devansh Srivastav, Christian Wressnegger, Erwin Quiring, Thorsten Eisenhofer, Daniel Arp, Lea Schönherr

CISPA Helmholtz Center for Information Security, Max Planck Institute for Security and Privacy, Karlsruhe Institute of Technology, Ruhr University Bochum, TU Wien, Sapienza University of Rome

Living appendix с best practices: https://llmpitfalls.org

Код и датасеты: https://github.com/dormant-neurons/llm-pitfalls

NDSS Symposium 2026