Антипаттерн LLM-приложений: Когда модель игнорирует контекст. Часть 1

info@vsetut.pro

Стать автором

Вернуться

26.11.2025 11:37:05 | Хабр

Хабы: Искусственный интеллект, Машинное обучение, Программирование

Всем привет! Бездумно соглашаться с любыми хотелками заказчика или начальства в технических вопросах — почти то же самое, что саботировать проект: всё это быстро превращается в тяжёлый технический долг. Да, жёсткие сроки, ограниченный бюджет и нехватка "свободных рук" — реальность, с которой приходится считаться. Но это не отменяет простой вещи: свои опасения и архитектурные риски нужно озвучивать, выносить на обсуждение и предлагать не только «работающие на сейчас», но и масштабируемые решения.

Как разработчикам нам обычно говорят: «давайте максимально быстро и топорно соберём proof-of-concept (PoC)». Мы собираем PoC на костылях, а дальше слышим: «отлично, теперь давайте из этого сделаем MVP». Времени на переорганизацию и реинжиниринг архитектуры никто не даёт. В итоге недели и месяцы работы превращают проект в тупиковую поделку — груду классов, методов и промптов, к которой страшно прикасаться.

С LLM эта история становится ещё болезненнее. В работе у меня было несколько показательных проектов с LLM в роли основного движка (RAG, Q&A-системы), на которых я очень наглядно увидел, как делать не стоит. Эти «шишки» превратились в набор антипаттернов проектирования LLM-приложений, о которых я хочу поговорить в серии статей.

В этой части — антипаттерн взаимодействия с LLM, когда модель игнорирует контекст: важные детали промпта, куски документов и даже прямые инструкции.

Представьте ситуацию: вы даёте модели текст, в котором прямо содержится ответ на вопрос, но она отвечает что-то совсем не то. Вы прописываете инструкции, как именно нужно вести диалог и решать задачу, но они стабильно игнорируются. Вы добавляете новые чанки с данными, дописываете всё более подробные правила и уточнения — а качество ответов только падает.

Подробнее