С повече от 20 години опит ние променяме вашето цифрово присъствие. Специализирани сме в разработването на уебсайтове и електронни магазини, SEO и цифров маркетинг, ERP софтуер и интелигентна автоматизация, които извеждат бизнеса ви на следващото ниво.
Адрес:
Егнатия 154, Солун 546 36
Телефон:
+30 231 231 4095
Електронна поща:
[email protected]
Готови ли сте за следващата стъпка?;
Как trie-автоматите ускоряват декодирането с ограничения при големи крайни множества, какво показаха тестовете за производителност и кога си заслужават да се използват в корпоративната изкуствена интелигенция.
Trie-автоматите могат да премахнат едно критично затруднение, когато дадена система за изкуствен интелект трябва да избере точно една валидна стойност сред хиляди инструменти, категории или кодове. В този случай декодирането с ограничения проверява на всеки етап кои токени все още могат да доведат до валиден отговор. Колкото повече списъкът се разраства, толкова повече един общ граматичен механизъм може да води до излишни разходи за компилация и маскиране.
Работата Трие-автомати за декодиране с ограничения върху големи крайни множества на Xingzi Xu и Karim Bouyarmane предлага trie на ниво символ, съвпадение по Aho-Corasick и предварително изчислени маски на токени. Експериментите отчитат валидност 100% и значителни подобрения при конкретни работни натоварвания. Бизнес изводът е по-конкретен и по-полезен от заглавието: плоските крайни множества изискват специализиран бекенд, докато действителният избор трябва да се прецени въз основа на същия модел, токенизатор, профил на партидите и хардуер, които ще се използват в производствената среда.
Структурираните изходи се използват, за да се принуди един LLM да върне данни, които съответстват на дадена схема: валиден JSON, правилни имена на полета и стойности от допустимите варианти. Обичайната техника е маскирането. На всеки етап от генерирането системата изключва токените, които не могат да доведат до приемлив резултат. По този начин форматът не се основава единствено на добрите намерения на подсказката.
Общите двигатели преобразуват схеми или граматики в машини с краен брой състояния, автомати с стека или анализатори. Това е необходимо за сложни структури: вложени обекти, масиви, рекурсия и сложни регулярни изрази. Но един плосък набор от познати низове — например името на инструмент — не е толкова сложен. Въпреки това често преминава през същия общ процес.
Авторите наричат резултата стена на кардиналността: освен редица опции, времето за компилиране и повтарящото се изчисляване на маската стават практически скъпи. Статията посочва като примери документирани или наблюдавани ограничения на доставчиците и свързва въпроса с регистрите на инструменти, класификациите, свързването на обекти и списъците, базирани на извличане на данни, които се променят при всяко заявка. Тези позовавания представляват контекста на статията, а не универсална оценка за всеки API или внедряване.
Един AI агент може да се наложи да избере API от голям регистър. В среда с MCP сървъри, вътрешни услуги, CRM, електронна търговия, аналитика и инструменти за поддръжка, наличните действия могат бързо да се увеличат. Същият модел се наблюдава, когато моделът трябва да върне категория на продукт, намерение за обслужване или идентификатор на обект от голям списък.
За електронна търговия, проблемът може да възникне при класифицирането на продуктите, насочването на заявките към подходящи автоматизирани процеси или избора на валидно действие при управлението на поръчките. За един екип маркетинг, може да се отнася до съпоставянето на съдържание с таксономия или до избора на работен процес от предварително определен набор. Това са практични интерпретации на механизма, а не примери за употреба, които в статията са били специално измерени в реални магазини.
Разликата спрямо свободното създаване на текст е решаваща. Тук не е достатъчно отговорът да «изглежда правилен». Той трябва да принадлежи точно към наличния набор. Несъществуващо име на инструмент или етикет с малко отклонение може да прекъсне следващото действие, дори ако човекът разбира какво е имал предвид моделът.
Trie е дърво на префикси. Ако много стойности започват с едни и същи символи, общият префикс се съхранява само веднъж, а пътеките се разделят само там, където се различават. Низовете медицинско_фактуриране, медицинско_кодиране и медицински_документи, както се вижда от примера в статията, те си разпределят medical_ и след това се разклоняват.
Това, разбира се, важи за краен списък. Всеки възел съответства на валиден префикс, а всеки лист – на цялостна стойност. Моделът може да се движи само по пътища, които завършват с допустим низ. Ако дадена стойност е префикс на по-голяма стойност, един и същ възел може да приема както край на последователността, така и продължение.
Предложението в статията използва trie на ниво символ, а не изключително на ниво токен. Този избор позволява споделяне на префикси, независимо от това как токенизаторът разделя низовете. Един токен обаче може да обхваща много символи и множество възли. Следователно е необходим ефективен начин за свързване на речника на BPE-токените с пътеките на трие-дървото на символите.
Най-простото решение би било да се тества всеки токен от речника във всеки възел на трието. При речници с десетки или стотици хиляди токени това би било скъпо. Авторите превръщат проблема в съвпадение на низове с множество шаблони и използват алгоритъма на Ахо-Корасик.
Речникът се разглежда като набор от шаблони. Автоматът на Ахо-Корасик се изгражда въз основа на тях и, при преминаването през трие, установява кои низове от символи могат да започнат от всеки възел и да следват валиден път. По този начин се изчислява множеството от валидни токени за всяко състояние.
По време на декодирането двигателят не се налага да претърсва отново целия речник, за да реши кои токени са допустими. Той извлича вече изчислената маска на текущия възел. Статията уточнява, че прилагането на маската върху вектора с логити все още има разходи по отношение на речника. Печалбата се състои в изчисляването на това кои токени са валидни, а не в премахването на всякаква свързана с това работа.
В резюмето авторите посочват 0,65 микросекунди за изчислението на валидните токени на стъпка, спрямо 5,8 микросекунди за XGrammar, което е приблизително 8,9 пъти по-бързо изчисление на валидните токени според използваната от тях сравнителна база. Те посочват също така, че компилацията е от 2 до 6,5 пъти по-бърза за набори от поне 300 варианта, в зависимост от настройката.
При тест от край до край с vLLM, Qwen3-8B, синтетични имена на инструменти и размер на партидата 256, измерената производителност достигна 219,4 заявки в секунда за trie спрямо 7,5 за XGrammar. Това е 29,3-кратно превъзходство. В статията се подчертава, че това не е чисто алгоритмично сравнение: то съчетава по-бързото изчисляване на маската с безсъстоятелен интеграционен път в vLLM, докато XGrammar преминава през пипалината за насочено декодиране.
Това разграничение е от решаващо значение. Ползата на стъпка се счита за преносима като алгоритмично свойство, но точното съотношение 29× не трябва да се обобщава за всеки serving engine. Самите автори го определят като специфично за vLLM. Измерванията са проведени на NVIDIA A100 80GB и AMD EPYC 7R32 процесори, поради което друго оборудване и друга интеграция могат да дадат различни резултати.
Основният критерий за оценка на статията на две нива
Измервания на авторите с Qwen3-8B и конкретна конфигурация на vLLM. Стойностите от 219,4 и 7,5 заявки/сек. включват ефекти от интеграцията и не представляват гаранция за друг сървинг стек.
Кой бекенд за ограничения е подходящ за конкретната работна натоварване?;
Началните разходи може да са по-значителни от маскирането на всеки етап. Общ двигател или „ленив“ парсер може да остане най-простият и най-бърз вариант.
Когато стотици или хиляди варианти се използват многократно в множество заявки, предварително изчислената дървовидна структура за символи се превръща в силен кандидат.
Плоският енум може да бъде преобразуван в трие, докато обектите, масивите, рекурсията и регулярните изрази остават в граматичния бекенд. Не е необходим един и същ двигател за всичко.
Необходимо е измерване на „cold“ и „warm“ компилация, тъй като промяната на стойностите на enum изисква прекомпилация, дори ако автоматът на токенизатора се кешира.
Статията сравнява три различни баланса. LLGuidance има много ниска начална цена благодарение на „ленивото“ анализиране: в тестовете на статията – от 0,6 до 24 ms за K от 10 до 10 000. Въпреки това изчислението на маската на всеки етап е измерено между 73 и 141 микросекунди. XGrammar се намира някъде по средата, с компилация от 3 до 239 ms и маскиране от около 5 до 10 микросекунди. Trie отнема около 30 до 40 ms за изчисление, но остава на 0,65 микросекунди на стъпка.
Следователно няма един-единствен победител за всеки работен товар. При схема „one-shot“ с по-малко от около 500 варианта, където компилацията доминира и резултатът се генерира еднократно, LLGuidance или XGrammar може да са по-подходящи. При повтарящо се обслужване, при големи списъци и най-вече при партиди, малката цена на всеки етап при trie може да доведе до по-голяма полза.
Обслужването на партиди разкрива защо работата на процесора (CPU) е от значение дори когато моделът се изпълнява на графичния процесор (GPU). Процесът на преминаване напред (forward pass) се разпределя между множество заявки, но всяка заявка се намира в различно състояние на декодиране и се нуждае от собствена маска. В пакет 128 от експериментите в статията се отчита общо време за маскиране от 10 микросекунди за trie, 783 за XGrammar и 3,716 за LLGuidance. Цифрите не представляват гаранция за производителност, но показват как малък допълнителен разход на заявка може да се превърне в пречка за пропускателната способност, когато се умножи.
Едно trie на ниво токен, като логиката, свързана с GENRE, е по-просто. Всяка стойност от изброения се токенизира веднъж, а допустимите последователности са идентификаторите на под-токените. При малки списъци това може да е по-бързо, тъй като не изисква автомат на Ахо-Корасик или предварително изчисляване на маски.
При измерванията, проведени от авторите с Qwen3-8B и инструменти за синтез, token trie отне 4,5 ms, спрямо 31 ms за character trie при 100 стойности. При около 1 000 времената се изравняват: 37 срещу 35 ms. При 10 000 token trie достига 369 ms, а character trie – 52 ms. Тоест, пресичането се появява приблизително в областта, която в статията се нарича „cardinality wall“.
Trie-дървото на ниво символ също е независимо от токенизатора и позволява различни разбивания на токени, които образуват един и същ низ. В конкретните тестове за алчно декодиране авторите посочват еднакви последователности от токени между трие на ниво символ и каноничното трие на ниво токен. Въпреки това те признават, че това е емпирично наблюдение, а не гаранция за най-лошия случай за всеки модел или настройка на извадката.
Едно от основните ограничения на декодирането с ограничения е, че то гарантира, че отговорът принадлежи към допустимото множество, а не че е правилният избор. Ако моделът избере грешна категория, резултатът може да е синтаксически валиден, но оперативно погрешен.
Статията доказва еквивалентност на изхода между trie-автомата и FSM за декодируемия речник и отбелязва резултати, идентични на байт ниво, при съответните тестове. В четири публични бенчмарка за класификация — TREC, MASSIVE, Banking77 и CLINC150 — трие-автоматът е постигнал валидност 100%. Авторите посочват, че декодирането с ограничения е постигнало най-висока точност в 21 от 24 комбинации от модел и набор от данни, докато декодирането без ограничения е достигнало валидност от поне 95% само в 8 от 24 случая.
Това е резултат от конкретния експериментален дизайн, а не доказателство, че ограничението винаги подобрява семантичното разсъждение. Статията посочва и случаи, в които мощни модели без ограничения са постигнали малко по-висока точност. За дадена компания правилната архитектура изисква две проверки: ограничение за валидността на стойността и отделна оценка за това дали изборът служи на реалната цел.
Дискриминацията също е проблем управление на ИИ-агентите: валидното извикване трябва да бъде придружено от политика за оторизация, доверие или въздържание, оперативно потвърждение и сигурен резервен вариант, преди да бъде изпълнено необратимо действие.
Първият урок е от архитектурен характер: не разглеждай всяка схема като един и същ проблем. Един вложен обект от тип „поръчка“, една дата, един числови диапазон и списък с 5 000 имена на инструменти имат различна структура. Един диспечер може да изпраща плоските крайни множества към специализиран бекенд и да оставя сложните структури на граматичния двигател.
Вторият тест е функционален: измерва поотделно латентността при компилиране, маскирането на всеки етап, общото време за извличане на заключения, пропускателната способност на партида и процента на невалидните резултати. Един бенчмарк, който показва само микросекунди на маска, не разкрива допълнителната натовареност при интеграцията. Напротив, един впечатляващ мултипликатор от край до край може да включва ефекти от планиращия алгоритъм и конвейера, които няма да се пренесат така, както са, във вашия стек.
Третият урок засяга икономиката на GPU. Когато ценното време на ускорителя се изразходва за изчисления на маски от страна на CPU, една оптимизация на на пръв поглед малък компонент може да повлияе на използването на инфраструктурата. Това не води автоматично до конкретна икономия на разходи; необходими са профилиране, специфично за работната натоварване, тестове за паралелност и измерване на действителния брой генерирани токени.
За електронната търговия и маркетингови екипи, практическото въпрос е дали вече съществува опция с висока кардиналност във веригата: обширна таксономия, регистър на действия, намерения, маршрутизиране към конектори или динамичен списък с резултати от извличане. Ако не, то trie-автоматът вероятно не е приоритет. Ако да, тогава си заслужава да се създаде прототип успоредно със съществуващия бекенд, с същите подсказки, модели и набори от данни.
Методът оптимизира избора на плоски крайни множества. Той не замества универсалните парсери за вложени схеми, масиви, рекурсия или произволни регулярни изрази. Статията разглежда смесените схеми по отношение на компилацията, но не и пълната производителност от начало до край за сложни производствени структури.
Динамичните актуализации на изброителите изискват пълна прекомпилация. Авторите посочват, че това става бързо в тяхната реализация и че автоматът на Ахо-Корасик може да бъде кеширан по токенизатор, но това не е инкрементална актуализация. Освен това реализацията се описва като Rust с Python bindings, а кодът ще бъде публикуван едновременно с публикуването на статията, така че независимото възпроизвеждане остава важно.
Пропускателната способност на headline е измерена само при vLLM. В статията се обяснява, че SGLang също използва XGrammar като бекенд за декодиране с ограничения, но там не се представя съответен бенчмарк за end-to-end trie. За TensorRT-LLM интеграцията остава задача за бъдеща работа. Освен това, ако маскирането бъде ефективно прехвърлено към GPU, част от предимството от страна на CPU може да се намали.
Безопасното внедряване започва с профил на натоварването и контролиран бенчмарк, а не с пренасяне на коефициента 29,3× в бизнес случая. K, честотата на промяна на опциите, споделянето на префикси, пакетната обработка и семантичната точност трябва да се измерват поотделно.
Пилотен проект за оценка на trie-автомати в шест стъпки
Запишете средния брой и p95 брой опции на заявка, дължината и степента на споделяне на префиксите на низовете, както и дали става въпрос за имена на инструменти, етикети от таксономията, идентификатори на обекти или друго затворено множество.
Разделете „cold“ и „warm“ компилациите, маскирането на всеки етап, общата латентност, натоварването на процесора, времето на бездействие на графичния процесор, пропускателната способност на партида и процента на невалидните резултати в съществуващия двигател.
Запазете непроменени модела, токенизатора, подсказките, крайните множества, разпределението на партидите, хардуера и броя на генерираните токени. Различен път на интеграция трябва да се запише като отделна променлива.
Една допустима, но погрешна класификация не е успех. Използвайте етикетиран набор за оценка, бизнес правила и човешка проверка за решенията с висок риск.
Прехвърлете големите плоски изброими типове в кандидатния трие и запазете вложените обекти, масивите, рекурсията и сложните регулярни изрази в бекенда за обща граматика с ясен резервен вариант.
Проверете динамичните актуализации, прекомпилацията, степента на уцелване на кеша, паралелизма, наблюдаемостта, отмяната на промени и изолирането на грешки, преди системата да получи право да извиква инструменти или да променя поръчки и клиентски данни.
Значението на тази статия надхвърля рамките на една конкретна структура от данни. Това показва, че структурираното генериране не е еднозначен проблем. Когато структурата притежава използваема регулярност, специализиран механизъм може да премахне допълнителната натовареност, която общият двигател понася за ненужни възможности.
За екипите, които строят продукти за изкуствен интелект за предприятия, което променя въпроса от «кой механизъм за декодиране с ограничения е по-бърз?» към «кой механизъм е подходящ за всяко ограничение и за всеки работен товар?». Trie-автоматът изглежда особено обещаващ за големи, повтарящи се избори от крайни множества. В същото време предпечатът поставя ясни граници: малките схеми от типа „one-shot“, сложните структури и различните механизми за обслужване изискват собствена оценка.
Следващата практическа стъпка не е да пренесете 29× в бизнес случая. Тя е да откриете истинската „кардиналностна бариера“ във вашата система, да проведете контролирано сравнително тестване и да вземете решение въз основа на реалната точка на претоварване, която имате.
TWO DOTS картографира регистри на инструменти, крайни множества, схеми, резервни варианти и човешки контролни точки, за да може агентите, електронната търговия и работните потоци за поддръжка да се мащабират с измерима латентност, семантична точност и безопасно изпълнение.
Често задавани въпроси
Това е процесът, който ограничава токените, които даден модел може да генерира, така че крайният изход да следва конкретна схема, граматика или затворено множество от валидни стойности.
Това е моментът, в който увеличаването на наличните варианти прави компилирането или маскирането на всеки етап в един общ механизъм за декодиране с ограничения практически скъпо за конкретната работна натоварване.
Тъй като разпределя префиксите на ниво символи, независимо от токенизацията. Алгоритъмът на Ахо-Корасик ефективно съпоставя низовете от токени с валидните пътища в трието.
Не. Това е резултат от край до край на конкретния vLLM тест и съчетава алгоритмични предимства с различен път на интеграция. Всеки екип се нуждае от бенчмарк в своя собствен serving stack.
Не. Те гарантират, че изходът принадлежи към допустимото крайно множество, но моделът може да избере грешна стойност. Семантичната точност се оценява отделно.
Не. Trie е специализиран за плоски крайни множества. Вложените схеми, масивите, рекурсията и сложните регулярни изрази изискват общ бекенд, докато малките еднократни множества може да налагат друг компромис при стартирането.
Когато има стотици или хиляди валидни варианти, повтарящо се подаване на данни, големи партиди или маскиране на CPU, което кара GPU да чака. Решението трябва да се основава на профилиране на работната натоварване.
Запишете броя и честотата на промените в настройките, „cold“ и „warm“ компилация, маскиране на всеки етап, размер на партидата, латентност от край до край, валидност и семантична точност при еднакви условия за сравнение.
