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

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

Чувајте ги фактите одвоени од интерпретациите

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

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

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

CREATE TABLE documents (
    id BIGINT PRIMARY KEY,
    body TEXT NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE document_classifications (
    id BIGINT PRIMARY KEY,
    document_id BIGINT NOT NULL,
    label VARCHAR(100) NOT NULL,
    confidence DECIMAL(5,4),
    model_identifier VARCHAR(255) NOT NULL,
    prompt_version VARCHAR(100) NOT NULL,
    source_updated_at TIMESTAMP NOT NULL,
    created_at TIMESTAMP NOT NULL,
    FOREIGN KEY (document_id) REFERENCES documents(id)
);

Оваа структура овозможува лесно да се одговори на едно важно прашање: „Која верзија на документот ја опишуваше овој резултат?“ Таа исто така дозволува повеќе класификации да коегзистираат додека тимот оценува нов пристап.

Дизајнирајте за потекло, не само за излез

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

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

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

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

Третирајте ја ВИ-работата како асинхрона работа

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

Наместо тоа, прво потврдете ја деловната трансакција и ставете во редица задача што се повикува на потврдениот запис. Работникот ја презема тековната состојба на изворот, ја извршува работата и го запишува изведениот резултат. Поле за статус како pending, processing, completed или failed ѝ дава видлив животен циклус и на апликацијата и на операторите.

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

Користете outbox кога конзистентноста е важна

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

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

Изберете архитектура за пребарување според прашањето

ВИ-пребарувањето често се воведува како „додај вгнездувања“, но дизајнот на пребарувањето започнува со поедноставно прашање: што треба корисниците да можат да најдат?

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

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

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

Направете ги промените на шемата повратни и видливи

ВИ-интеграцијата брзо еволуира бидејќи барањата за производот брзо еволуираат. Миграција што трајно заменува поле уредувано од човек со генериран текст создава непотребен ризик. Адитивните промени обично се побезбедни: нови табели, nullable колони за време на преодот и периоди на двојно читање или двојно запишување кога е потребно.

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

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

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

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

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

Целта не е базата на податоци да стане „ВИ-изворна“. Целта е таа да биде отпорна кога ВИ ќе се промени — а ќе се промени — додека бизнисот сè уште има потреба неговите податоци да бидат точни, објасниви и достапни.