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