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

Токму во заднината таа разлика станува реална. Таа ја претвора импресивната интеракција со јазичен модел во систем за учење со меморија, ограничувања, набљудливост и кохерентен пат од „Го прочитав ова“ до „Можам да го направам ова“.

Почнете со циклусот на учење, а не со моделот

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

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

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

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

Направете API да одразува значајни граници

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

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

final class SubmitAttemptAction
{
    public function __invoke(SubmitAttemptRequest $request): AttemptResponse
    {
        $attempt = $this->attemptService->record(
            learnerId: $request->authenticatedUserId(),
            activityId: $request->activityId(),
            answer: $request->answer(),
            idempotencyKey: $request->idempotencyKey(),
        );

        $this->evaluationQueue->enqueue($attempt->id());

        return AttemptResponse::accepted($attempt->id());
    }
}

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

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

Користете ВИ како ограничена услуга

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

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

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

• Чувајте ги промптовите со верзии заедно со кодот на апликацијата или во контролиран конфигурациски систем.
• Чувајте ја верзијата на промптот и политиката за оценување што се користат за секој изведен резултат.
• Ограничете го контекстот на материјал што е релевантен и овластен за тој ученик.
• Поставете експлицитни истеци на време, ограничувања за повторни обиди и патека за неуспешни задачи во dead-letter ред.
• Понудете корисна резервна опција, како детерминистичка порака според критериумите за оценување или барање да се обиде повторно подоцна.

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

Дизајнирајте го моделот на податоци за ревизија

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

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

Користете трансакции за промени на состојба што мора да се усогласени. Евидентирањето обид и објавувањето задача за оценување не треба да го остават системот во состојба каде што едното успева без другото. Шаблонот transactional outbox е прагматичен одговор: запишете го обидот и записот во outbox во една трансакција, а потоа worker сигурно нека ја објави ставката од outbox.

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

Одржувајте ја асинхроната работа набљудлива

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

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

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

Контејнеризирајте за повторливост, а не за формалност

Docker е најкорисен кога прави локалниот развој, тестирањето и распоредувањето да се однесуваат предвидливо. На PHP заднината најчесто ѝ треба веб-извршувачка околина, worker процес, база на податоци и можеби кеш. Одржувајте ја продукциската слика мала, фиксирајте ги верзиите на зависностите каде што е соодветно и извршувајте миграции како контролиран чекор при распоредување, наместо како случаен несакан ефект при секое стартување на контејнер.

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

Архитектурата треба да ја заслужи довербата на ученикот

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

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