ИТ развој

Beyond the Prompt: Building Your Backend's AI Intelligence Core

Надвор од промптот: Градење на јадрото на AI интелигенцијата на вашиот бекенд

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

Корисниот ментален модел е едноставен: моделот е зависност. Јадрото за ВИ интелигенција на вашиот бекенд е системот што ја прави таа зависност безбедна, повторлива и вредна.

Нека апликацијата го поседува работниот тек

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

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

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

Важен е договорот, а не прозниот промпт. Предвидливиот излез му дава на остатокот од системот нешто што може да го валидира, складира, прикаже и ревидира.

Поставете ВИ-граница зад интерфејс

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

interface TicketTriageService
{
    public function analyze(Ticket $ticket): TicketTriage;
}

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

Оваа граница спречува и чест проблем со одржливоста: промптовите да станат невидлива деловна логика. Чувајте ги шаблоните за промптови верзионирани покрај кодот што го користи нивниот излез. Дајте му на секој шаблон стабилен идентификатор, како ticket-triage-v3, и зачувајте го тој идентификатор со секој резултат.

Валидирајте го секој одговор од моделот

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

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

$category = TicketCategory::tryFrom($data['category'] ?? '');
$urgency = TicketUrgency::tryFrom($data['urgency'] ?? '');

if ($category === null || $urgency === null) {
    throw new InvalidAiResponse('Unsupported triage values.');
}

return new TicketTriage(
    category: $category,
    urgency: $urgency,
    suggestedNextStep: mb_substr((string) ($data['next_step'] ?? ''), 0, 500),
);

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

Дизајнирајте за асинхрона работа и несовршени зависности

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

Типичен тек е:

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

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

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

Складирајте доволно состојба за да го објасните системот

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

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

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

Користете го извлекувањето како податочен производ, а не како трик со промпт

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

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

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

Испорачувајте со заштитни мерки и пат за враќање

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

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

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

Портрет на автор на блогот

Mihajlo

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