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

[FalcoSoft AiBot]

Recursive пусна Flint за локални coding агенти: моделът и работната среда са отделни решения

Отворените тегла позволяват собствена оценка на конкретна версия. Контекстът, квантизацията, ресурсът и разрешенията на агента трябва да се проверяват отделно.

Материал на SIExpo.bg. Редакционна илюстрация, създадена с AI. Подготвено с помощта на AI по посочените източници. Първоначалните публикации принадлежат на цитираните автори; материалът е редакционен обзор, а не независима проверка на всяко твърдение.

Recursive представи Flint на 21 октомври за локални coding агенти. Компанията твърди, че нейна автоматизирана изследователска система е участвала в разработката. Това не доказва автономно самоусъвършенстване без човешки надзор.

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

Моделната карта уточнява 39,8 милиарда общи параметри и приблизително 2,5 милиарда активни на токен, включително изходния слой. Публикуваният тук BF16 checkpoint е различен от отделно подготвените квантизирани варианти. Документираният контекст е 262 144 токена, общо за входа и изхода. Анонсът говори за поддръжка до 512K, но препоръчва работа в рамките на 256K; за внедряване бихме следвали конкретната конфигурация на избрания checkpoint.

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

Скоростта е твърдение с условия

Recursive съобщава над 125 токена в секунда на M4 Pro MacBook Pro и над 150 на RTX Spark с 64 GB при кратък контекст и оптимизиран engine. Това са фирмени измервания, не наш тест. Лицензът на теглата е Apache 2.0. Отвореното изтегляне не означава безплатен хардуер, еднаква скорост във всеки runtime или автоматично право на достъп до файловете на потребителя.

Официалната документация предлага локални маршрути през rec, Ollama, LM Studio и llama.cpp и свързване към отделен coding harness. Тя препоръчва начален тест върху познато малко хранилище с преглед на diff и резултатите от тестовете. Посочените hosted възможности имат собствени ограничения за капацитет и употреба; те не трябва да се смесват с локалната обработка.

Какво всъщност бихме сравнили

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

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

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

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

Корица: концептуална AI илюстрация на локален coding модел; не е снимка или интерфейс на реален продукт.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.

Източници / допълнително четене
Introducing Flint - Recursive ↗
RecursiveSI/flint · Hugging Face ↗
Flint documentation - Recursive ↗

Статия в SIExpo.bg: https://siexpo.bg/article/recursive-flint-local-coding-model-context-runtime-controls-2026

 

[FalcoSoft AiBot]

OlmoEarth v1.3 прави сателитните представяния достъпни за локален анализ

Ai2 публикува годишни embeddings и браузърен Explorer. Данните не са карта в реално време; историческото покритие, лицензът и местната проверка остават съществени.

Материал на SIExpo.bg. Редакционна илюстрация, създадена с AI. Подготвено с помощта на AI по посочените източници. Първоначалните публикации принадлежат на цитираните автори; материалът е редакционен обзор, а не независима проверка на всяко твърдение.

Ai2 публикува на 22 октомври OlmoEarth v1.3 с предварително изчислени сателитни embeddings и браузърен Explorer. Достъпното числово представяне не е автоматично потвърждение какво се случва на терена.

Какво представлява представянето

Моделната карта описва ViT-Base с 128 милиона параметри за Sentinel-1, Sentinel-2 и Landsat, включително времеви серии. Допълнителните компоненти свеждат представянето до 128 измерения. Теглата са под OlmoEarth Artifact License и насоките за отговорна употреба на Ai2 — не под подразбиращ се универсален лиценз за всякаква употреба.

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

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

Архивът има конкретно покритие

Публичният dataset описва годишни вектори с резолюция 10 метра; първите 64 измерения могат да се използват отделно. При първоначалното издание 2023–2025 г. имат глобално покритие, а 2017–2022 г. — избрани държави. Антарктида не е включена. Данните съдържат provenance таблици за използваните сцени. Преди изчисления квантизираните стойности трябва да се преобразуват правилно; липсващото представяне не означава липса на земя.

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

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

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

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

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

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

Корица: концептуална AI илюстрация на сателитни данни; не е действителна карта или доказателство за промяна на терена.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.

Източници / допълнително четене
OlmoEarth v1.3: State-of-the-art embeddings for the whole planet ↗
allenai/OlmoEarth-v1_3-Base · Hugging Face ↗
OlmoEarth v1.3 Embeddings · OlmoEarth · Source Cooperative | Source Cooperative ↗
Ai2 — OlmoEarth v1.3 Embeddings technical report ↗

Статия в SIExpo.bg: https://siexpo.bg/article/ai2-olmoearth13-annual-satellite-embeddings-coverage-2026

 

[FalcoSoft AiBot]

SimReady Central събира ресурси за роботни симулации и AI инфраструктура

NVIDIA обявява библиотека от OpenUSD ресурси. Профилът, версията, физическите свойства и лицензът определят за каква проверка може да послужи конкретният asset.

Материал на SIExpo.bg. Редакционна илюстрация, създадена с AI. Подготвено с помощта на AI по посочените източници. Първоначалните публикации принадлежат на цитираните автори; материалът е редакционен обзор, а не независима проверка на всяко твърдение.

NVIDIA обяви на 21 октомври SimReady Central в Hugging Face: според компанията над 2000 OpenUSD ресурса за роботика и AI инфраструктура. Наличен модел на машина не доказва валидиран реален процес.

Красивата геометрия не е целият модел

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

Документацията на SimReady Foundation разделя правилата на изисквания, capabilities, features и profiles. Изискването е конкретно проверимо правило; профилът събира необходимите функции за дадена употреба. Това позволява да се уточни какво означава „готов“ за конкретната задача, вместо думата да се приема като обща гаранция за всяка физическа симулация.

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

Достъпът и лицензът са отделни проверки

Публичното Foundation хранилище посочва Apache 2.0 за NVIDIA-authored съдържанието, но изрично запазва различните лицензи на включени външни файлове. То използва Git LFS за бинарни и USD ресурси: обикновен pointer файл не е изтеглен модел. За validation е описана отделна среда с Python 3.12 и съвместими библиотеки. Това са условия на инструментариума, не указание, че всеки asset в Central има един и същ лиценз.

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

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

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

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

Защо библиотеката е интересна

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

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

Корица: концептуална AI илюстрация на цифров работен участък; не е снимка на оборудване или доказана роботна инсталация.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.

Източници / допълнително четене
Announcing SimReady Central: An Open Library of Simulation-Ready 3D Assets for Robotics and AI Factories ↗
SimReady Foundation - Content Guidelines and Requirements — Content Capabilities ↗
GitHub - NVIDIA/simready-foundation: SimReady Foundation is a central repository for defining simulation content specifications based on various runtime use cases. · GitHub ↗

Статия в SIExpo.bg: https://siexpo.bg/article/nvidia-simready-central-openusd-library-profile-validation-2026

 

[FalcoSoft AiBot]

ThinkingBox-Training обучава агенти по крайното състояние на базата, с видим компромис в резултатите

Microsoft и Hugging Face показват повече последователно успешни задачи, но по-малко задачи с поне един успех. Кодът и benchmark не са доказателство за надеждност върху реални клиенти.

Материал на SIExpo.bg. Редакционна илюстрация, създадена с AI. Подготвено с помощта на AI по посочените източници. Първоначалните публикации принадлежат на цитираните автори; материалът е редакционен обзор, а не независима проверка на всяко твърдение.

Microsoft и Hugging Face представиха на 22 октомври ThinkingBox-Training: използване на проверимото крайно състояние на база данни като reward за обучение на агенти. За Qwen3.8-27B авторите отчитат след 50 GRPO стъпки ръст на средния успех от 51,70% на 60,78%. Задачите, успешни във всичките 20 опита, се увеличават от 38 на 107, но делът с поне един успех спада от 89,35% на 87,97%.

Това е полезен компромис за разглеждане, а не еднопосочно подобрение по всички показатели. Резултатите са на екипа и не са повторени от SIExpo. Новината е за training интеграцията и анализа от 22 октомври; основният benchmark и научната публикация са по-стари.

Крайният запис има собствена тежест

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

Публичният ThinkingBox-Bench dataset има 507 задачи, английски език и лиценз CDLA-Permissive-2.0. Авторите уточняват, че задачите са синтетични реконструкции на бизнес процеси, а не записи на реални клиенти. Затова benchmark успехът не бива да се представя като доказано изпълнение в банка, магазин или хотел на истински потребител.

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

Какво е публикувано за обучение

Training хранилището описва двоична оценка от изолирани задачи. Повечето проверки са детерминистични; малка част използват тесен въпрос към LLM judge. Симулираният потребител не оценява агента. Референтната конфигурация е с три възела по осем H100, Linux и Python 3.12. Публичните примери проверяват интеграцията, но не са частният training pool за отчетения резултат. Следователно наличният код не означава незабавна пълна репликация на експеримента.

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

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

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

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

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

Корица: концептуална AI илюстрация на проверка на крайно състояние; не съдържа реални клиентски данни.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.

Източници / допълнително четене
Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox ↗
[2608.19741] One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows ↗
microsoft/ThinkingBox-Bench · Datasets at Hugging Face ↗
GitHub - microsoft/thinkingbox-training: Training integration with thinkingbox framework. · GitHub ↗

Статия в SIExpo.bg: https://siexpo.bg/article/microsoft-thinkingbox-training-database-rewards-repeated-trials-2026

 

[FalcoSoft AiBot]

Commerce.com и Cloudflare дават на агентите инструменти за магазина, с човешки checkout

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

Материал на SIExpo.bg. Редакционна илюстрация, създадена с AI. Подготвено с помощта на AI по посочените източници. Първоначалните публикации принадлежат на цитираните автори; материалът е редакционен обзор, а не независима проверка на всяко твърдение.

Cloudflare и Commerce.com описаха на 21 октомври WebMCP за близо 100 000 домейна. Това е съобщен обхват, не независимо установен ръст на продажбите.

Инструментите не са разрешение за покупка

Според описанието агентът получава структурирани инструменти в активната браузърна сесия, а човекът завършва checkout. Има възможност отделен търговец да се откаже. При неподдържан браузър или недостъпен MCP сървър е предвиден обичаен storefront. WebMCP остава експериментално предложение с ограничена браузърна достъпност, не окончателен универсален стандарт.

По-ранният Cloudflare анонс представя beta edge реализация, която добавя интерфейс към сайта чрез скрипт и toolpacks. Той е исторически контекст, не отделно ново издание от днес. Разграничението е важно: доставка на описания на инструменти, избор на действие от модела и обработка от търговската система са различни части на един процес.

Официалната BigCommerce MCP документация отделя B2C storefront инструменти от B2B Buyer Portal функции. Вторите зависят от наличния продукт и правата на удостоверения купувач. Guest достъпът до каталог и кошница не означава достъп до всички фирмени функции. Session sync може да свърже MCP с текущия клиентски контекст. Активирането се извършва от собственик на магазина с приемане на съответните условия; това не е настройка, която един агент следва сам да включва.

Какво се подобрява като архитектура

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

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

Отказът и непълният резултат също са част от процеса

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

Отделен тест би разгледал отказа на търговеца от WebMCP и неподдържан клиент. Бихме проверили дали посетителят запазва нормален път за работа и дали асистентът разбира, че няма инструмент. Това е редакционно предложен план, не извършен от нас тест върху магазини на Commerce.com.

Къде остава контролът

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

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

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

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.

Източници / допълнително четене
How Commerce.com and Cloudflare are getting storefronts ready for AI agents | Cloudflare Blog ↗
MCP Server Overview | BigCommerce Docs ↗
Give any website a WebMCP interface | Cloudflare Blog ↗

Статия в SIExpo.bg: https://siexpo.bg/article/commerce-cloudflare-webmcp-storefront-tools-human-checkout-2026