AI као пророчиште: зашто је култура провере важнија од промптовања

О AI-ју се често говори као о алату, помоћнику, колеги или замени. Те метафоре нису нужно бескорисне, али инжењере често воде ка погрешној навици. Усмеравају их на делегирање, брзину одговора и осећај продуктивности, уместо на проверу исправности резултата.

Кориснији инжењерски ментални модел јесте пророчиште.

Поента те аналогије није мистика. Поента је оперативна дисциплина.

Шта је пророчиште

У теоријској рачунарској науци пророчиште је хипотетичка црна кутија која може да одговори на одређену класу питања без откривања начина на који је дошла до одговора.

У криптографији се тај израз користи практичније, за услуге налик пророчишту као што су оракли за шифровање или дешифровање. Позивалац може да пошаље улаз и посматра излаз, док унутрашњи механизам остаје скривен.

LLM није дословно формално пророчиште ни у једном од та два смисла. Није део доказног модела нити јасно омеђен криптографски примитив.

Али из инжењерске перспективе у пракси често делује као пророчиште:

• поставите питање
• добијете уверљив одговор
• унутрашњост система углавном је непрозирна
• одговор може бити користан, а да притом није поуздан

Та последња тачка најважнија је од свих.

Зашто је аналогија са пророчиштем боља

Модел пророчишта усмерава пажњу на права инжењерска питања.

Модел је непрозиран. Чак и када нешто знамо о подацима за тренирање, дохватању контекста, алатима или ширем дизајну система, обично немамо поуздано објашњење зашто се појавио баш одређени одговор.

Одговори могу бити вредни, али нису загарантовано тачни. Могу бити непотпуни, претерано самоуверени, осетљиви на контекст или суптилно погрешни, а такве грешке често откривамо тек касније.

То значи да излазе треба третирати као хипотезе, а не као чињенице.

То такође значи да провера није нешто што долази тек на крају. Провера је део самог радног процеса.

Ту је стварни културни помак. Проблем није у томе што инжењерима треба боља техника писања промптова. Проблем је у томе што многим тимовима и даље недостаје снажна култура провере у раду уз AI.

Култура провере, а не култура промптовања

Промптовање јесте важно, али није суштина проблема.

Уско и добро омеђено питање корисно је зато што олакшава проверу.

Преширок промпт опасан је зато што подстиче претерано поверење у одговор.

Ако тим интеракцију са AI-јем посматра првенствено као вештину промптовања, обично ће оптимизовати за:

• течне одговоре
• брзину
• самоуверен тон
• утисак потпуности

Ако пак тим рад са AI-јем посматра као коришћење пророчишта, обично ће оптимизовати за:

• јасна питања
• ограничен опсег
• изричите претпоставке
• независне провере
• забележено образложење одлука
• поновљиву валидацију

Тај други списак много је ближи стварној инжењерској дисциплини.

Како то изгледа у инжењерској пракси

Развој вођен спецификацијом

Развој вођен спецификацијом већ сам по себи полази од тога да брз излаз није исто што и исправан излаз. Писане спецификације одређују сврху, границе, токове рада и критеријуме прихватања пре него што се генерисани излаз прихвати као ваљана промена.

То је дисциплина пророчишта. Одговор мора да се провери према унапред одређеном стандарду.

AI-потпомогнут рад са знањем

Рад са знањем уз помоћ AI-ја постаје поузданији када око модела постоје трајни артефакти, изричит преглед и следљиви стандарди. Конверзацијски излаз сам по себи није стабилан извор истине.

Управљање документацијом

Добри инжењерски тимови одвајају спецификацију производа, имплементационе смернице, јавну документацију, мапе извора и генерисане артефакте. Та одвојеност је важна јер спречава да један уверљив одговор тихо постане прихваћена истина.

Валидатори и тестови

Тимови уводе валидаторе зато што су памћење и самоувереност слабе контроле. Провере линкова, структурне провере, провере паритета, генерисање метаподатака, тестови и валидатори објаве претварају проверу у инфраструктуру.

Очување контекста и образложења

Користан одговор пророчишта сам по себи још није довољан. Ако рад треба да преживи време и промене у тиму, видљиве морају остати претпоставке, докази, белешке прегледа и разлози за прихватање или одбацивање одговора.

Локализација и семантички паритет

Локализација је добар пример зашто је провера важна. Превод може звучати течно, а да ипак подбаци у модалности, терминологији, исправности Unicode записа, тексту за приступачност или семантичком паритету са изворником. У таквом процесу AI-излаз није објавна истина. То је нацрт који треба прегледати.

Конкретни примери

Модел пророчишта постаје јаснији када питања постану конкретна.

Када тражите од AI-ја да објасни код

LLM може брзо и смислено да објасни функцију, ток података или баг.

Шта треба проверити:

• одговара ли објашњење стварном путу кроз код
• да ли су изостављени рубни случајеви
• да ли је одговор помешао тренутно понашање са намераваним понашањем
• занемарује ли објашњење околне спецификације, тестове или коментаре

Користан начин провере:

• прочитајте наведени код
• упоредите одговор са постојећим тестовима
• проверите одговара ли објашњење документованом току рада

Када тражите од AI-ја да напише валидатор

LLM може да произведе валидатор који изгледа уредно и уверљиво.

Шта треба проверити:

• проверава ли валидатор стварно правило или само поједностављени приближак
• ствара ли правило лажан осећај сигурности
• да ли су пропуштени важни случајеви грешке
• описује ли валидатор документовано правило исправно

Користан начин провере:

• припремите позитивне и негативне тестне примере
• покрените валидатор над познатим неуспесима
• проверите штити ли заиста ону класу грешака која вас занима

Када тражите од AI-ја да преведе документацију

LLM може врло брзо да произведе углађен превод.

Шта треба проверити:

• семантички паритет са изворником
• терминолошку доследност
• исправност писма и Unicode записа
• ознаке приступачности и метаподатке
• остају ли примери, повезани линкови и пратећи материјали усклађени

Користан начин провере:

• покрените валидаторе локализације и паритета
• упоредите структуру одељака извора и циљног језика
• обезбедите преглед изворног говорника за важан садржај

Када тражите од AI-ја да предложи архитектуру

LLM може да предложи слојевиту архитектуру, раздвајање сервиса или интеграциони образац који звучи разумно.

Шта треба проверити:

• одговара ли предлог стварном опсегу производа
• поштује ли захтеве од којих не може да се одступи
• уводи ли непотребну сложеност
• претпоставља ли инфраструктуру, буџете или оперативну зрелост који не постоје

Користан начин провере:

• упоредите предлог са спецификацијом производа
• проверите га према границама опсега и критеријумима прихватања
• запишите компромисе пре усвајања

Како провера изгледа у пракси

Провера не значи увек формални доказ. У стварном инжењерском раду најчешће значи комбинацију више слабијих, али корисних провера.

• упоредите одговор са спецификацијом
• прегледајте релевантне датотеке
• покрените тестове
• покрените валидаторе
• проверите линкове и генерисане артефакте
• сачувајте белешке прегледа и образложења
• поставите уже накнадно питање када је први одговор преширок да би се чисто проверио

Зато култура провере дугорочно скалира боље од саме вештине промптовања. Она ствара поново употребљиве контролне тачке које надживљавају појединачне разговоре.

Практичан закључак

• Постављајте уска питања.
• Забележите претпоставке.
• Проверавајте тврдње.
• Користите тестове и валидаторе.
• Сачувајте образложење.
• AI-излаз третирајте као доказни материјал, а не као истину.

Закључак

AI није ни колега ни претраживач.

Ближи је пророчишту: црној кутији која може да одговори на изненађујуће тешка питања, под условом да питате пажљиво и проверите одговоре.

Изазов AI-потпомогнутог инжењерства није научити како користити пророчиште. Изазов је научити како му не веровати превише.

Повезано штиво

• ../../wiki/ai-assisted-knowledge-work.md
• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ../../wiki/documentation-traceability.md
• ../../wiki/localization-governance.md
• ../../wiki/let-books-localization-case-study.md
• ai-workflows-beyond-software.md
• spec-driven-development-for-ai-projects.md
• documentation-is-part-of-the-product.md