Случвало ли ви се е дадена подкана да работи добре, а после внезапно да спре?
Попадали ли сте в цикъл на непрекъснато коригиране на системната подкана в опит да подобрите резултатите, но без успех?
Обучението на системни подкани може да е точно това, от което се нуждаете.
Обучението на системни подкани (SPL) е нова област, която привлича интереса на общността в сферата на ИИ и през май беше широко популяризирана от Андрей Карпати в X.
Обучението на системни подкани преодолява ограниченията на негъвкавите и неустойчиви системи с ИИ, които разчитат на статични системни подкани или тромави процедури за фина настройка. То предлага друг начин за непрекъснато обучение на системите с ИИ.
Преди да навлезем в темата, нека накратко преговорим основите на създаването на подкани.
Когато разработваме Агент или персонализиран модел, първо трябва да проектираме два основни компонента:
Системна подкана
Потребителска подкана
Системните подкани определят основните правила за поведението на модела. Когато са предназначени за персонализирани решения с ИИ, те често започват така:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
За разлика от тях, потребителските подкани обикновено съдържат заявката на потребителя и друга уместна информация, например часовата му зона и предпочитанията му. Една потребителска подкана може да изглежда така:
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
Изтичането на системни подкани стана обичайно след пускането на нови модели от водещи лаборатории за ИИ, тъй като потребителите прилагат джейлбрейк на чатботове, за да разкрият основните им инструкции. Популярно хранилище в GitHub вече събира много от тези системни подкани на едно място. Те разкриват „тайната съставка“, която лабораториите за ИИ са разработили с времето, за да насърчават подходящо поведение на моделите. Например наскоро изтеклата системна подкана на GPT-5 (разкрита в ChatGPT) съдържа около 6000 думи. Това показва колко знания и насоки трябва да бъдат кодирани, за да се оформи поведението на системата.
Тези подробни системни подкани обикновено обхващат няколко основни области, като:
Инструкции за търсене
Дефиниции на инструменти
Потребителски предпочитания
Инструкции за цитиране
Бързи корекции за известни проблеми
На практика разработчиците на персонализирани системи с ИИ ръчно коригират системните подкани на последователни етапи, докато тестват и усъвършенстват приложенията си, като използват предимно оценки, за да направляват подобренията.
Други начини за насочване на поведението на модела са:
Бърз инженеринг, включително генериране с подпомагане чрез извличане (RAG), което контролира съдържанието, предоставяно на модела
Фина настройка (директна промяна на базовите тегла на модела)
Ами ако имаше и друг начин да влияем върху поведението на модела? Представете си система, която динамично се учи и усъвършенства собствената си системна подкана чрез генерирани по-рано разсъждения, планове и стратегии. Тя би могла да използва както обратна връзка от потребители, така и оценки от LLM като съдия, за да преценява резултатите си.
Помислете за траен бизнес проблем, който искате да автоматизирате чрез система от агенти. Ефективните решения изискват способности за структурирано анализиране отвъд обикновената автоматизация на работни процеси. В такива случаи е от съществено значение да включите в системата си с ИИ компонент за генериране на планове. Това позволява на системата да работи по различни начини с множество агенти в зависимост от задачата. Отделните стъпки може да включват инструкции за достъп до други агенти с цел изпълнение на подзадачи или за използване на инструменти.
Забележка: Инструментът на Агента е всяка външна функция, API или ресурс, който Агент с ИИ може да извика, за да излезе отвъд текста и да предприеме реални действия.
Може да решите да „заложите“ в системната подкана на модела план, който следва логичните стъпки на човек. Големите езикови модели обаче обикновено се нуждаят от по-конкретни насоки за използване на инструменти, форматиране на резултатите и свързани изисквания. Понякога оптималната стратегия може да не е ясна или да работите по проблем, който не е преоценяван, защото преди е бил смятан за решен. Тук се намесва обучението на системни подкани (SPL).
SPL подобрява системната подкана на последователни етапи, като включва генерирани по-рано стратегии. С възникването на нови проблеми системата постепенно натрупва знания и става по-устойчива. Представете си го като създаване на наръчник за решаване на проблеми във вашата област.
SPL постепенно включва в системната подкана изводи от обратната връзка на потребителите. С развитието на системата може да откриете повтарящи се проблеми, които да обобщите в по-универсални принципи от по-високо ниво.
Нека разгледаме по-подробно как протича процесът, стъпка по стъпка:
Започнете с потребителската заявка, която възлага на системата конкретна задача.
Ако системата ви решава само един проблем, може да приложите „алчен“ подход, като изберете стратегиите с най-високи оценки от предишни изпълнения. Можете също да насърчите проучването, като формирате извадка от разпределение, което предпочита високо оценени стратегии, но понякога включва и по-ниско оценени. Това е особено полезно, когато тепърва започвате да събирате стратегии.
За системи, проектирани да решават разнообразни групи проблеми, обмислете добавянето на слой за класификация или използването на векторни представяния и косинусово сходство — същите техники, които обикновено се използват в RAG — за откриване на подходящи решения. Това ви помага да изберете стратегии, подходящи за конкретния проблем — например стратегии за задачи по програмиране.
Забележка: Векторните представяния, използвани с косинусово сходство, позволяват да измерим колко тясно са свързани два информационни фрагмента. Така по-лесно съпоставяме документи, заявки или идеи дори когато точната им формулировка се различава.
Примерна отправна точка за опростено хранилище на стратегии за решаване на задачи по програмиране.
Забележка: Показаните тук „начални стратегии“ са само илюстративни. В реални сценарии за програмиране бихме ги усъвършенствали допълнително. Специфичните бизнес проблеми биха изисквали събиране на допълнителни знания с времето.
Generation_id (обратен ред) | Тема | Оценка | Strategy_text | Обяснение |
|---|---|---|---|---|
4 | програмиране | 1 | Разберете проблема, ограниченията и граничните случаи. Проектирайте алгоритъм с подходящите структури от данни. Проверете плана чрез примери и инварианти. Реализирайте чист и четим код. Усъвършенствайте го чрез рефакториране, оптимизация и окончателно форматиране. Използване на инструменти: Когато използвате инструмент, обяснете накратко защо е бил необходим. | Включва и съчетава най-силните елементи от трите стратегии по-долу. |
3 | програмиране | 1 | Разберете проблема, ограниченията и граничните случаи. Проектирайте алгоритъм с подходящите структури от данни. Проверете плана чрез примери и инварианти. Реализирайте чист и четим код. Усъвършенствайте го чрез рефакториране, оптимизация и окончателно форматиране. | По-цялостна стратегия, но без насоки за използването на инструменти. |
2 | програмиране | -1 | Разберете проблема, ограниченията и граничните случаи. Проектирайте алгоритъм с подходящите данни. Реализирайте чист и четим код. Използване на инструменти: при достъп до инструменти обобщете накратко защо сте използвали съответния инструмент. | По-добра стратегия, която споменава използването на инструменти, но все още може да се подобри. |
1 | програмиране | -1 | Прегледайте набързо проблема. Решете проблема. Създайте минимални тестове. Предайте каквото успее да се изпълни. | Споменава тестове, но като цяло е слаба стратегия. |
3. След като формирате извадка от N, включете стратегиите в системната подкана. Така генерирането на планове се основава на предишна експертна обратна връзка, вместо моделът да създава планове с минимални насоки. Насърчете модела да „мисли нестандартно“ и при нужда да добавя стъпки, вместо просто да копира дословно примерните стратегии.
4. Използвайте динамично създадената системна подкана, за да генерирате нова стратегия за заявката на потребителя. Този процес трябва да създаде допълнителни задачи, които подобряват крайния резултат. Целта е творчески подход: съчетайте най-силните елементи от предишните стратегии, обединете припокриващите се стъпки и добавете полезни нови стъпки, където е необходимо.
Забележка: Не забравяйте, че температурата е параметър, който може да се настройва за получаване на по-разнообразни и по-малко детерминистични резултати — полезно при търсене на творчески решения. При температура, различна от нула, всеки генериран план може да е различен.
5. След като получите резултата от модела, оценете го чрез човек оценител или LLM съдия според конкретни критерии, определящи доброто решение на проблема ви. За споменатия по-рано пример с дейности в Португалия критериите за оценка може да включват:
Краткост (отговор, ограничен до едно изречение)
Уместност на предложената дейност
Точност на местоположението
6. Въз основа на тази оценка използвайте друг модел, за да усъвършенствате стратегията. Незадължителен цикъл за обратна връзка може да включва човешки принос и да подпомага съвместните подобрения. Съхранете усъвършенстваната стратегия в базата си данни с подходящи метаданни за проследяване на версиите и промените.
Защо тогава да полагате всички тези усилия? Бихте могли ръчно да преглеждате резултатите и да коригирате системната подкана спрямо тях. Мощните модели за структурирано анализиране обаче могат да усъвършенстват стратегиите чрез контекста на резултатите и обратната връзка от хора. Хората лесно забелязват недостатъците на простите подходи, но откриването им става трудно и досадно при сложни системи, които решават по-широк кръг проблеми.
Големите езикови модели често се нуждаят от подробни инструкции и допълнителни стъпки, за да съберат контекстните знания, които хората естествено прилагат към даден проблем. Броят на необходимите задачи може да нарасне бързо, когато системата започне да обхваща по-широк кръг проблеми. Например хората, които решават задачи по програмиране, могат интуитивно да разбират свързаната кодова база, докато на един голям езиков модел може първо да му се наложи да „прочете“ множество файлове.
Кога помага: Представете си, че ръководите екип за обслужване на клиенти, а Агент с ИИ разпределя заявките. С времето SPL може да открие метод за категоризация, който екипът ви не е обмислял, и така да намали броя на ескалациите.
Кога не помага: Ако изискванията за съответствие или нормативните разпоредби вече определят работните ви процеси, например при финансово отчитане, SPL може да е с малка стойност, защото творческият подход се превръща в риск, а не в предимство.
Кога помага: В дейности с интензивни проучвания, като пазарно разузнаване или продуктова стратегия, можете да си сътрудничите с ИИ, като усъвършенствате плановете му, обогатявате резултатите и запазвате подобренията за бъдеща употреба. Всяко взаимодействие повишава ефективността на системата.
Кога не помага: Ако екипът ви използва ИИ предимно за ясни работни процеси с минимално човешко участие, например обработка на фактури, усилията за сътрудничество може да надхвърлят ползата.
Кога помага: Да предположим, че навлизате в нов регион и ИИ внезапно трябва да обработва запитвания за местните данъци. SPL ви позволява бързо да кодирате новите правила и евристики при възникването им и така да предотвратявате повтарящи се грешки.
Кога не помага: Ако средата ви е статична, например когато преобразувате стенограми от срещи в стандартизирани резюмета, постоянното адаптиране носи минимална полза.
На теория всичко това звучи обещаващо, но внедряването на SPL е свързано с реални предизвикателства. По-долу разглеждаме някои от основните:
В ранните етапи на генерирането на стратегии напредъкът често спира: новите резултати не надграждат предишните и темпото се забавя. Това обикновено се дължи на два основни проблема:
Решение: Кодирайте предварително всички налични бизнес знания, за да има системата солидна основа, от която да черпи.
Решение: Създайте подробна скала, която оценява различни аспекти на отговора, като точност, яснота и уместност, и настройте извадката си така, че да отразява тези сигнали.
Ако системата ви генерира стотици стратегии, но получава малко обратна връзка, за да различи добрите от лошите, извадката бързо става неуправляема. Решението е отсяване.
Когато усъвършенствате хранилището си за стратегии, вземете предвид:
Жизнен цикъл: Извеждайте стратегиите от употреба, след като надхвърлят определен период или брой поколения.
Оценка: Използвайте скалата си за оценяване, за да отсявате стратегиите с трайно слаби резултати. В съчетание с жизнения цикъл това гарантира, че запазвате само подходи, доказали стойността си с времето.
Оценяване от LLM: Периодично оценявайте стратегиите, за да откривате онези, които вече не добавят уникални идеи, тъй като полезните им елементи вероятно са включени в по-новите версии.
Решение: Третирайте базата си данни със стратегии като жива система: редовно я прочиствайте, така че да останат само уместни знания с висока стойност.
Обучението на системни подкани все още е в начален етап, но потенциалът му е огромен. Компаниите, които разчитат единствено на статични подкани или безкрайна фина настройка, ще се сблъскат с познати ограничения: неустойчиви системи, растящи разходи и пропилени усилия. SPL предлага изход от този цикъл чрез изграждане на системи, които се подобряват с времето и кодират принципи от по-високо ниво вместо отделни корекции.
SPL все още се развива, но посоката е ясна: системите, които могат да се учат сами, ще изпреварят онези, които не могат. Сега е моментът да експериментирате, да започнете с малки стъпки, да извличате поуки и да положите основите на системи с ИИ, които се подобряват с всяко взаимодействие.