Зворотне формулювання запитів: як перетворити хорошу сесію з LLM на повторно використовуваний запит

Той запит, який нарешті працює, рідко є тим, з якого ви починали: він формується після кількох етапів корекцій, а потім зникає після закриття чату. Зворотне формулювання запитів змінює звичайний алгоритм роботи. Спочатку ви отримуєте результат, який вам подобається, а потім просите модель реконструювати інструкції, які б надійно його створили. Ви дізнаєтесь, як виловлювати ці інструкції з розмови, як відновлювати приблизний запит лише на основі результатів та де обидві ці методи перестають бути надійними.

Чому функціональний запит зазвичай загубляється

Зворотне формулювання запитів ґрунтується на тому, що сучасні передові моделі добре вміють аналізувати власний контекст. Воно може застосовуватися вручну у вікні чату або як етап у скриптованому процесі, і найбільш ефективне воно є у генерації коду та агентних робочих процесах, де вимоги є численними та легко забуваються.

Типовий цикл удосконалення

Уявіть собі розробника, який додає кінцеву точку реєстрації користувача до Python-сервісу. Метою є код FastAPI виробничої якості: перевірка вхідних даних, структуровані відповіді на помилки, логування та тести. Початкове запитання є досить розпливчастим — на кшталт «напишіть кінцеву точку FastAPI для реєстрації користувача», і перша відповідь, як і очікувалося, є мінімальною. Тож розробник продовжує працювати над цим:

• Прохає надати моделі Pydantic для перевірки електронної пошти та сили пароля.
• Прохає додати належні HTTP-винятки та функції логування.
• Прохає забезпечити єдину, послідовну структуру JSON для кожної помилки.
• Прохає створити тести pytest, які охоплюють успішний сценарій та випадки невдалих перевірок.

Через кілька кроків код досягає вимог команди, його копіюють у репозиторій, а розмову, як і всі обмеження та корективи, що вплинули на неї, забувають. Наступний кінцевий пункт знову починається з нечіткого однорядкового опису.

Витягування одноразового запиту з розмови

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

Now that we have reached this final output, reverse-engineer
the entire conversation. Look at every correction, added constraint,
tone adjustment, format decision, and the result.
Produce one complete, standalone prompt that would generate
this exact output quality in a single shot with no follow-ups.

The prompt must explicitly state:
- Role and expertise level
- All background context and requirements established
- Every constraint and rule settled on
- Output format and structure
- Tone, style, and quality criteria
- Any examples or reference patterns used

Output only the prompt itself, ready to copy into a fresh session.
No explanation.

Те, що повертається, — це чітке описування всього того, що є неявним у діалозі. Нова сесія, яка використовує цей формат, має давати схожий результат вже при першій спробі; якщо все одно потрібні додаткові кроки, це означає, що щось було пропущено.

Розглядайте результат як інженерний актив:

• Збережіть його у репозиторії поруч із кодом, який він генерує, щоб зміни підлягали перевірці та версіонуванню.
• Поділіться ним із колегами, щоб однакові стандарти дотримувалися незалежно від того, хто його запускає.
• Замініть частини, специфічні для конкретного завдання, на параметри (назва елемента, поля, коди помилок) та використовуйте його для схожих кінцевих точок.

Відновлення запиту лише на основі результатів

Метод розмови працює лише тоді, коли у вас ще є історія спілкування. Більш універсальна техніка, відома як інверсія запиту або зворотна інженерія запиту (RPE), дозволяє відтворити приблизну версію запиту лише на основі тексту, який він створив.

Формально це означає так: певний прихований запит X створив результат O. Ви хочете знайти запит P, чий результат N буде семантично та функціонально близьким до O. У вас є доступ лише до „чорної скриньки“, тобто немає жодних логітів чи даних для навчання — лише можливість надсилати запити та читати відповіді.

Вибір кандидатів та їх перевірка

Прямий підхід складається з трьох кроків:

• Дайте моделі результат O та попросіть її визначити запит, який стояв за ним. Одне припущення часто призводить до надналаштування моделі або створення обмежень, яких насправді не існує, тому виконуйте це кілька разів із різними параметрами температури та вибору зразків, щоб зібрати набір кандидатських запитів.
• Пропустіть кожен кандидат через модель та порівняйте отриманий результат із O, використовуючи такий показник перекриття, як ROUGE-1 (очко F1 на основі спільних уніграм).
• Збережіть кандидата з найвищим балом.

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

Еволюція кандидатів за принципом генетичного алгоритму

Ви також можете розглядати кандидатів як популяцію та сприяти їхній еволюції. Кожне покоління:

• Оцінюйте придатність як середню схожість між результатами, які генерує кандидат, та оригінальним O.
• Зберігайте найкращі результати.
• Мутуйте слабші варіанти, надаючи моделі поточний запит разом із спостережуваними відмінностями, та дозволяючи їй перефразувати текст, додавати чи видаляти обмеження або змінювати його структуру.
• Повторюйте процедуру, поки оцінки більше не покращуються або не закінчиться бюджет.

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

Обмеження, на які варто зважати

Реконструкція завжди є наближеною. Відновлений запит часто буває довшим та більш конкретним, ніж той, що створив початковий результат, оскільки йому потрібно вказати нюанси, які спочатку передавалися через контекст.

Ще два застереження:

• Інженерія назад запрошень кодує особливості моделі, з якої вони були створені. Запрошення, налаштоване під одну модель, може потребувати корекції перед тим, як ефективно працювати з іншою, тому перевіряйте його ще раз під час зміни моделі.
• Лексичні метрики, такі як ROUGE-1, оцінюють спільні слова, а не правильну поведінку. Для коду чи структурованого виводу розгляньте можливість додавання перевірок, важливих для вас, наприклад, чи проходять генеровані тести чи є коректним JSON, окрім оцінки схожості.

Яке місце займають агенти для програмування

Інструменти агентного кодування, такі як OpenAI Codex та Claude Code, оптимізовані для прямого виконання завдань, з потужною обробкою контексту, довгими циклами роботи агента та активним використанням кешування запитів. Проте обидва інструменти можуть зупинитися перед написанням коду та поставити вам запитання з кількома варіантами відповідей для уточнення, що дозволяє рано виявити необхідні умови. Продовжуйте працювати з агентом, поки результат не стане достатньо якісним, а потім витягніть основний запит з цієї сесії для одноразового подальшого використання. Щоб дізнатися про альтернативний спосіб структурування витягнутих запитів, перегляньте наш посібник щодо створення запитів для LLM, готових до використання у продакшені, за допомогою семишарової структури.

Ключові висновки

• Справжня цінність тривалої сесії формування запитів полягає у накопичених обмеженнях; зафіксуйте їх перед закриттям чату.

Одна мета-інструкція в кінці успішної розмови перетворює її на окремий, версійований запит.

Коли існують лише результати вихідних даних, необхідно створити багато кандидатських запитів та дозволити метриці схожості, а не рівню впевненості моделі, обрати найкращий варіант.

Відновлені запити є приблизними та пов’язаними з конкретною моделлю, тому їх потрібно перевіряти у новій сесії та щоразу, коли змінюється модель.

Пов’язана література

• Безпечна заміна моделей LLM: людські мітки, метрики за кроком, налаштування зусиль — як мігрувати багатокроковий пайплайн LLM на новіші моделі, уникаючи уявних регресій: людські еталонні дані, метрики за кроком, застарілі запити та вимірювання зусиль для міркувань.
• Де мають бути інструкції Claude Code: CLAUDE.md, правила шляхів чи хуки — Дізнайтеся, чому Claude Code використовує CLAUDE.md як контекст, як його оптимізувати, як застосовувати правила до певних шляхів, як переміщувати кроки, що мають виконуватися, у хуки, та як перевірити, що насправді завантажено.
• Інструменти оцінки для додатків на основі LLM: набори даних, системи оцінювання та механізми виявлення регресії — Дізнайтеся, що таке інструмент оцінки для додатків на основі LLM, які є його чотири основні компоненти, та як він допомагає виявляти регресію у запитах та справедливо порівнювати моделі перед тим, як вони потраплять до користувачів.
• Самостійно розміщений Vision LLM OCR у Go: растеризація, формування запитів, парсинг — як працівник на Go перетворює медичні PDF-файли на структурований JSON за допомогою Ollama, pdftoppm, суворих запитів, резервного парсингу та груп споживачів Redis Streams.
• Створіть особистий інструмент для вдосконалення та генерації запитів за допомогою Claude Artifacts — як перетворити одну розмову в Claude на інструмент запитів, який можна повторно використовувати для покращення слабких запитів та розширення грубих ідей до базових, просунутих та експертних версій.