Моделите за решения преценяват. Не прогнозират.
Повечето разговори за AI са за модели, които пишат. Един по-нов вид не пише изобщо: подаваш му текст и тесен въпрос, а той връща отговор с прикрепена към него вероятност. За три дни възложихме на един такъв модел за решения три задачи. Той заслужи две от тях, а защо не заслужи третата, е полезната част.
От Ivaylo Tsvetkov, Co-Founder
Модел, който не пише
Моделът беше Jev на TypeSafe, достъпен през OpenRouter. Той отговаря на три вида въпроси: избери една от тези опции, постави това на скала или кажи дали дадено условие е изпълнено. Всеки отговор идва като структурирана стойност с вероятност за всеки възможен изход и нищо повече: без проза, без обяснение, без следа от разсъждения. Създаден е за мястото, където иначе би задал на чат модел тесен въпрос и би извадил етикет от отговора му: сортиране на тикет, проверка на правило, подреждане на списък. Цената му е като на инфраструктура: около четири цента на милион входни токена, а изходът е безплатен. При такава цена да го пробваш струва инженерно време, а не пари.
Първа и втора задача: правилният резултат на първо място
Търсенето е очевидният пример. Имаме две системи за търсене: едната в общо хранилище с кратки бележки на екипа, другата в няколкостотин страници техническа документация. Двете вече имаха първи етап, който съчетава търсене по ключови думи със семантично търсене, и връщаха приличен топ 10. Проблемът беше подредбата. Правилният отговор обикновено беше в списъка, но не винаги най-отгоре, а хората и AI агентите четат предимно върха. Затова добавихме втори етап. Jev чете въпроса до всеки от десетте кандидата, оценява колко добре кандидатът отговаря на него и списъкът се преподрежда по оценка. Начинът, по който питахме, имаше значение: да оценяваме всеки кандидат поотделно, с десетте повиквания паралелно, се оказа по-добре, отколкото моделът да избира най-добрия от десетте с едно повикване. Всяко повикване има краен срок и когато оценките не пристигнат навреме, търсенето запазва подредбата, която вече е имало.
Какво даде вторият етап
Тествахме го така, както тестваме всичко, което може да пуснем. Използвахме въпроси, които системата никога не беше виждала, и записахме какво ще се брои за успех преди първото пускане. При търсенето в бележките, което и без това беше добро, делът на търсенията с правилната бележка на първо място се вдигна от 92 на около 96 процента. При търсенето в документацията правилната страница излезе първа при 92 от 120 тестови въпроса, срещу 61 без втория етап. За бележките първо бяхме пробвали учебниковата алтернатива: малък модел за преподреждане с отворен код, работещ на наш собствен хардуер. Не струваше нищо на повикване, но не прескочи същата летва и отнемаше около шест секунди на търсене. Jev добавя между половин секунда и секунда и половина на търсене и около четири стотни от цента. И двата втори етапа вече работят на живо.
Трета задача: избор на модел за всяка работа
Третата задача изглеждаше като същия вид решение. Като много екипи, ние пускаме AI агенти за програмиране с фиксирана настройка по подразбиране: силен модел на високо ниво на разсъждение за цялата работа по код. Рутер, който чете всяка задача и праща лесните към по-евтин модел или към по-малко разсъждение, би спестявал пари от всяка лесна задача. Маршрутизирането е в собствения списък с приложения на Jev, така че изградихме такъв рутер. Той имаше предпазни механизми: изричният избор на човек винаги печели, най-скъпите настройки никога не се избират автоматично, а всяка грешка или неуверен отговор връща настройката по подразбиране. После го пуснахме върху около 150 реални описания на задачи от собствената ни история, по три пъти всяко. Той мина всяко правило за безопасност, което бяхме записали, и почти никога не избра по-евтиния вариант. За повече от една четвърт от задачите по код поиска най-високото налично ниво на разсъждение, а за повечето от останалите се съгласи с настройката по подразбиране. Ако го бяхме включили, сметката щеше да порасне.
Има ли настройката значение изобщо?
Тестът върху историята показва какво избира рутерът, но не и дали изборите са правилни. Затова пуснахме наново шест завършени задачи по код, от точно същите първоначални входни данни, с три настройки: тази по подразбиране, същия модел с повече разсъждение и по-евтин модел. Всяко повторение беше оценено от автоматичните тестове, срещу които е била приета оригиналната работа. Допълнителното разсъждение отне от 1,5 до 2,2 пъти повече време и не донесе нищо измеримо. По-евтиният модел се изравни с настройката по подразбиране при три задачи и изостана при другите три. Увереността на рутера, че дадена задача има нужда от по-силния модел, се оказа вярна при три от шестте, което е на нивото на случайността. Дори една и съща настройка при една и съща задача се разминаваше с до девет пункта в дела на минаващите тестове между повторенията, така че значение имат само големите и последователни разлики. Рутерът остава изключен. Постановката за повторения остава в употреба: така ще измерим следващата версия на модела, преди да сменим настройка по подразбиране.
Преценка срещу прогноза
Двете задачи, в които Jev спечели, имат нещо общо: доказателствата бяха във входа. Дали една бележка отговаря на даден въпрос е преценка за два текста, които моделът вижда. Задачата, която не спечели, иска нещо друго: прогноза как друг модел ще се представи на работа, която още никой не е започнал. Нищо в описанието на задачата не казва това. Маршрутизирането на тикети, учебниковото приложение, пасва на първия тип: кой екип трябва да поеме тикета, пише в самия тикет. Кой модел ще се справи със задачата, не пише в задачата. Това е границата, която теглим сега. Моделът за решения е добър съдия на това, което е пред него. Той не е прогнозист, а тесен въпрос с прикрепена вероятност може да накара прогнозата да изглежда като преценка.
Какво да отнесете от това
Използвайте модел за решения там, където отговорът е във входа: релевантност, класификация, проверка на правила, дали даден резултат отговаря на изискване. Бъдете предпазливи навсякъде, където отговорът зависи от нещо, което входът не съдържа, като трудност, бъдещо поведение или краен резултат. Давайте му кратък списък, а не цялата колекция, и задавайте по един тесен въпрос за всеки кандидат. Нека при проблем системата просто продължава постарому: всяко повикване има нужда от краен срок и от връщане към това, което сте имали преди, и точно това направи включването му безпроблемно за нас. Измервайте ползата отделно от безопасността, защото един рутер може да мине всяка проверка за безопасност и пак да не спести нищо, а само повторното пускане на реална работа ще покаже кое от двете е вярно. Очаквайте първият резултат да остава стабилен, докато останалата подредба се разбърква от едно пускане до друго. И решете съзнателно какво излиза от системите ви, защото всяко повикване изпраща оценявания текст към външна услуга.
Искате да обсъдим как това се отнася до Вашия бизнес? Запазете безплатен разговор.
Готови ли сте за AI?
Помагаме на компании да идентифицират, проектират и внедряват AI решения, които реално работят. Запишете безплатна консултация.
Запазете безплатен разговор →Свързани статии
Всички статии →AI чатбот за e-commerce поддръжка: какво да автоматизирате първо
Практична рамка за онлайн магазини: какво AI чатбот трябва да поеме първо — повтарящи се въпроси, продуктово ориентиране, политики и предаване към човек.
AI сигурността вече е въпрос при покупка
Mythos Preview на Anthropic и инцидент с инструменти на OpenAI сочат към едно: при избора на AI бизнесът трябва да оценява права, интеграции и риск — не само модела.
Защо местното студио за разработка е по-добро от фрилансер
Фрилансерите са евтини. Агенциите са скъпи. Бутиковите студия предлагат нещо по-добро: старши опит, пряка отговорност и без аутсорсинг.