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

Granite Switch 4.1.1 обновява адаптерите: какво се променя и защо езиковият списък има значение

IBM показва обновяване на специализирани компоненти при запазен основен модел. Проверяваме конкретната ревизия, версиите и различните описания на речевата поддръжка.

Материал на SIExpo.bg. Корица: AI редакционна илюстрация, не документална снимка.

granite-switch-411-modular-adapter-update-2026-61f916a34a10b85d.jpg


На 29 октомври IBM представи Granite Switch 4.1.1 като съвместима поправка с обновени речеви и decision компоненти и непроменен основен модел. Публикацията обещава по-добри решения и транскрипция, но не представлява независимо измерване на производителността. Това е последваща ревизия на вече представения Switch 4.1, а не повторно обявяване на първоначалния продукт.

Какво точно се обновява

Картата на 30B модела датира ревизията от 27 октомври. Тя запазва двата адаптера guardian-core и decision, като вторият получава нови тегла. Контролни маркери избират адаптера; съществуващият формат за извикване остава същият според документацията. Разграничението между датата на артефакта и по-късното съобщение е важно за екипите, които следят версии.

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

В модела има конкретно несъответствие, което не бива да се скрива. Блогът говори за десет езика при обновеното разпознаване на реч. Картата и таблицата на тази 30B композиция изброяват седем: английски, френски, немски, испански, португалски, италиански и японски. Не приемаме, че десетте са потвърдени за този артефакт, нито че списъкът включва български.

Версията е част от резултата

Хранилището обяснява, че main следва последната ревизия, а изданията имат тагове. BUILD.md описва състава на композицията. За възпроизводима проба това дава практична отправна точка: запишете конкретния артефакт, вместо само общото име на семейството. Иначе две изпълнения могат да изглеждат еднакво обозначени, въпреки че използват различни компоненти.

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

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

Това предполага и смислено сравнение между ревизиите: входният набор и правилата на приложението остават еднакви, а променените отговори се разглеждат поотделно. Самият номер на версията не показва дали разликата идва от разпознаване, класификация или околния код. Това е предложение за оценка; SIExpo не е изпълнявал модела локално.

Какво още предстои

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

Редакционният извод е конкретен: тази поправка прави управлението на отделни AI компоненти по-видима инженерна тема. Практическата ѝ стойност трябва да се установи върху точната версия и задача. Съвместим интерфейс помага при интеграцията, но проверката на резултата остава работа на внедряващия екип.

*Корица: AI илюстрация на модулно обновяване, не изображение на реален хардуер.*

*Редакционна проверка: 31.10.2026, 09:12:27 +0200 (Europe/Sofia).*

Източници
Granite Switch 4.1.1 — Update models like you update software — 2026-10-29
Granite Switch 4.1 30B — revision 4.1.1
Granite Switch 4.1 30B — BUILD.md

Статия в SIExpo.bg: https://siexpo.bg/article/granite-switch-411-modular-adapter-update-2026
 
Project ProtoStar свързва отворените научни данни с проверими AI задачи

Инициативата започва с предстоящо климатично предизвикателство на Carnegie Mellon. Целта е повторна употреба на научни ресурси; по-добри прогнози още не са доказани.

Материал на SIExpo.bg. Корица: AI редакционна илюстрация, не документална снимка.

protostar-open-science-climate-challenge-2026-c8dd27a03d451ae6.jpg


Обявеният на 29 октомври Project ProtoStar цели повторна употреба на научни данни, модели и код чрез отворена инфраструктура и практически задачи. Участват Carnegie Mellon, Hugging Face и ORCA. Научен пробив още не е установен.

Началната задача е насрочена за 2–13 ноември: 210 американски града, обучение до 2018 г., оценка за 2019–2026 г. и резултати в началото на 2027 г. Състезанието още не е започнало; завършените годишни наблюдения предстоят.

Публичен файл и използваем ресурс

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

Документацията на Hugging Face описва dataset card като README с човешко обяснение и YAML метаданни. Лиценз, език, размер и тагове подпомагат откриването; информацията за потенциални отклонения помага да се разбере подходящата употреба. Така страницата на набора може да бъде повече от бутон за изтегляне.

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

Какво би било убедително доказателство

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

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

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

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

Значението за AI сектора

ProtoStar поставя инфраструктурата за научна повторяемост до самите модели. Това е интересната новина: организацията на ресурсите и проверката на употребата им се разглеждат заедно. Все още не е доказано, че инициативата ускорява открития или подобрява конкретни прогнози.

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

*Корица: AI илюстрация на научни данни и наблюдения, не реална карта на резултати.*

*Редакционна проверка: 31.10.2026, 09:12:27 +0200 (Europe/Sofia).*

Източници
Announcing Project ProtoStar: Making Publicly Funded Science AI-Ready — 2026-10-29
Hugging Face Hub — Dataset Cards

Статия в SIExpo.bg: https://siexpo.bg/article/protostar-open-science-climate-challenge-2026
 
Articul8 предлага Bivia за ограничени решения в AI агенти — с възможност за отказ

Новият API връща структурирани решения вместо свободен текст. Разглеждаме как отказът и увереността се вписват в приложение и защо фирмените демонстрации не са независим тест.

Материал на SIExpo.bg. Корица: AI редакционна илюстрация, не документална снимка.

articul8-bivia-typed-decisions-agent-api-2026-843f9dcc6d6121e3.jpg


На 28 октомври Articul8 обяви Bivia — мултимодален модел за решения, предлаган чрез API. Компанията го позиционира за специализация според фирмени правила и процедури. Това е продуктово съобщение с вътрешни изпитвания, а не независимо потвърждение за точност във всяка индустрия.

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

Какво вижда разработчикът

Продуктовата страница описва типизирани изходи, включително избор, булева стойност, оценка и извлечен откъс. При отговор приложението трябва първо да провери status, след това value. При abstained стойността е null и има причина за отказа. Опцията allow_abstain включва това поведение; при изключването ѝ моделът избира отговор.

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

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

Отговорът и действието са различни стъпки

Възможен първи експеримент е маршрутизиране на вътрешни заявки в режим на наблюдение. Човек продължава да определя правилния екип, докато системата записва предложението си. След това могат да се сравнят правилните избори, отказите и случаите, в които уверен грешен избор би създал допълнителна работа.

За такава оценка бихме запазили и неясните примери. Ако тестът съдържа само очевидни случаи, той почти не проверява стойността на въздържането. Също така отказът не е непременно провал: може да бъде подходящият резултат, когато входът няма достатъчно информация. Това не позволява да се отчита единствено делът на отговорените заявки.

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

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

Какво означават нулевите изходни токени

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

SIExpo не е изпращал частни данни към API, не е активирал абонамент и не е измервал модела. Проверимото събитие е предлагането на продукта и описаният договор за отговор. Дали този подход подобрява даден агент остава въпрос за конкретна, предварително определена оценка.

*Корица: AI илюстрация на входове, решения и отказ, не реален продуктов екран.*

*Редакционна проверка: 31.10.2026, 09:12:27 +0200 (Europe/Sofia).*

Източници
Articul8 launches Bivia to bring domain-specific decision intelligence to enterprise AI agents — 2026-10-28
Bivia by Articul8 — product interface and response guide

Статия в SIExpo.bg: https://siexpo.bg/article/articul8-bivia-typed-decisions-agent-api-2026
 
TDK показва сензорната страна на хуманоидните роботи на Foxconn Tech Day

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

Материал на SIExpo.bg. Корица: AI редакционна илюстрация, не документална снимка.

tdk-foxconn-humanoid-sensors-components-2026-48731b801c80db61.jpg


На 30 октомври TDK обяви сензорно и компонентно портфолио за хуманоиди на Foxconn Technology Day в Тайпе, 30–31 октомври: позиция, ъгъл, NTC температура и пасивни компоненти. Съобщението не обявява завършен универсален робот.

Публичният адрес на съобщението съдържа „20261029“, но видимата дата на страницата е 30 октомври. Използваме именно публикуваната дата, вместо да извеждаме деня на събитието от името на файла. Изложбеното присъствие също не удостоверява независимо измерени характеристики на цял робот.

От командата до измереното движение

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

TDK InvenSense описва PositionSense като двучипово решение с шестосна IMU, триосен TMR магнитометър и сливане на сензорни данни. Продуктовата страница посочва абсолютна ориентация и приложения, включително роботика. Описанието на такава система не бива да се чете като обещание за прецизност на всеки робот или като готова пространствена карта на средата.

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

Как бихме оценили практическата полза

Полезна проверка би започнала с една определена задача, например повтарящо се движение към една и съща позиция. Бихме записали командата, измереното положение и времето на наблюдението. Така може да се различи проблем във възприятието от проблем в изпълнението, без всичко да се обяснява с „интелигентността“ на робота.

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

Страницата за роботика на InvenSense представя сливането на данни върху чипа като начин за намаляване на натоварването на основния процесор. Това е твърдение на доставчика. За конкретен проект ползата би зависела от цялата конфигурация, затова не превръщаме продуктовото описание в измерена икономия на енергия или универсално по-ниско закъснение.

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

Какво не е установено

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

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

*Корица: AI илюстрация на измислен роботизиран механизъм; не снимка от събитието.*

*Редакционна проверка: 31.10.2026, 09:12:27 +0200 (Europe/Sofia).*

Източници
TDK showcases sensor and passive component solutions for humanoid robotics at Hon Hai (Foxconn) Tech Day — 2026-10-30
TDK InvenSense — PositionSense
TDK InvenSense — Robotics

Статия в SIExpo.bg: https://siexpo.bg/article/tdk-foxconn-humanoid-sensors-components-2026
 
Kodiak отчита 99% готовност на досието за безопасност — какво измерва този показател

Фирменият ARM отчита завършени твърдения и доказателства. Планираният магистрален старт остава бъдещ етап; процентът не е точност на шофиране или сертификат.

Материал на SIExpo.bg. Корица: AI редакционна илюстрация, не документална снимка.

kodiak-arm-readiness-safety-case-2026-ece7f558322d1eee.jpg


На 30 октомври Kodiak AI съобщи, че Autonomy Readiness Measure достига 99% за планираните безпилотни превози на дълги разстояния. Компанията определя ARM като дял на съществено завършените твърдения и доказателства в своето досие за безопасност. Процентът не измерва точност на шофиране, вероятност за безопасно пътуване или независима сертификация.

След приключване на досието Kodiak планира работа без човек в кабината по Interstate 45 между Далас и Хюстън до края на 2026 г. Това остава бъдещ фирмен план. Съобщеното приближаване до вътрешен етап не означава, че магистралната услуга вече е започнала.

Как да се чете процентът

Подобен показател отговаря на въпрос за напредъка на подготвителната работа. Той не казва самостоятелно колко тежки са оставащите задачи, дали всяка има еднаква значимост или колко време ще отнеме приключването им. От 99% следователно не може да се пресметне дата на старта или оставащ риск.

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

Откъде идват доказателствата

В технически текст от 3 юни Kodiak описва Probabilistic Risk Assessment чрез честота на срещане на сценарий, вероятност за сблъсък при него и тежест на последствията. BreakPoint търси проблемни случаи в симулация и подава резултати към оценката. Това са методи, описани от разработчика, а не наша проверка на изчисленията му.

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

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

Смислената оценка би разграничила и увереността в дадена оценка от количеството доказателства зад нея. Две добре представени числа могат да стъпват на различни допускания. Видимите допускания и отворени въпроси биха улеснили преценката на оперативно твърдение; това е редакционен критерий, а не констатация за непубликувани фирмени данни.

Какво би направило следващата новина по-силна

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

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

Новината показва напредък според собствената система за отчитане на Kodiak. За AI сектора интересът е в опита доказателствата и оставащата работа да бъдат изразени като проследим процес. Практическата безопасност на планираната услуга трябва да се оценява по нейните конкретни доказателства и условия, а не по впечатляващия процент сам по себе си.

*Корица: AI илюстрация на планиран превоз и незавършено досие, не снимка на реален курс.*

*Редакционна проверка: 31.10.2026, 09:12:27 +0200 (Europe/Sofia).*

Източници
Kodiak AI Accelerates Toward Driverless Long-Haul Launch as Autonomy Readiness Measure Reaches 99% — 2026-10-30
Quantifying Safety Knowns and Unknowns: How Kodiak Uses PRA and AI to Measure Risk — 2026-06-03

Статия в SIExpo.bg: https://siexpo.bg/article/kodiak-arm-readiness-safety-case-2026
 

Горе