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

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

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

Почнете со значењето, а не со изборот на модел

Пред да додадете embeddings, крајни точки за разговор или слој за оркестрација, идентификувајте ги деловните концепти што системот мора да ги претставува. „Клиент“ звучи едноставно сè додека една табела содржи контакти за наплата, друга содржи корисници на производот, а трета чува анонимни потенцијални клиенти. Ако тоа се различни концепти, шемата и API-то треба јасно да го кажат тоа.

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

Корисна вежба при дизајнирање е да се дефинира канонска претстава за секој концепт што преминува граница меѓу услуги. Тоа не бара одеднаш да се замени секоја застарена табела. Бара да се одлучи што значи апликацијата кога вели account, document, conversation или permission.

Рефакторирајте за стабилни односи

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

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

CREATE TABLE knowledge_documents (
    id BIGINT PRIMARY KEY,
    account_id BIGINT NOT NULL,
    title VARCHAR(255) NOT NULL,
    body TEXT NOT NULL,
    language_code VARCHAR(16) NOT NULL,
    published_at TIMESTAMP NULL,
    FOREIGN KEY (account_id) REFERENCES accounts(id)
);

Вредноста не е само во референтниот интегритет. Шемата сега поддржува правило за пребарување како: врати објавени англиски документи за дадена сметка. Тоа правило е разбирливо во SQL, спроводливо во API и може да се тестира без да се вклучи ВИ-провајдер.

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

Одделете ги оперативните податоци од претставите подготвени за ВИ

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

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

CREATE TABLE document_chunks (
    id BIGINT PRIMARY KEY,
    document_id BIGINT NOT NULL,
    chunk_index INT NOT NULL,
    content TEXT NOT NULL,
    content_hash CHAR(64) NOT NULL,
    indexed_at TIMESTAMP NULL,
    FOREIGN KEY (document_id) REFERENCES knowledge_documents(id),
    UNIQUE (document_id, chunk_index)
);

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

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

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

Побезбедниот образец е прошири, мигрирај, префрли и стесни:

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

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

Држете ги API-договорите пред деталите за складирање

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

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

$documents = $repository->findPublishedForAccount(
    accountId: $accountId,
    language: $language
);

$context = array_map(
    fn ($document) => [
        'id' => $document->id(),
        'title' => $document->title(),
        'body' => $document->body(),
    ],
    $documents
);

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

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

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

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

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

Шемата е одлука за производот

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

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