Фрагментація промптів: чому старі підходи більше не працюють і чому індустрії потрібен новий фреймворк

За останні роки системи на базі великих мовних моделей (LLM) перестали бути лабораторними експериментами. Сьогодні це складні продакшн-рішення, інтегровані в бізнес-процеси, користувацькі продукти та внутрішні платформи автоматизації. Разом із цим різко зросла складність логіки, яку ми намагаємося «запакувати» у промпти.

І тут виникає фундаментальний розрив: архітектура систем еволюціонує, а підходи до роботи з промптами — ні.

Найпоширеніший патерн досі виглядає так: master prompt + include-фрагменти. Базова інструкція, до якої поступово додаються правила, уточнення, обмеження, сценарні вставки. По суті, це текстова компіляція без формальної моделі. У простих сценаріях вона працює. У складних — починає ламатися системно.

Фрагментація як неминучий наслідок зростання складності

Фрагментація промпта — це не випадковість і не помилка окремого розробника. Це природний наслідок того, що один цілісний намір розбивається на десятки незалежних фрагментів, які живуть своїм життям.

Кожен фрагмент може виглядати коректним у вакуумі. Але коли вони збираються разом, з’являються:

  • суперечливі інструкції,
  • неявні пріоритети,
  • дублювання або взаємне нівелювання сенсів,
  • залежності, про які ніхто вже не пам’ятає.

Ключова проблема в тому, що розробник не працює з фінальним промптом. Він працює з частинами, умовами, include-файлами, feature-флагами. Після серії інкрементальних змін уявити, який саме текст у підсумку отримає LLM, стає майже неможливо.

Фінальний prompt перетворюється на чорну скриньку.

Прозорість фінального результату: чого реально бракує

Одна з базових речей, яких не дає старий підхід, — прозорість фінальної збірки.

У реальній системі хочеться бачити:

  • повний фінальний prompt у тому вигляді, в якому він був переданий у модель;
  • всі фрагменти, які увійшли в цю збірку;
  • джерело кожного фрагмента;
  • порядок і контекст, у якому він був включений.

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

Ідеальна модель

Читати далі


Як не забути про ялинку

Коли люди роблять ремонт, вони майже завжди думають про велике: стіни, вікна, підлогу, меблі. А потім настає грудень, з’являється ялинка, гірлянда — і раптом з’ясовується, що розетки «тут не планувалися». Починаються подовжувачі, трійники, дроти через усю кімнату і універсальне виправдання: «Ну, потім якось вирішимо». Вирішити можна. Але дорого, негарно і незручно.

З програмною архітектурою відбувається рівно те саме.

На старті проєкту команда зазвичай зосереджується на ключовому функціоналі: основні модулі, бази даних, API, інтеграції. Усе виглядає логічно й охайно. Але якщо на цьому етапі не закласти важливі «дрібниці» — розширюваність, майбутні сценарії, точки зростання, — згодом вони починають з’являтися хаотично. Функціональність нарощується, архітектурні рішення ухвалюються несистемно, під тиском дедлайнів або конкретного запиту. У результаті те, що мало бути однією продуманою частиною системи, розмазується по всьому коду.

Це і є та сама забута ялинка.

Важливо розуміти: проблема не в тому, що вимоги змінюються. Це нормально. Проблема в тому, що архітектура спочатку не була спроєктована з розрахунком на подібну функцію. Найчастіше це наслідок недостатньої інженерної експертизи або відсутності зрілого архітектурного процесу. Рішення може працювати «тут і зараз», але в довгостроковій перспективі воно виявляється нераціональним і некоректним для конкретної системи.

Хороша архітектура — це не ідеальна схема на всі часи. Це система, у якіх мінімальна кількість подовжувачів, яка відповідає своїм цілям. Як розетка для ялинки: вона майже нічого не коштує на етапі планування, але економить гроші й нерви потім.

Логічне запитання: чи існує спосіб не забути спроєктувати справді важливі речі? Відповідь не є простою. Усе залежить від досвіду людей, які беруть участь у проєкті, і від того, наскільки вони розуміють, що саме важливо не проґавити.

У InterLink ми використовуємо кілька підходів,

Читати далі