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

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

За многу бекенд производи, токму тука се наоѓа трајната вредност.

Моделот не е вашата апликација

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

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

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

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

Што навистина прави наставникот за вештачка интелигенција

Замислете го наставникот како контролиран слој за контекст и алатки меѓу корисниците, вашите системи и моделот. Неговата работа не е да ги прави потсетниците подолги. Неговата работа е да го состави најмалиот доверлив пакет од инструкции, докази и способности за конкретна задача.

Презема докази, а не само текст

Преземањето често се опишува како „пребарување документи“, но корисното преземање почнува со сопственоста на податоците. На асистентот за поддршка може да му требаат одобрени статии за помош, конфигурација на производот и статус специфичен за сметката. На асистентот за програмирање може да му требаат конвенции на складиштето и тесен сет релевантни датотеки. Финансискиот работен тек може да бара записи од главниот систем на евиденција, а не застарен извезен документ.

Секоја преземена ставка треба да носи метаподатоци како закупец, опсег на пристап, извор, ревизија и временска ознака. На моделот му е потребна содржина; на вашата апликација ѝ треба доволно контекст за да одлучи дали таа содржина имала право да се појави.

Ги кодира оперативните правила

Инструкциите треба да ја објаснат задачата, границите, претпочитаниот формат на одговор и постапувањето со неизвесност. Тие не треба да се преправаат дека реченица во потсетникот е безбедносна граница.

На пример, ако корисникот може да побара поврат на средства, моделот може да ги собере недостасувачките детали и да го предложи следниот чекор. Апликацијата треба да одлучи дали корисникот е овластен, дали нарачката ги исполнува условите и дали дејството може да се изврши. Ставете ја детерминистичката политика во код или конфигурација каде што може да се тестира и прегледа.

Обезбедува тесно насочени алатки

Алатката треба да претставува конкретна способност, како пребарување на нарачка или составување тикет. Избегнувајте изложување општа крајна точка за пребарување на база на податоци или неограничен интерен HTTP-клиент. Тесно насочените алатки ја намалуваат случајната штета, ја поедноставуваат авторизацијата и ги прават неуспесите полесни за дијагностицирање.

final class OrderLookup
{
    public function findForCustomer(string $orderId, int $customerId): array
    {
        // Enforce tenant and customer scope in the query itself.
        // Return only fields needed for the assistant's task.
        return [];
    }
}

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

Изградете ја наставната јамка како и секој друг продукциски работен тек

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

1. Автентицирајте го барањето и утврдете закупец, корисник и улога.
2. Класифицирајте ја побараната задача и изберете дозволен работен тек.
3. Преземете докази со соодветен опсег од авторитативни извори.
4. Составете инструкции и структурирани влезови за тој работен тек.
5. Повикајте го моделот со временски ограничувања, ограничувања за повторни обиди и јасна резервна опција.
6. Валидирајте ја вратената структура и спроведете политика пред несаканите ефекти.
7. Забележете ги релевантните влезови, повиците на алатки, излезите и одлуките за преглед.

Повторните обиди бараат воздржаност. Повторувањето неуспешно барање за генерирање текст може да биде разумно кога операцијата е идемпотентна. Повторувањето дејство што создава тикет, испраќа е-пошта или менува запис може да создаде дупликат несакани ефекти. Користете клучеви за идемпотентност и дозволете апликацијата, а не моделот, да го поседува конечното запишување.

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

Направете ја базата на податоци дел од дизајнот

Функциите за вештачка интелигенција може да создадат изненадувачки притисок врз податоците. Дневниците на разговори, преземените исечоци, трагите од алатки, случаите за евалуација и настаните со повратни информации имаат различни барања за задржување и пристап. Не ги ставајте во една неограничена табела само затоа што сите се „податоци за вештачка интелигенција“.

Дизајнирајте според прашањата што операторите ќе ги постават подоцна: Кој извор го информираше овој одговор? Која алатка ја произведе оваа вредност? Која верзија на потсетникот беше користена? Дали барањето не успеа затоа што преземањето не најде ништо, затоа што алатката го надмина временското ограничување или затоа што валидацијата на излезот го отфрли одговорот?

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

Евалуирајте го наставникот, не само прозата

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

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

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

Кога тренирањето може да биде вистинскиот избор

Тренирањето не е грешка; тоа е различна инвестиција. Може да биде соодветно кога имате стабилна, висококвалитетна збирка податоци и повторливо однесување што не може соодветно да се изрази преку примери, преземање или апликациска логика. Дури и тогаш, тренирањето не ја отстранува потребата од авторизација, свежи податоци, надзор и валидација на излезот.

Практичниот стандард е поедноставен: најпрво изградете силен наставник околу постоечки модел. Научете каде системот не успева. Подобрете ги границите на податоците, работните текови и евалуациите. Дури тогаш можете да утврдите дали преостанатиот проблем навистина се однесува на однесувањето на моделот.

Трајната предност е расудувањето кодирано во софтвер

Моделите ќе се менуваат. Со нив ќе се менуваат и добавувачите, цените и способностите. Трајниот дел од производот со вештачка интелигенција е слојот што знае кои факти се тековни, кои дејства се дозволени, како се постапува со неизвесноста и како се мери точноста.

Изградете го тој слој добро, и моделот станува заменлива компонента во доверлив систем. Тоа е покорисна амбиција отколку да научите модел сè: изградете го наставникот што му помага да ја донесе правилната одлука кога е важно.