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

Затоа системската архитектура е толку важна. Моделот можеби е највидливиот дел од производ со ВИ, но дизајнот на заднинскиот систем одредува дали неговото привидно разбирање ќе стане корисно, повторливо однесување. Практичната цел не е уште првиот ден да се изгради разработена „ВИ платформа“. Целта е да се создаде систем што може да носи добри одлуки под вообичаен оперативен притисок.

Разбирањето започнува со контекст

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

Започнете така што ќе го третирате контекстот како податоци со животен циклус. Од каде потекнува? Кој може да му пристапи? Колку е ажурен? Може ли да се цитира или проследи? Што се случува кога не е достапен? Корисниот одговор од ВИ треба да биде поврзан со овие прашања, наместо составен од неограничен куп документи.

Практичниот пат на барање може да изгледа вака:

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

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

Држете го моделот зад стабилна граница на апликацијата

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

interface AnswerGenerator
{
    public function generate(AnswerRequest $request): AnswerResult;
}

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

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

Користете структуриран излез таму каде што софтверот мора да дејствува

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

$data = json_decode($responseBody, true, 512, JSON_THROW_ON_ERROR);

if (!isset($data['category']) || !in_array($data['category'], $allowedCategories, true)) {
    throw new UnexpectedValueException('Invalid classification result.');
}

Потврдата сè уште е неопходна дури и ако потсетникот бара JSON. Одговорот од моделот е надворешен влез. Третирајте го со истата претпазливост што би ја примениле за webhook или поднесување формулар.

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

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

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

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

Едноставна шема на сандаче за појдовни пораки може да помогне. Потврдете ја промената на канонскиот документ и настанот „индексирај го овој документ“ во истата трансакција на базата на податоци. Работникот подоцна го обработува настанот. Така се избегнува преправањето дека два независни системи секогаш може да се ажурираат атомски.

Направете ја бавната работа асинхрона

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

За работен тек на внесување документи, зачувајте почетен статус како pending, ставете задача во редица, а потоа оставете работникот да извлече текст, да создаде пребарливи претставувања и да го означи записот како ready само откако сите потребни чекори ќе успеат. Ако работникот не успее на половина пат, повторувањето треба безбедно да продолжи или да ги замени нецелосните изведени податоци.

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

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

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

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

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

Оптимизирајте ја целата патека, а не најмодерната компонента

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

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

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