Юридична команда однієї з адвокатських фірм впровадила RAG-асистента для пошуку в 2000 договорів. Через кілька тижнів вони помітили, що асистент точно відповідає на запитання щодо положень з першої та останньої сторінки документа, але систематично ігнорує умови з середніх розділів. Модель не була зіпсована. Проблема полягала в тому, що до кожного запиту потрапляло 20-30 фрагментів тексту без жодного сортування, а ті, що опинялися в середині вікна, модель сприймала з нижчим пріоритетом.
Це класичний приклад поганого context engineering. Не йдеться про те, скільки тексту ви надасте моделі. Йдеться про те, що саме ви надасте, в якому порядку і чи має модель реальний шанс цим скористатися.
Точний retrieval замість ущільнення всього документа
#Найпоширеніша помилка — передавати до LLM весь документ замість точно відібраних фрагментів. У документах обсягом 50 і більше сторінок вікно контексту швидко заповнюється, витрати зростають, і все одно немає гарантії, що модель зосередить увагу на потрібному розділі.
Підхід на основі RAG працює інакше: замість цілого документа до моделі потрапляє 5-10 фрагментів, відібраних за допомогою семантичного пошуку та опціонально reranker. Якість цих фрагментів залежить від chunking, про який ми пишемо в статті про chunking документів для RAG. На практиці впроваджень видно чітко, що якість отриманих фрагментів має більший вплив на точність відповідей, ніж параметри самої моделі.
Рішення за людиною: кількість отримуваних фрагментів (top-k) та поріг відхилення слабких результатів (score threshold) потребують калібрування на тестовому наборі, специфічному для вашого документа та домену. Налаштування цих параметрів — це інженерна діяльність, а не алгоритмічна.
Ефект lost-in-the-middle та порядок фрагментів
#У 2023 році дослідники зі Стенфордського університету опублікували спостереження, яке практики впроваджень AI знають з власних проєктів: мовні моделі значно краще запам’ятовують інформацію з початку та кінця вікна контексту, ніж з його середини. Ефект посилюється зі збільшенням довжини вікна. При вікні 16 000 токенів інформація, розміщена на позиції від 6000 до 10 000 токенів, може бути практично проігнорована моделлю.
Практичні наслідки для порядку вставлення контексту:
- Системна інструкція: завжди на початку, перед фрагментами документа.
- Найбільш релевантні фрагменти RAG: на початку списку, а не в кінці.
- Історія діалогу: після системної інструкції, але перед фрагментами документів.
- Фрагменти з низькою релевантністю: якщо їх потрібно додати, розмістіть у середині. Краще їх відфільтрувати.
Результат reranking можна використати для сортування: фрагмент з найвищим score потрапляє першим, найнижчий — останнім (якщо взагалі). У Cashcrown ми рекомендуємо тримати менше 8 фрагментів в одному вікні контексту для фактографічних запитів. Більше рідко покращує якість, але завжди підвищує витрати.
Компресія історії діалогу
В асистентах для спілкування історія діалогу зростає з кожним обміном. Після 10-15 турів діалог може займати 3000-6000 токенів, перш ніж ви додасте фрагменти з бази знань. Дві стратегії компресії, які ми застосовуємо на практиці:
Крокова сумаризація: після кожного n-го туру (наприклад, кожні 5 обмінів) агент генерує підсумок попередньої частини діалогу та замінює ним повні транскрипти цих турів. Підсумок займає 200-400 токенів замість 1500-2500. Недолік: точні факти, що згадувалися в середині розмови, можуть бути спрощені в резюме. Вимагайте цитування джерела в підсумку або зупиняйтеся на рішеннях, що потребують точності.
Векторна пам’ять із селекцією: замість переписування історії ви зберігаєте її у векторній базі (шаблон описаний у статті про пам’ять агента AI) та отримуєте лише ті фрагменти, які важливі для поточного запиту. Історія з сесії тижневої давнини не захаращує вікно, якщо вона не потрібна.
Вибір між цими підходами залежить від характеру діалогу. Для багатотурових розмов про один документ крокова сумаризація працює краще. Для асистентів, що обслуговують клієнтів протягом багатьох тижнів, векторна пам’ять є необхідністю. Рішення про спосіб компресії має приймати людина, яка розуміє, які дані з історії є критичними для конкретного застосування.
Бюджет токенів та вартість і затримка
Кожен токен у вікні контексту коштує і впливає на час відповіді. Для хмарних моделей вартість вхідних токенів становить 0,5-15 USD за мільйон токенів залежно від моделі. При self-hosting це час GPU та затримка. Повні витрати та шаблони оптимізації описані в статті про вартість токенів LLM.
У таблиці нижче показано, як різні стратегії заповнення контексту впливають на бюджет токенів, вартість та ризик погіршення якості:
| Стратегія | Типовий розмір контексту (токени) | Відносна вартість | Ризик lost-in-middle |
|---|---|---|---|
| Повний документ без фільтрації | 8 000-128 000 | висока | високий при понад 16k |
| RAG top-5 без reranking | 1 500-3 000 | низька | низький |
| RAG top-10 з reranking | 2 500-5 000 | середня | низький (сортування) |
| Повна історія 15 турів | 3 000-6 000 | середня | середній |
| Стиснута історія | 800-1 500 | низька | низький |
| Повна історія + повний док | понад 20 000 | дуже висока | дуже високий |
Хороше проектне правило: кожен елемент контексту має бути обґрунтований конкретною користю для якості відповіді. Якщо ви не можете пояснити, чому даний фрагмент там є, видаліть його.
Компресія та форматування контексту
Форма контексту має значення поряд з його змістом. Сирий PDF після OCR з артефактами, повторюваними заголовками та примітками — гірший контекст, ніж той самий текст після очищення та структурування.
Кілька конкретних шаблонів, які покращують якість відповідей:
Позначення джерел: кожен фрагмент з RAG має бути попередньо позначений етикеткою [Джерело: Договір XYZ, §3.2], що дозволяє моделі цитувати та дає змогу системі guardrails перевіряти, чи відповідь не виходить за межі наданих фактів. Цитування джерел у відповіді — базовий механізм обмеження галюцинацій. Детальніше про цей шаблон у статті про обмеження галюцинацій AI.
Деконтекстуалізація фрагментів: фрагмент «У цій справі термін становить 14 днів» без інформації, про яку справу йдеться, є некорисним. При chunking варто додавати заголовок розділу як префікс до кожного фрагмента, щоб модель мала контекст його позиції в документі.
Негативна інструкція в промпті: явне вказівка моделі відповідати «не знаю» замість спекуляцій, коли фрагменти не містять відповіді, зменшує кількість вигаданих відповідей. Це частина інжинірингу промптів, детальніше описана в статті про prompt engineering для бізнесу.
Рішення за людиною: при виходах високого ризику (юридичні, медичні, фінансові рішення) система завжди має вказувати вихідний фрагмент, з якого походить відповідь. Перевірка цього цитату людиною — обов’язковий етап перед прийняттям рішення на основі відповіді моделі.
Протестуйте власний сценарій
FAQ
#Скільки фрагментів RAG варто вкладати в один запит?
#Оптимальна кількість залежить від довжини фрагментів та моделі, але на практиці 5-8 добре переранжованих фрагментів дають кращі результати, ніж 15-20 фрагментів без селекції. Вище 10 фрагментів ризик ефекту lost-in-the-middle зростає, а вартість інференсу зростає лінійно. Почніть з top-5, виміряйте якість на тестовому наборі та збільшуйте обережно.
Чи довше вікно контексту замінює добре спроєктований RAG?
#Ні. Моделі з вікнами 128 000 або більше токенів спокушають вставляти весь документ без фільтрації, але точність відповідей на запитання про деталі з середини документа тоді нижча, ніж при ретельному retrieval. Велике вікно контексту — корисний інструмент на випадок надзвичайних ситуацій або для разового аналізу, а не заміна архітектури RAG у продуктивних системах.
Як діяти з запитаннями, на які фрагменти RAG не дають відповіді?
#Системна інструкція має явно наказувати моделі повертати відповідь «не маю достатньо інформації в доступних документах» замість спекуляцій. Варто виміряти показник таких відповідей (так званий «не знаю» rate) на тестовому наборі: значення нижче 5-10 відсотків для добре проіндексованої бази знань — хороший орієнтир. Вищий показник може вказувати на проблеми з chunking або retrieval.
Як компресія історії діалогу впливає на узгодженість довгих діалогів?
Крокова сумаризація може губити точні факти, згадані в стисненій частині розмови. Захист: зберігайте ключові факти (числа, дати, назви сторін) як окремий структурований запис поряд із підсумком. Агент може оновлювати цей запис після кожного туру. Для конфіденційних даних рішення про те, що потрапляє до постійної пам’яті, має затверджувати політика зберігання, схвалена людиною.
Чи є context engineering одноразовою конфігурацією чи безперервним процесом?
#Безперервним. Розподіл запитів користувачів змінюється з часом, а разом з ним змінюється й оптимальна конфігурація retrieval та порядку контексту. Рекомендуємо щомісячний огляд золотого тестового набору: якщо показник faithfulness або точності відповідей падає більше ніж на 5 процентних пунктів, дослідіть, чи змінився розподіл запитів або структура документів. Такі аудити якості — це безперервний процес, а не одноразове налаштування системи.