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

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

Почнете од системот на евиденција

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

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

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

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

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

Потеклото на моделот како првокласна грижа

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

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

CREATE TABLE document_derivatives (
    id BIGINT PRIMARY KEY,
    document_id BIGINT NOT NULL,
    document_version INT NOT NULL,
    derivative_type VARCHAR(50) NOT NULL,
    content TEXT NOT NULL,
    model_identifier VARCHAR(255) NOT NULL,
    prompt_version VARCHAR(100) NOT NULL,
    status VARCHAR(30) NOT NULL,
    created_at TIMESTAMP NOT NULL,
    UNIQUE (document_id, document_version, derivative_type)
);

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

Дизајнирајте го пребарувањето околу значењето и дозволите

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

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

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

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

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

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

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

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

Преместете ја бавната работа со вештачка интелигенција надвор од циклусот на барањето

Вградувањето на документ, обработката на прикачена датотека или генерирањето долго резиме ретко е соодветно за синхроно веб-барање. Мрежната латентност, ограничувањата на давателот, минливите неуспеси и променливото време на обработка во спротивно ќе го претворат нормалниот сообраќај на апликацијата во кревок синџир на зависности.

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

На пример, ажурирањето на документ може да означи постари изведени записи како застарени и да стави во ред задача со клуч составен од document_id плус document_version. Пред да го зачува резултатот, работникот проверува дали сè уште ја обработува тековната верзија. Ако пристигнала понова измена додека работел, тој го отфрла застарениот излез или соодветно го означува.

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

Планирајте за трошоци, латентност и повторна обработка

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

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

Направете ја евалуацијата дел од моделот на податоци

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

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

Целта не е да се докаже дека системот е интелигентен. Целта е регресиите да станат видливи пред корисниците да ги откријат.

Трајната предност е доверлив контекст

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

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