💭 Как проектировать LLM-приложения, чтобы контекст реально работал (а не ломал ответы) С учётом lost in the middle, позиционных перекосов и деградации на длинном контексте, набор практичных принципов: 1️⃣ Держите контекст минимальным и целевым В промпте – только то, без чего модель точно не ответит. Всё, что “на всякий случай”, выталкивает важное в слепую середину. 2️⃣ Разделяйте “долгую память” и “рабочую память” История/факты/прошлые ответы – во внешнее хранилище (БД/векторы). В промпт – краткое summary + реально релевантные куски. 3️⃣ Не “сливайте” документы целиком Используйте retrieval + re-ranking. Сначала топ-N (BM25/вектор), потом сузить до k самых полезных (re-rank моделью или самой LLM) – и только это в промпт. 4️⃣ Стройте промпт с учётом позиции В начало – цель и ключевые правила. В середину – сырой контекст. В конец – краткое резюме фактов + вопрос. Критичное дублируйте ближе к хвосту. 5️⃣ Шаблоны и режимы вместо простыни правил 2–3 режима работы + формат ответа (например JSON-схема + 1–2 примера) обычно лучше десятков “если/то”. 6️⃣ Разбивайте “гигантский запрос” на шаги Сначала уточнения/план, затем подтягивание нужных фрагментов ретривером, потом финальный ответ на коротком сфокусированном контексте. 7️⃣ Не тратьте окно на то, что модель и так знает Общие знания – оставляем модели. В окно – доменные, свежие и локальные факты. 🎱 Контролируйте рост системного промпта Если инструкции стали “повестью” – рефакторинг: часть логики в код/конфиг. И обязательно сравните качество “короткой” и “длинной” версии — короткая часто выигрывает. ❗️Это не чек-лист, который надо внедрить весь сразу. Но если держать эти принципы в голове, контекст начинает помогать, а не ухудшать качество. 🎯 Подробнее в статье на Хабре.