От неврона до агента: какво научихме, когато се опитахме да говорим с машините

Всяка техника за работа с езиков модел е белег. Някой е опитал нещо, то се е провалило по специфичен и поучителен начин, а следващата техника е запис на този провал. Ако искате да разберете къде сме сега, с агенти, „сбруи“ и инженеринг на контекст, трябва да проследите белезите поред. Пропуснете един и останалите ще изглеждат като магия, а магията е лоша основа, върху която да градите компания.

Така че да започнем от самото дъно.

Невронът и проблемът да знаеш каквото и да било

Невронът в една невронна мрежа не е мистериозен. Той взема шепа числа, умножава всяко по тегло, събира ги и решава дали сборът е достатъчно голям, за да го предаде нататък. Това е всичко. Думата „неврон“ му прави незаслужен комплимент. По-скоро прилича на копче на смесителен пулт, а съвременният езиков модел е смесителен пулт с няколкостотин милиарда копчета.

Никой не настройва тези копчета на ръка. Показвате на пулта изречение със скрита последна дума, карате го да познае, измервате колко е сгрешил и побутвате всяко копче с частица от косъма в посоката, която би направила грешката по-малка. След това повтаряте това няколко трилиона пъти с голяма част от всичко, написано от хората. Копчетата се установяват в позиции, които правят предположенията добри.

Забележете какво означава това, защото цялата история се върти около него. Моделът не съдържа факти, както базата данни съдържа редове. Той съдържа настройки на копчетата, които правят определени продължения вероятни. Никой не е написал правило, което казва, че Париж е столицата на Франция. Копчетата са се озовали в позиция, в която „столицата на Франция е“ обикновено е последвано от „Париж“, защото това е било вярно в достатъчно много текстове. Това е знание в смисъла, в който утъпканата в пътеката бразда е знание. Пътеката знае откъде минават хората.

Attention: нищо не означава нищо само по себе си

Ранните версии на тези мрежи четяха текст така, както нервен човек чете договор – дума по дума, опитвайки се да задържи всичко предишно в ума си. До края на дългото изречение началото вече беше избледняло. Попитайте за темата на параграф и моделът щеше да отговори за това, което е видял последно.

Transformer, публикуван през 2017 г., изостави този подход. Вместо да се чете последователно, всяка дума получава възможност да погледне всяка друга дума в пасажа едновременно и да зададе един въпрос: колко си важна за мен в този момент? Думата „bank“ поглежда към „river“ и „money“ и придава голяма тежест на една от тях. Този механизъм се нарича attention и името е необичайно честно.

Има нещо почти философско в това и не мисля, че е случайно. Една дума не означава нищо сама по себе си. Тя означава нещо само във връзка с всичко около нея. Старите поети са го знаели. Transformer го превърна в аритметика.

Това, което Transformer не промени, е задачата. Задачата все още е, и единствено, да предвиди следващия токен. Всяка способност, която сте видели оттогава – есетата и работещият код – е просто проявление на тази една задача, когато е изпълнена изключително добре върху огромен обем текст. Моделът не знае. Той предвижда. Запомнете тази разлика, защото всяка следваща техника е опит да се извлече нещо надеждно от нещо, което само гадае.

Prompting: първият път, когато попитахме както трябва

Щом моделите станаха достатъчно добри, за да бъдат полезни, първият провал се появи веднага. Моделът можеше да допълва текст прекрасно, но пак да не прави това, което искате. Поискахте резюме, а получихте продължение. Зададохте въпрос, а получихте още три въпроса в същия стил.

Prompting беше отговорът и всяка негова версия е същият ход в различен костюм. Подреждате текста пред модела така, че най-вероятното продължение да е полезното.

„Zero-shot“ prompt просто задава задачата и се доверява, че моделът е виждал достатъчно подобни задачи. „Few-shot“ prompt поставя два или три решени примера над вашето искане, така че моделът да вижда шаблона и да трябва да се постарае, за да не го последва. Инструкциите за роля („вие сте старши данъчен счетоводител“) променят в коя част от утъпканата бразда се намества моделът. А „chain of thought“, най-интересният от тях, просто кара модела да изложи разсъжденията си, преди да отговори. Това работи, защото модел, който е написал „първо трябва да проверя датите“, е променил собствения си контекст и следващото предвиждане се прави от по-добра изходна позиция.

Една малка демонстрация, защото тук хората или го разбират, или не. Попитайте модела: „Рискова ли е тази клауза от договора?“ и поставете клаузата. Ще получите правдоподобен параграф. Сега напишете: „Вие преглеждате договор с доставчик за малка производствена компания. Прочетете клаузата по-долу. Избройте всяко задължение, което тя създава за купувача, след което кажете кои от тях биха били необичайни в стандартно споразумение за доставка и защо. Посочете точните думи, които създават риска.“ Същият модел, същата клауза. Вторият отговор си струва да се прочете, а първият – не, като разликата е изцяло в това как сте подготвили сцената.

Prompting ни научи на нещо неудобно: качеството на отговора е предимно свойство на въпроса. Това важи и за хората, поради което никой не обича да го чува.

Retrieval: моделът не знае, затова вие трябва да му кажете

Вторият провал беше по-лош от първия, защото беше невидим. Модел, обучен с текст до определена дата, не знае нищо след нея и не знае, че не знае. Попитайте го за резултатите от последното тримесечие и той ще генерира уверен, добре оформен отговор с числа в него. Числата са измислица. Хората наричат това „халюцинация“ и аз не харесвам термина, защото предполага неизправност. Това е системата, която прави точно това, за което е създадена – да генерира правдоподобен текст – в ситуация, в която правдоподобно и вярно са се разминали.

Решението е retrieval. Преди да попитате модела каквото и да било, идете и намерете съответните документи сами и ги поставете пред него заедно с въпроса. Сега най-вероятното продължение е стъпило на нещо реално. Техниката се нарича RAG (retrieval-augmented generation) и е причината моделът да може да отговаря на въпроси за вътрешните политики на вашата компания, без изобщо да е бил обучаван с тях.

Механизмът зад всичко това заслужава един параграф. За да намерите „релевантни“ документи, ви е нужен начин да сравнявате смисъл, а не да съпоставяте думи. Embeddings правят това. Един embedding превръща част от текст в дълъг списък с числа, а текстове с подобен смисъл получават подобни списъци. Мислете за това като за присвояване на координати на всяко изречение в пространство, където разстоянието е смисъл. Въпрос за „отпуск на служители“ се озовава близо до документ за политиката за „право на отпуск“, въпреки че не споделят нито една дума.

Retrieval премести проблема, вместо да го реши. Сега моделът беше добър само толкова, колкото това, което му подадете, а подаването на правилното нещо се оказа цяла дисциплина. Този проблем се завръща накрая.

Инструменти: разликата между описване и правене

Третият провал е този, който разделя чатбота от всичко, което дойде след него. Моделът можеше да говори за действия, но не и да ги извършва. Помолете го да провери календар и той ще генерира текст, който изглежда като проверка на календар. Думите за правене не са правене.

Използването на инструменти, или „function calling“, затваря тази празнина с трик, който е почти смущаващо прост. Казвате на модела кои функции съществуват, в структуриран формат. Когато моделът реши, че е нужна някоя, той не пише проза. Той пише структурирана заявка: извикай тази функция с тези аргументи. Вашият код прихваща това, изпълнява реалната функция и връща резултата обратно в контекста. След това моделът продължава, сякаш сам е извършил действието.

Моделът никога не докосва календара. Той създава описание на действието, толкова прецизно, че програма може да го изпълни. Това е целият мост между езика и света и си струва да сме наясно колко е тънък. Модел, който може да извика функция за търсене и заявка към база данни, не е по-интелигентен от такъв, който не може. Той е по-свързан. Интелигентността е същата. Обхватът е различен.

MCP, който се превърна в общия протокол за описване на тези инструменти, съществува, за да може обхватът да бъде стандартизиран. Всеки може да предостави инструмент, на всеки модел може да се каже за него и двамата не е нужно да са се срещали преди.

Агенти и цикли: когато една стъпка не е достатъчна

Щом моделът може да действа, четвъртият провал пристига по график. Истинските задачи не се състоят от една стъпка. „Разбери защо билдът се проваля и го поправи“ е поредица от проверки и решения, всяко от които зависи от предишното. Един-единствен prompt, колкото и добре да е конструиран, не може да направи това.

Агентът е модел, поставен в цикъл. Наблюдавай ситуацията. Реши какво действие да предприемеш. Извърши го. Виж какво се е случило. Реши отново. Най-простата публикувана форма на това се нарича ReAct (от reason и act) и цялото ѝ съдържание е, че моделът редува писане на мисъл и избор на инструмент, докато не прецени, че задачата е изпълнена.

По-голямата част от настоящия ентусиазъм около AI е ентусиазъм за този цикъл и той заслужава част от него. Да гледаш как един такъв решава проблем за първи път е истински шок.

Повечето от това, което четете за агенти, пропуска аритметиката. Всяка стъпка в цикъла е предвиждане, а предвижданията не са перфектни. Да приемем, че всяка стъпка е правилна в 95 процента от случаите, което е щедро. След десет стъпки шансът нищо да не се е объркало е около 60 процента. След двадесет – около 36. Грешките не се неутрализират взаимно. Те се натрупват, защото грешно наблюдение на четвърта стъпка води до уверено грешно решение на пета, а моделът няма как да знае, че земята под краката му се е разместила.

Този факт организира областта през последните две години. Въпросът престана да бъде как да направим агентите по-умни и се превърна в това как да спрем верига от предположения да се изроди в безсмислица. Това е различен проблем и той има различен вид отговор.

„Сбруята“: това, което обгражда модела, има по-голямо значение от самия модел

Петият провал е този, който никой не искаше да признае. Един-единствен агент в цикъл, оставен сам, не е достатъчно надежден, за да му се повери нещо важно. И отговорът, когато най-накрая дойде, не беше по-добър модел. Беше всичко, изградено около модела.

Тази обграждаща структура е „сбруята“. Думата е добре подбрана. Сбруята не прави коня по-силен. Тя прави силата на коня използваема и държи каруцата на пътя.

„Сбруята“ включва предпазните механизми, които проверяват предложеното от агента действие, преди то да се изпълни, и отхвърлят тези извън определена граница. Тя включва верификация, при която второ преминаване (често втори модел, понякога обикновен скрипт) проверява резултата от първия спрямо първоначалната заявка. Тя включва логика за повторен опит, която улавя неуспешно извикване на инструмент и опитва отново с различни аргументи, вместо да продължи с боклук. Тя включва контролните точки, където агентът спира и чака човек, преди да извърши нещо необратимо. И тя включва маршрутизиране: решаване кой модел, с кои инструменти, да получи коя част от работата.

Тази последна част прерасна в многоагентни системи. Вместо един агент да прави всичко, имате един, който планира, няколко, които изпълняват тясно специализирани подзадачи, и един, който преглежда. Всеки има малка задача и малък контекст, което поддържа нисък процента на грешки на всяка стъпка, а това е единственото, което има значение, когато стъпките се умножават.

Стойността се е преместила. Преди две години въпросът беше до кой модел имате достъп. Днес моделите са достатъчно близки един до друг, така че „сбруята“ решава дали нещото работи. Инженерната дисциплина, от онзи стар, немодерен вид с тестове, контролни точки и писмен списък на начините, по които може да се провали, е това, което разделя демото от продукта. Хората, които пропуснаха тази стъпка, защото „AI ще се справи“, са тези, които сега обясняват на клиентите си защо не се е справил.

Инженеринг на контекст: prompt-ът порасна

Prompting се отнасяше за едно-единствено съобщение. Изработвахте един текстов блок и го изпращахте. Инженерингът на контекст се отнася за целия прозорец, който моделът вижда в момента на всяко предвиждане, в рамките на задача, която може да включва стотици предвиждания. Какви документи има вътре? Какви резултати от инструменти? Какво резюме на последните четиридесет стъпки? Какво е било изхвърлено, за да се освободи място?

Прозорецът е ограничен. Моделът чете фиксиран брой токени и една дълга агентна задача изчерпва този бюджет бързо. Всеки резултат от инструмент, всяка междинна мисъл, всеки извлечен документ се намира в контекста и се бори за вниманието на модела. Attention, спомнете си, е механизмът от Transformer: всеки токен претегля всеки друг. Напълнете прозореца с шум и сигналът ще бъде заглушен от него. Моделът не става по-глупав. Той се разсейва, в най-буквалния смисъл на думата.

Така че инженерингът на контекст е дисциплината да решаваш на всяка стъпка какво трябва да гледа моделът. Кои от последните двадесет резултата от инструменти все още са от значение. Кога да се компресира дълга история в кратко резюме и да се приеме загубата. Кои извлечени пасажи да се включат и кои да се премахнат. Какво да се съхранява в отделна памет извън прозореца и да се извиква обратно само при нужда. Това е куриране, лишено от блясък, и е разликата между агент, който завършва двучасова задача, и такъв, който губи нишката на четиридесетата минута.

Започнахме с проблема за подреждане на текст, така че следващото предвиждане да бъде полезно. Това беше prompting. Завършваме с проблема за подреждане на текст, така че следващото предвиждане да бъде полезно, само че сега подреждането се случва непрекъснато, програмно, в рамките на дълга задача, захранвана от retrieval и памет. Това е същият проблем. Просто порасна и се сдоби с по-голяма къща.

Тежестта се прехвърли върху вас

В началото казах, че всяка техника е белег, и в тези белези има модел, който сочи нанякъде.

На всеки етап провалът беше един и същ. Моделът предвижда; той не знае. И на всеки етап решението беше да се отнеме отговорността от модела и да се прехвърли върху човека, който го управлява. Prompting превърна въпроса във ваша работа. Retrieval превърна фактите във ваша работа. Инструментите превърнаха връзката със света във ваша работа. „Сбруята“ превърна надеждността във ваша работа. Инженерингът на контекст превърна цялото зрително поле на модела във ваша работа.

Инструментът стана по-способен и като пряк резултат се изискваше повече от този, който го държи. Това е, което способните инструменти винаги са правели. Скалпелът изисква повече от хирурга, отколкото нож за масло, а хирург, който мисли, че скалпелът върши работата, е хирург, когото искате да избегнете.

Моделите ще продължат да стават все по-способни. Следващият ще направи част от днешната „сбруя“ ненужна, а друга част – по-важна, и няма да знаете коя предварително. Това, което няма да се промени, е къде се намира отговорността. Резултатът е ваш. Преценката дали е достатъчно добър е ваша. Решението какво вижда машината и до какво ѝ е позволено да се докосва е ваше. Хората, които ще се справят добре през следващите пет години, са тези, които разбират това и се отнасят сериозно към него. Тези, които ще се провалят, все още чакат моделът да свали тежестта от плещите им.

Няма. Това е целият урок и бяха нужни много провали, за да го научим.