Запити – це спроєктовані системи з п’ятьма рівнями, які створюють детермінований, готовий до виробництва код замість ненадійних результатів ШІ.
Якщо 2025 рік був роком, коли організації відкрили для себе інженерію запитів як дисципліну, то 2026 рік стане роком, коли ми встановимо її як стандартну практику. Запити – це не хитрі текстові трюки, а програмні компоненти з архітектурами, режимами збоїв та вимогами життєвого циклу. Зі збільшенням розгортання LLM у виробничому середовищі наслідки зростають від «дивної реакції» до «порушення відповідності» або «неправильних даних клієнта». Це вимагає фундаментального зрушення: ми повинні думати про запити, як про API або мікросервіси. Запити (питання, інструкціъї) – це не речення, це спроєктована система, розроблена для узгоджених результатів за різних умов.
Запити – це системи, а не рядки
Коли розробники кажуть, що запити «працювали вчора, але не сьогодні», вони виявляють, що запити поводяться як моделі машинного навчання, а не як статичний код. Вони кодують намір, контекст, обмеження та очікування. Коли будь-яка зміна – версія моделі, розподіл вхідних даних або порядок прикладів – призводить до зміщення результатів.
Щоб зробити запити детермінованими, потрібні структуровані системи з п’ятьма рівнями:
- Рівень наміру: Що є завданням, а що ні.
- Рівень контексту: Що потрібно знати моделі.
- Рівень обмежень: Як повинні поводитися виходи.
- Рівень пам’яті: Які попередні взаємодії мають значення.
- Цикл перевірки: Механізми самоперевірки.
Це перетворює інженерію запитів з творчого письма на справжню інженерію.
Рівень 1: Рівень наміру
Запити для виробництва потребують кришталево чіткої мети. Розпливчасті цілі, такі як «Створити резюме», працюють для дослідження, а не для виробництва. Детерміновані запити чітко визначають успіх, невдачу та обсяг.
Приклад: Компонент банківської картки
Task: Generate a reusable Jetpack Compose card component for banking accounts.
Success Criteria:
- Adapts to account types (checking, savings, credit cards)
- Displays: account name, masked number, current balance
- Optional CTA button ("Get virtual card", "View debit card")
- Material Design 3 compliance, dark mode support
Failure Conditions:
- NO hardcoded account data
- NO balance calculations
- NO API calls or business logic
- NO sensitive data in component state
Out of Scope: Data fetching, transaction history, navigation
Рівень 2: Рівень контексту
Контекст неправильно розуміють. Розробники перевантажують запити абзацами, сподіваючись, що щось «запам’ятається». Ефективний контекст мінімальний, релевантний та структурований. Структурований контекст (ефективний):
Context:
- Platform: Android (Kotlin, Jetpack Compose)
- Architecture: MVVM + Clean Architecture
- UI Framework: Material Design 3
- Target API: Android 24+
- State Management: ViewModel with StateFlow
Account Types:
Credit cards - balance, "Get virtual card" CTA
Checking accounts - balance, "View debit card" CTA
Savings - balance, "View details" CTA
Design System:
- Card elevation: 4.dp, corner radius: 16.dp
- Typography: title (20sp), body (14sp)
- Colors: Blue gradient, white text
Модель тепер має точне кадрування без перевантаження.
Рівень 3: Рівень обмежень
Саме тут проявляється інженерна дисципліна. Обмеження перетворюють нечіткі міркування на детерміновану поведінку.
Виробничі обмеження:
// Architecture Requirements
// - Stateless Composable function
// - Accept AccountUiState data class parameter
// - Callbacks only: onCardClick, onCtaClick
// - NO remember { } blocks
// - NO LaunchedEffect or mutableStateOf
// Data Model
data class AccountUiState(
val accountId: String,
val accountName: String, // "Quicksilver", "360 Checking"
val accountType: AccountType,
val maskedNumber: String, // "...0501"
val balance: String, // "$524.63"
val ctaText: String? // "Get virtual card" or null
)
// Security Requirements
// - Pre-masked account numbers only
// - NO logging sensitive data
// - NO hardcoded test data
// - String resources for accessibility
// UI Requirements
// - Material 3 Card (androidx.compose.material3)
// - 4.dp elevation, 16.dp corner radius
// - Gradient background
// - CTA button only if ctaText != null
// - Minimum 48.dp touch targets
Рівень 4: Рівень пам’яті
Пам’ять керує станом під час взаємодій зі штучним інтелектом. Контекст визначає, що модель знає зараз; пам’ять визначає, що вона зберігає з часом. Структура пам’яті:
Session Memory:
component: AccountCard.kt
iteration: 3
established_decisions:
data_model: AccountUiState
callbacks: [onCardClick, onCtaClick]
design: Material 3, 4.dp elevation, stateless
evolution:
- v1: Basic card with text (completed)
- v2: Added CTA button (completed)
- v3: Adding gradient (in progress)
constraints:
- NO remember blocks
- Maximum 100 lines
- Callbacks only
Це гарантує, що ітерації будуються на попередній роботі без регресії.
Рівень 5: Цикл перевірки
LLM отримують вигоду від самоперевірки ‒ другого проходу оцінки відповідності інструкціям.
Контрольний список перевірки:
## Security Review
- [ ] Account numbers pre-masked only?
- [ ] NO logging sensitive data?
- [ ] NO remember { } or mutableStateOf?
- [ ] NO hardcoded test data?
## Architecture Review
- [ ] Completely stateless?
- [ ] Accepts AccountUiState parameter?
- [ ] Callbacks: onCardClick, onCtaClick?
- [ ] NO LaunchedEffect?
## UI/UX Review
- [ ] Material 3 Card?
- [ ] 4.dp elevation, 16.dp corners?
- [ ] CTA only when ctaText != null?
- [ ] 48.dp minimum touch targets?
- [ ] Preview functions included?
Триетапний шаблон верифікації
- Генератор – створює початковий код.
- Оцінювач безпеки – перевіряє відповідність PCI DSS, маскування та ведення журналу.
- Оцінювач архітектури – перевіряє MVVM, підняття стану, розділення проблем.
Це переходить від ймовірнісного до контрольованого, перевіреного коду.
Чому детермінізм важливий
У фінансових програмах детерміновані системи запитів забезпечують такі компоненти:
- Надійна автоматизація: генерують понад 20 варіантів облікових записів з узгодженою архітектурою.
- Стабільна якість: кожен компонент дотримується ідентичних шаблонів.
- Зменшення вразливостей: обмеження запобігають витоку даних.
- Швидший огляд: рецензенти очікують узгодженої структури.
- Легше обслуговування: єдиний дизайн компонентів.
- Впевненість у відповідності: перевірки безпеки вбудовані в генерацію.
Запити як код
Прогресивні команди ставляться до запитів як до першокласних артефактів:
# prompts/android-card-component.yml
# Version: 2.3.0
metadata:
name: "Card Component Generator"
platform: "Android"
framework: "Jetpack Compose"
template:
intent:
task: "Generate {{COMPONENT_TYPE}} card"
success: ["Stateless", "Material 3", "Callbacks"]
constraints:
architecture: ["NO remember", "State hoisting"]
security: ["Pre-masked data", "NO logging"]
ui: ["4.dp elevation", "48.dp touch targets"]
verification:
security_items: 7
architecture_items: 6
pass_rate_required: 100%
Організації, що застосовують цей спосіб мислення, створюють передбачувані системи штучного інтелекту, тоді як конкуренти борються з хаосом.
Заключні думки
Запити – це структуровані системи, що поєднують намір, контекст, обмеження, пам’ять та верифікацію. При правильній розробці вони стають детермінованими та готовими до використання.
У розробці фінансових додатків архітектурні запити означають різницю між кодом, який потребує рефакторингу, та перевіркою коду під час першого надсилання. Без належних обмежень ви отримуєте компоненти, що використовують remember{ } для стану, жорстко кодовані тестові дані або проблеми з доступністю. Завдяки багаторівневій архітектурі ви отримуєте компоненти без урахування стану, безпечні, повторно використовувані компоненти, які бездоганно інтегруються.
Оскільки ШІ стає фундаментальною інфраструктурою, архітектура запитів виявиться такою ж важливою, як і дизайн API або схема бази даних. Інженери, які рано зрозуміють цей зсув, визначатимуть практики розробки наступного покоління. Питання не в тому, чи застосовує ваша організація принципи архітектури запитів, а в тому, чи робите ви це проактивно, чи після виявлення, що код, згенерований ШІ, порушує відповідність або призводить до збоїв у виробництві. Почніть ставитися до запитів як до програмних компонентів, якими вони є.