intel

Intel One Mono v1.5, if you’re into such things Is everybody in?

Dans les projets où on l'attendait pas, vous savez qu'Intel propose sa propre police de caractères orientée code ? En Open Font Licence ? La version 1.5 vient de sortir, ils ajoutent pas mal de choses (Braille, Powerline, etc), les détails sur Github intel/intel-one-mono

Omg the Intel One Mono font got discontinued and archived, then undiscontinued and unarchived, and now there's a new version! github.com/intel/intel-one-mono/releases/tag/V1.5…

In fact, C++26 made some considerable progress on that front. en.cppreference.com An implementation of which exists in the following GitHub repo (albeit implemented in the xvec::simd namespace rather than std::simd...but otherwise intended to be spec-compliant). intel/xvec Speaking as a long-time C++ developer...I wasn't uninterested in contracts (which I've known about since the days of Bertrand Meyer flogging them in Eiffel), but I agree with the sentiment here that the SIMD efforts were considerably more interesting.

If anyone at @inteldevs @IntelAI could verify my performance / questions here: torch-xpu-ops#6019 - that would be great! I know i'm leaving some theoretical performance on the table but made some improvements in some iterative cycles and have more to try.

Intel's NEO compute driver now runs on Apple Silicon Linux. An Arc Pro B60 over USB4 on an M1 Max shows up in OpenCL 3.0 and Level Zero. Required patching Intel’s driver, PR: compute-runtime#1045 @Intel @IntelGraphics @IntelAI

Small open-source win: a build bug I reported in intel/llvm (the SYCL/oneAPI compiler) was fixed today. AMD GPU builds failed because two parts of the build used different names for the same target. Thanks to Rafał Rudnicki at Intel for the fix. llvm#23531

Been using Intel Omni acceleration on B580 B70 in ComfyUI for a while now—pretty solid! Since I needed to do some video editing work, I had to switch my main workflow environment back to Windows. I’ve been following the official llm-scaler/omni/ repo for a bit, and they’ve done a lot of validation and support specifically for Windows ComfyUI users. Component Structure I tried building it myself to run on both the Arc B580 and B70, and it compiled smoothly on both—with noticeable performance improvements. Later, I ran a side-by-side benchmark at work comparing the omnixpu accelerated environment with the native pytorchxpu environment. Here are the log results: Krea2Edit H3-Fl2va, 10s While the official repo currently targets BMG (Battlemage) architecture GPUs, you can already find DG2 (Alchemist) community builds available. B-series portion (BMG) B580 B60 B65 B70 from intel official kernel：github.com/intel/llm-scaler/tree/main/omni/omni_x… comfyui-omnixpu：github.com/intel/llm-scaler/tree/main/omni/ComfyU… aimdo xpu provider： xiangyuT/comfy-aimdo-xpu kitchen xpu provider：xiangyuT/comfy-kitchen-xpu A-series portion（dg2）A770 from github kernel：Blackwood416/omni-xpu-kernel comfyui-omnixpu：Blackwood416/ComfyUI-OmniXPU aimdo xpu provider： Blackwood416/comfy-aimdo-xpu (Just a quick note: the DG2 build bypasses kitchenxpu and injects operator routing directly into the omnixpu plugin).

Настройка и пример работы LLM на встроенном NPU мини-компьютера с Intel Core Ultra 5 226V Подопытный - мини-ПК Ninkear L20 на Intel Core Ultra 5 226V с 16 ГБ памяти. В статье будет установка и настройка OpenVINO, запуск Qwen3-8B на NPU, замеры скорости и мощности по счётчикам самого процессора и сравнение с дорогой видеокартой RTX 5070 Ti. Плюс практическая часть: обработка фотографий, 3D-рельеф из фото, озвучка книг TTS, Blender и печатная плата. Всё работает локально, без утечек данных в интернет и без оплаты подписок. В новых процессорах Intel Core Ultra появился третий вычислитель - нейронный процессор, NPU. Маркетинг обещает «ИИ-компьютер», но живых примеров обычно два: размытие фона в видеозвонке и Copilot. Мне стало интересно другое. Можно ли запустить на NPU настоящую языковую модель (LLM), сколько она выдаёт токенов в секунду и сколько при этом потребляет? Также мне интересно, что же получится, если загрузить сразу все три блока процессора: NPU, встроенную графику и обычные ядра. Постараюсь разобраться и подробно все рассказать. Начну с писания этого мини-ПК. Ninkear L20 построен на Intel Core Ultra 5 226V (Lunar Lake) с 16 ГБ памяти LPDDR5X-8533 на корпусе процессора. Рабочий диапазон мощности 17-37 Вт. Внутри три разных вычислителя: CPU на 8 ядер (4 производительных + 4 энергоэффективных). Универсален, но на нейросетях медленный: мало параллельных блоков, высокая частота, высокое энергопотребление на операцию. iGPU Intel Arc 130V (в терминах Intel и PyTorch XPU, в OpenVINO это GPU). Архитектура Xe2, сотни параллельных вычислителей, аппаратное умножение матриц. Самый быстрый блок для крупных нейросетей: языковых моделей, Stable Diffusion, длинных промптов. NPU Intel AI Boost четвёртого поколения, по данным Intel до 40 TOPS. Узкий специалист: умножение матриц в INT8 и FP16 на низкой частоте и при малом напряжении. Не умеет динамические формы данных, требует долгой первой компиляции, поддерживает не все операции. У всех трёх блоков общая оперативная память: своей видеопамяти у графики нет, своего ОЗУ у NPU тоже. Модель не нужно копировать между устройствами, но шина памяти одна на всех. При одновременной работе это видно. Чем NPU отличается от Arc 130V на практике. Графика быстрее на языковой модели вдвое. NPU выигрывает, когда задача длинная, нагрузка неполная и важны тишина и ватты: Фоновая обработка (поток с камеры, пакет фотографий, пересказ документов) на NPU добавляет к простою 1-2 Вт (огромная разница по потреблению, если смотреть ту же RTX 5070 Ti, подходит для случаев, когда нужно не срочно). Графика и процессор свободны для основной работы, будь то Blender, браузер или сборка проекта. NPU загружен на 99%, процессор 7%, графика 2%: остальная система свободна Вентилятор не раскручивается: шум остаётся на уровне простоя, 22-24 дБ, тогда как с графикой и процессором 33-34 дБ (для меня также критично - шум не раздражает). Шум L20 при разной нагрузке (замер шумомером): NPU не отличается от простоя NPU, графика и процессор в цифрах Для сравнения я взял одну и ту же языковую модель Qwen3-8B в 4-битном сжатии (OpenVINO GenAI 2026.4). Запрос - 77 токенов, ответ - 256, жадная генерация, засчитывается второй прогон. Мощность - среднее по счётчику RAPL всего кристалла (CPU + GPU + NPU + контроллер памяти) за время генерации. Скорость генерации на трёх вычислительных устройствах Qwen3-8B INT4 NPU GPU Arc 130V CPU Генерация, ток/с 10,7 21,2 10,0 Первый токен, с 1,7 0,17 0,46 Чтение промпта 1329 токенов, ток/с 360 1171 30 Мощность кристалла, Вт 15,4 20,6 16,0 Энергия на токен, Дж 1,52 1,01 1,64 Скажу прямо: Arc 130V быстрее NPU вдвое и даже тратит меньше энергии на токен 1,01 Дж против 1,52. Графика потребляет на треть больше мощности, но заканчивает работу вдвое быстрее. Мощность кристалла по времени: NPU, GPU, CPU и все три блока сразу Процессор по скорости генерации равен NPU, но читает длинный промпт в 12 раз медленнее и тратит больше всех. Привел данные в график к 1 токену и добавил для сравнения RTX 5070 Ti. Обратите внимание - подобный мини-ПК оказывается практически в 2-3 раза экономичнее, чем компьютер с полноценной дискретной видеокартой. Энергия на один токен: L20 и оценка для RTX 5070 Ti  Как это выглядит на большой задаче, например, «написать 10 000 токенов» (15-20 страниц текста). NPU делает её за 15,6 минуты и 4,2 Вт·ч, графика - за 7,9 минуты и 2,8 Втч. Разница в энергии 1,4 Втч, меньше заряда одного телефона. На неполной нагрузке NPU на треть экономичнее графики и в 4-10 раз экономичнее процессора. Специально делаю акцент - если задача не срочная, NPU позволяет отдать её в фон и не занимать графику. Обычно я ставлю пакетную обработку фото или генерацию моделей через LLM и оставляю его работать. Одна задача на трёх устройствах: время и энергия Где NPU выигрывает: параллельная работа. Если две нейросети запустить на одной графике, каждая работает вдвое медленнее. Если языковую модель перенести на NPU, нейросеть на графике сохраняет 92% своей скорости. А все три блока одновременно потребляют 27,5 Вт. Все три блока заняты: NPU 75%, графика 92%, процессор 62% Настройка OpenVINO Пара слов про настройку. Работает такая связка на базе OpenVINO - это открытый набор инструментов Intel для запуска нейросетей на CPU, GPU и NPU. Модель хранится в формате IR (.xml граф, .bin веса). Для каждого устройства есть плагин: он компилирует граф под конкретное железо. Для работы потребуется настроить драйверы (речь про NPU драйвер) и установить связку OpenVINO+Python и что еще требуется. NPU виден в Диспетчере устройств в разделе «Нейронные процессоры» как Intel(R) AI Boost. Драйверы NPU и графики берутся с сайта Intel (Intel Driver & Support Assistant ставит оба). У меня: NPU 32.0.100.5540, графика 32.0.101.8331. Со старым драйвером NPU многие модели не компилируются - это первое, что стоит обновить. Потребуется Python 3.12 с python.org. На каждый проект - своё виртуальное окружение, чтобы зависимости разных программ не конфликтовали: python -m venv C:\AI\npu\venv C:\AI\npu\venv\Scripts\activate pip install openvino openvino-genai nncf huggingface_hubsourcecraft.dev Здесь: openvino - среда выполнения, openvino-genai - готовые конвейеры для языковых моделей, Stable Diffusion и распознавания речи, nncf - сжатие моделей в INT8/INT4, huggingface_hub - скачивание моделей (команда hf). Дальше - проверка устройств и свойств NPU. python -c "import openvino as ov; c=ov.Core(); print(c.available_devices); print(c.get_property('NPU','FULL_DEVICE_NAME'), c.get_property('NPU','NPU_DRIVER_VERSION'))"sourcecraft.dev OpenVINO видит CPU, GPU и NPU Выбор устройства в коде. Общего переключателя в системе нет: устройство задаёт программа. Варианты: CPU, GPU, NPU - конкретное устройство. Две видеокарты Intel получают имена GPU.0 и GPU.1; AUTO - OpenVINO выбирает сам; HETERO:NPU,CPU - неподдерживаемые NPU операции уходят на процессор. import openvino as ov core = ov.Core() model = core.read_model("model.xml") compiled = core.compile_model(model, "NPU", {"CACHE_DIR": r"C:\AI\ov_cache", "PERFORMANCE_HINT": "LATENCY"}) result = compiled(input_tensor)[0]sourcecraft.dev Здесь: PERFORMANCE_HINT задаёт стратегию: LATENCY - один запрос как можно быстрее, THROUGHPUT - максимум кадров в секунду через несколько параллельных запросов. Тест NPU на 99% выше сделан именно с THROUGHPUT и очередью из 8 запросов. Настройка LLM модели для работы с NPU Первая компиляция для NPU долгая: Qwen3-8B - 97 секунд, Depth Anything - 30-40 секунд, ESRGAN - 12 минут. С CACHE_DIR скомпилированная модель сохраняется на диск, и следующий запуск занимает секунды (Qwen3-8B 14,6 с). Дальше отмечу, что NPU принимает только фиксированный размер входа. Для картинок модель экспортируют сразу под нужное разрешение (например, 1×3×518×518) или вызывают model.reshape(...) перед компиляцией. Для языковых моделей это делает OpenVINO GenAI: достаточно задать максимальную длину промпта и ответа (см. ниже). Готовые модели для NPU лежат на Hugging Face в коллекции OpenVINO. Для NPU нужны варианты -int4-cw-ov: веса в 4 бита, симметрично, одним масштабом на канал. Свою модель в этом формате можно собрать инструментом optimum-cli (пакет optimum-intel): optimum-cli export openvino -m Qwen/Qwen3-4B --weight-format int4 --sym --group-size -1 --ratio 1.0 Qwen3-4B-int4-cw-ovsourcecraft.dev Я пользовался готовыми моделями, эту команду привожу для полноты. Продолжаю настройку: hf download OpenVINO/Qwen3-8B-int4-cw-ov --local-dir C:\AI\models\Qwen3-8B-int4-cw-ov import openvino_genai as og pipe = og.LLMPipeline(r"C:\AI\models\Qwen3-8B-int4-cw-ov", "NPU", CACHE_DIR=r"C:\AI\ov_cache", MAX_PROMPT_LEN=2048, MIN_RESPONSE_LEN=512) cfg = og.GenerationConfig(); cfg.max_new_tokens = 400 print(pipe.generate("Перескажи текст в пяти пунктах: ... /no_think", cfg))sourcecraft.dev MAX_PROMPT_LEN и MIN_RESPONSE_LEN нужны только NPU: под эти размеры GenAI «нарезает» модель. Приписка /no_think выключает у Qwen3 режим размышлений. Для удобства я сделал окно чата с выбором устройства, в котором видны скорость и мощность: Qwen3-8B на NPU: 1,8 с до первого токена, 15,8 ток/с, кристалл 17,3 Вт Во время генерации NPU загружен примерно на две трети: языковая модель упирается в скорость памяти. Загрузка NPU во время теста Синтез речи Qwen3-TTS на NPU Qwen3-TTS - синтез речи на основе языковой модели (1,7 млрд параметров), с встроенными голосами и клонированием голоса по образцу. У Intel есть официальный пример запуска Qwen3-TTS в OpenVINO (ноутбук qwen3-tts в репозитории openvino_notebooks). Я взял из него конвертер и конвейер. Для Qwen3-TTS нужен PyTorch для конвертации, нужно настроить дополнительное окружение: python -m venv C:\AI\tts\venv C:\AI\tts\venv\Scripts\activate pip install torch==2.8.0 torchaudio==2.8.0 --index-url download.pytorch.org pip install qwen-tts==0.1.1 openvino nncf soundfile git clone --depth 1 openvinotoolkit/openvino_notebooks hf download Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice --local-dir C:\AI\models\Qwen3-TTS-1.7B-CustomVoice hf download Qwen/Qwen3-TTS-12Hz-1.7B-Base --local-dir C:\AI\models\Qwen3-TTS-1.7B-Basesourcecraft.dev CustomVoice - модель со встроенными голосами, Base - для клонирования голоса по образцу. Каждая весит около 4,2 ГБ. Конвертация в IR - функцией из примера Intel, около 3 минут на модель: cd openvino_notebooks\notebooks\qwen3-tts python -c "from qwen_3_tts_helper import convert_qwen3_tts_model as c; c(r'C:\AI\models\Qwen3-TTS-1.7B-CustomVoice', r'C:\AI\models\Qwen3-TTS-CV-OV')"sourcecraft.dev Процесс запуска генерации: from qwen_3_tts_helper import OVQwen3TTSModel import soundfile as sf tts = OVQwen3TTSModel.from_pretrained(r"C:\AI\models\Qwen3-TTS-CV-OV", device="GPU") wavs, sr = tts.generate_custom_voice(text="Глава первая. ...", speaker="aiden", language="Russian", temperature=0.9, top_k=50, repetition_penalty=1.05, max_new_tokens=2048) sf.write("chapter1.wav", wavs[0], sr)sourcecraft.dev Параметры по умолчанию модели: temperature 0,9, top_k 50, repetition_penalty 1,05. За один проход модель озвучивает до 8192 токенов (около 11 минут звука), поэтому книгу я режу на куски около 1500 символов по абзацам и склеиваю результат. Пример Intel официально исключает NPU, и проверка это подтвердила. Основная часть модели (talker) и вокодер имеют динамические формы и KV-кэш, их компилятор NPU не принимает. Но в модели есть «предсказатель кодов» (code predictor), который вызывается 15 раз на каждый кадр звука. Я переэкспортировал его в статическую форму без состояния (вход 1×16×2048), и он заработал на NPU с тем же результатом, что в PyTorch. Программа озвучки: основная модель на графике, предсказатель кодов на NPU Qwen3-TTS 1.7B RTF Всё на графике (статический предсказатель) 1,73 Графика + предсказатель на NPU 2,0-2,1 Процессор + предсказатель на NPU 6,7 Всё на процессоре 8,8-9,9 RTF во сколько раз генерация дольше звука. Самый быстрый вариант - это графика ARC 130V. Вариант «процессор + NPU» в полтора раза быстрее чистого процессора и не трогает графику вовсе - удобно для озвучки книги ночью, пока компьютер занят чем-то ещё. Разборчивость проверялась распознаванием речи Whisper: 95-100% слов во всех вариантах. GIMP и нейросети OpenVINO Intel выпускает бесплатный набор плагинов для GIMP 3: увеличение разрешения, сегментация, Stable Diffusion (генерация и инпейнтинг) и FastSD. Устройство выбирается в окне плагина. Установка подобным образом: winget install --id GIMP.GIMP.3 --version 3.0.8.2 --scope user mkdir C:\AI\GIMP_OpenVINO cd C:\AI\GIMP_OpenVINO git clone --branch 3.3.0 intel/openvino-ai-plugins-gimp openvino-ai-plugins-gimp\install.bat gimpenv3\Scripts\python.exe -m pip install "optimum-intel==2.0.0" gimpenv3\Scripts\python.exe openvino-ai-plugins-gimp\model_setup.pysourcecraft.dev Версию GIMP я взял 3.0.x: на ней Intel проверяет плагины. install.bat создаёт для плагинов отдельное окружение gimpenv3 и копирует их в %APPDATA%\GIMP\3.0\plug-ins. model_setup.py - меню загрузки моделей Stable Diffusion. Super Resolution и сегментация входят в комплект. Модели инпейнтинга меню скачивает целым репозиторием (14 и 19 ГБ) и конвертирует сам. Я поступил экономнее: скачал только FP16-веса и сконвертировал той же командой, что вызывает плагин, положив результат в его папку моделей: hf download stable-diffusion-v1-5/stable-diffusion-inpainting --include ".json" ".txt" "*fp16.safetensors" gimpenv3\Scripts\optimum-cli export openvino --model <папка_скачанной_модели> --variant fp16 --weight-format fp16 --task image-to-image %USERPROFILE%\openvino-ai-plugins-gimp\weights\stable-diffusion-ov\stable-diffusion-1.5\inpaintingsourcecraft.dev Для SDXL - то же с репозиторием diffusers/stable-diffusion-xl-1.0-inpainting-0.1 и папкой stable-diffusion-xl\inpainting. Слой → OpenVINO-AI-Plugins: четыре плагина Нюанс: плагины работают только в интерактивном режиме. Из пакетного режима GIMP они ничего не делают. Устройство выбирается списком: CPU, GPU, NPU Тест апскейлинга 741×500 → 1482×1000 пх. Super Resolution на NPU, результат - новым слоем Модель CPU GPU NPU Super Resolution sr_1033 151 мс 32 мс 46 мс Super Resolution ESRGAN ×4 64 с 1,0 с 1,2 с Сегментация deeplabv3 200 мс 7,6 мс 19,5 мс Сегментация sseg-adas-0001 491 мс 31 мс неверный результат SD 1.5 Inpainting, 512×512, 20 шагов 284 с 25 с не компилируется SDXL Inpainting, 1024×1024, 20 шагов - 107 с не компилируется Для NPU в GIMP подходят Super Resolution и сегментация deeplabv3. Модель sseg-adas-0001 на NPU работает без ошибок, но результат неверный: с процессором совпадают 2,3% пикселей. Stable Diffusion - только на графике, в режиме Power Mode - Best performance. Так что для тяжелых генераций имеет смысл подключить eGPU (но это уже отдельная история). 3D-рельеф из фото: Depth Anything на NPU Depth Anything V2 строит карту глубины по одному фото. Из неё моя программа Depth & Relief Studio делает рельеф с основанием и рамкой и экспортирует STL для 3D-печати. Это идеальная задача для NPU: модель картиночная, размер входа фиксированный, а пакет из сотни фотографий можно поставить в фон. Настройка конвертации модели в IR под NPU (окружение с torch и transformers): import torch, openvino as ov from transformers import AutoModelForDepthEstimation class DepthOnly(torch.nn.Module): def init(self, m): super().init() self.m = m def forward(self, x): return self.m(pixel_values=x).predicted_depth m = AutoModelForDepthEstimation.from_pretrained("depth-anything/Depth-Anything-V2-Small-hf").eval() with torch.no_grad(): ovm = ov.convert_model(DepthOnly(m), example_input=torch.zeros(1, 3, 518, 518), input=[1, 3, 518, 518]) ov.save_model(ovm, "small_fp16_518/model.xml", compress_to_fp16=True)sourcecraft.dev Фиксированный вход 518×518 (кратно 14 - размеру патча ViT) сразу делает модель пригодной для NPU. Сжатие в INT8 инструментом NNCF, без переобучения. Для калибровки хватило восьми моих фото рельефов, размноженных отражениями и кадрированиями до 88 примеров. tensors - список этих примеров, подготовленных так же, как для инференса: размер 518×518, нормализация ImageNet, массив 1×3×518×518: import nncf q = nncf.quantize(ov.Core().read_model("small_fp16_518/model.xml"), nncf.Dataset(tensors), model_type=nncf.ModelType.TRANSFORMER, subset_size=len(tensors)) ov.save_model(q, "small_int8_518/model.xml")sourcecraft.dev FP16 против INT8 на восьми фото рельефов: время, энергия на кадр и точность Depth Anything V2 Small CPU GPU NPU FP16, мс на кадр 659 18,1 28,0 INT8, мс на кадр 336 18,1 23,6 INT8, Дж на кадр 3,58 0,31 0,36 INT8, отличие от FP16 (рельеф 5 мм) 0,063 мм 0,065 мм 0,062 мм INT8 уменьшает модель с 47 до 24 МБ, ускоряет NPU на 16% и процессор вдвое. Отличие от FP16 - в среднем 0,06 мм на рельефе высотой 5 мм, меньше слоя FDM-печати. Фото, FP16 и INT8 на NPU, разница (усилена в 5 раз) Разница собрана по резким контурам, а не по всей поверхности: Depth & Relief Studio: модель INT8, устройство NPU, карта высот парусника Рельеф Парусник 90 × 120 мм, STL прошёл проверку на замкнутость, можно отправлять на принтер для FDM печати. Парусник на основании со скруглёнными углами под фрезеровку и 3D печать Такой сценарий работы «поставить и забыть» удобен, особенно если в очереди много файлов для обработки: в программе есть пакетный режим (папка с фото → папка с картами глубины). На NPU в INT8 он идёт в фоне на 24 мс и 0,36 Дж на кадр, вентилятор при этом не слышно, а графика свободна для Blender или слайсера. Сравнение с Tesla V100 и флагманскими видеокартами Я не так давно рассказывал про приобретение Tesla V100 (и в качестве eGPU, и для домашнего ИИ-сервера). Для сравнения вот такой график. Указываю паспортную мощность видеокарт (реально могут быть другие цифры, нужно также прогонять на тестах для более детального сравнения), рядом с измеренной мощностью кристалла L20: Tesla V100 - 250 Вт (PCIe) или 300 Вт (SXM2), RTX 5070 Ti - 300 Вт, RTX 4090 - 450 Вт, RTX 5090 - 575 Вт. И это одна карта, без процессора, памяти и блока питания. L20 на языковой модели потребляет 15-21 Вт на кристалл, все три блока сразу - 27,5 Вт, фоновая задача на NPU - плюс 2 Вт к простою. Выводы NPU медленный. Языковая модель на нём работает вдвое медленнее, чем на Arc 130V, и тратит на токен даже больше энергии. Если результат нужен сейчас - считайте на графике. NPU экономный в фоне. На неполной нагрузке он добавляет к простою 1-2 Вт - это на треть меньше графики и в 4-10 раз меньше процессора. NPU почти не шумит. При работе нейросети на NPU шум L20 остаётся на уровне простоя (22-24 дБ). С графикой и процессором - 33-34 дБ. NPU работает параллельно. Отдав ему одну нейросеть, вы сохраняете графику и процессор: задача на графике теряет всего 8% скорости. Не всё запускается на NPU. Stable Diffusion, основная часть Qwen3-TTS и модели с динамическими формами не компилируются. Некоторые модели (sseg-adas-0001) дают неверный результат без ошибок - проверяйте на эталоне. Кэш и статические формы - обязательны. Без CACHE_DIR каждый запуск начинается с минутной компиляции. INT8 для картиночных моделей - да. Depth Anything в INT8 на NPU быстрее на 16%, вдвое меньше и почти не отличается от FP16. Итог простой: NPU в L20 - не ускоритель «для скорости», а тихий экономичный помощник. Подходящий вариант, чтобы поставить задачу и забыть, если результат не нужен срочно: пересказ документов, пакетная обработка фото в рельефы, озвучка книги в связке с процессором. Мини-ПК при этом не слышно, а графика и процессор свободны для основной работы. А какие фоновые задачи вы бы отдали NPU на своём компьютере?

Agent Context A/B Testing with Intel Dokimi Hands-on A/B agent context testing using dokimi from Intel. !Image description Introduction What is Agent Context A/B Testing? Agent Context A/B Testing is a rigorous evaluation methodology used to measure how different pieces of context (such as system prompts, documentation, user profiles, or specialized agent skills) impact an AI model's performance on specific tasks. Rather than guessing which context configuration works best, this approach treats context as a variable in a controlled experiment, comparing a baseline against one or more enhanced "arms". Key Components of the Evaluation Flow The A/B testing pipeline generally follows a structured, multi-step process: 1. Questions / Golden Sets: The process starts with a standardized set of test prompts, questions, or synthetic personas that represent real-world use cases. 2. Execution Arms: The same base model answers every question across different context "arms" (e.g., a baseline arm versus an arm enhanced with specific documentation, user profiles, or plugins). Agentic arms also record whether and how tools were utilized. 3. Automated Judging: A separate, dedicated LLM acts as a judge, scoring all generated answers (typically on a 0–100 scale) across multiple core dimensions such as accuracy, completeness, conciseness, and novelty impact. Cross-checks (such as RAGAS) are often integrated to ensure scoring reliability. 4. Statistical Significance & Results: The framework computes performance deltas (Δ=B−AΔ=B−A) and runs statistical significance tests (such as calculating p*p*-values) to determine whether an observed performance boost is real or merely statistical noise. 5. Scorecard & Decision Gates: Results are compiled into a final scorecard reporting the value added by the new context (e.g., worth +X+X on model M*M*), guiding developers on whether to ship it or cut it. Why Use Context A/B Testing? - Multi-Dimensional Visibility: It provides a comprehensive radar view of model behavior, ensuring that an improvement in accuracy doesn't inadvertently hurt conciseness or introduce hallucinations. - Data-Driven Decisions: It replaces subjective tuning with rigorous statistical validation, helping engineering teams optimize prompts and agent context confidently. > First things first, what is "dokimi"? > Excerpts from the project's GitHub and documentation: Dokimi — A/B testing for agent context !Image description **Documentation: intel.github.io — guides, plus a CLI reference and an API reference generated from the code. > dokimi — Greek δοκιμή, "test, proof". The name is the method: an artifact does not get trusted because it was written or because it is popular, it gets trusted because it passed a test that could have failed. Skills, instructions, docs, MCP servers and repository guidance are cheap to write and easy to over-claim. Dokimi tests each one like an experiment: change one thing, keep everything else fixed, run the same question or task set, and report the delta together with its p-value. An artifact ships with the scorecard that earned it, a deliberate contrast to popularity-ranked marketplaces, which structurally bury niche HPC and numerical-accuracy tooling. What measuring shows (evidence): - Much of a skill repeats what the model already knows, and the rest is exact detail. For claude-opus-5 under lenient grading, 70% of what a skill says the model already produces unprompted. Under strict grading, which also checks qualifiers and exact values, only 22% is already known and 38% is still missing even with the skill in context. Read the two gradings together. - Models believe their context, even when it is wrong. A plausible wrong value planted in a skill is repeated 94% of the time. - Value depends on the model. What a small model needs, a frontier model may already know, so every verdict is per model. The idea in three points: - An agent is more than its model. It is model + the context you give it: docs, skills, MCP servers, system prompts (agent profiles), plugins. - All of that is cheap to write — and easy to over-claim. Does it really help, or does it just add tokens? - So we test it like an experiment: change one thing, keep everything else fixed, measure the delta — and check it is statistically significant. What it measures 1. Does it help? Enabled vs disabled arms - An arm is one context condition. Every arm runs the same question or task set against the same model, and the report gives the per-arm delta against the baseline with paired statistics. Arms are given as specs (dokimi arms run --arms …): | Arm | What the agent gets | | ---------------------- | ------------------------------------------------------------ | | `baseline` | nothing extra | | `docs:<source>` | product documentation (local Markdown, URLs, Context7) | | `mcp:<server>` | an MCP documentation server it can call | | `skill:<path>` | one skill, its instructions in context | | `skill-agent:<path>` | one skill offered by name and description; the model must decide to load it | | `skill-catalog:<root>` | a whole skill catalog, to measure whether the right skill gets selected | | `profile:<path>` | an agent persona / system prompt | | `guidance:none | raw | | `guidance:rev:<rev>` | the same repository with the guidance files of another revision, such as a PR's `AGENTS.md` (repository mode) | | `patch:<file>` | the repository with a unified diff applied on top of its own guidance: a new script, a Makefile target (repository mode) | The same arms drive question answering (LLM-as-judge with judge-validity checks), executable Docker coding tasks through Codex, Claude Code, Harbor or BenchFlow harnesses (dokimi tasks run), and file/line localization (dokimi explore run). Results roll up per subject (dokimi subjects run): a skill, MCP server, doc source, profile, bundle or repository, each with a scorecard. 2. What does it add? Novel vs known content An arm delta says whether an artifact helps; it does not say which parts. dokimi novelty analyze --artifact skill:<path>|text:<path> splits the artifact into knowledge atoms and probes each one against the model with and without the artifact. Each atom comes out added (new to the model), redundant (the model already knew it), degraded (the artifact broke something the model knew) or still missing (stated but not picked up). text: takes any file, so the same analysis runs on a documentation page or a repository's AGENTS.md. The output is per (artifact, model) pair, with shortening candidates (novelty shorten) and a check that the artifact can be selected among competitors at all (novelty routing). See skill-novelty.md. 3. Repositories: scan the guidance, then measure agents working in them A repository is a subject in its own right, described by a repo-eval.yaml manifest it owns: - dokimi repo scan (L0, no LLM): do the links, paths, identifiers, commands and build labels the guidance names exist in the tree? - dokimi repo budget (no LLM): how many characters of guidance and skill listing every model call pays for at start-up, what loads lazily or on demand, and which AGENTS.md files a CLAUDE.md turns off. - dokimi repo reach (L1): which guidance files does a given harness actually load? - dokimi repo inspect (static, no LLM): which instruction files, checks, capability surfaces and risky hooks or scripts the repository offers an agent, with findings per stage. - dokimi repo run: run an agent per (task, arm, model, repetition) inside the repository's image, grade each run with the repository's own tests, and dokimi repo report the per (task, arm, model) table. With the guidance:* arms this measures what the repository's agent guidance does to the agent's work; dokimi repo compare puts each arm against a baseline arm, paired by task. !Image description > End of Excerpts from the project’s GitHub and documentation --- Implementation of the Application Discovering the 'dokimi' repository naturally piqued my interest. Leveraging Bob, I developed an end-to-end application to evaluate and demonstrate its core capabilities in action. !Image description Overall Architecture of the Implementation The Dokimi Agent Context A/B Testing Platform is structured around a modular, full-stack architecture that combines a FastAPI backend with a responsive single-page dashboard built using the Carbon Design System theme. At its core, the system incorporates Intel's Dokimi evaluation methodology—enforcing paired on/off arm comparisons, knowledge atom decomposition, and rigorous statistical significance testing via paired Student's t-tests and Holm-Bonferroni corrections. The platform supports dual-tier persistence, keeping built-in demonstration fixtures immutable in memory while storing dynamic ad-hoc use-cases in persistent JSON storage (data/adhoc_usecases.json). Furthermore, evaluation requests are dispatched through a flexible execution layer capable of interfacing with domain-specific mock engines, LiteLLM providers (such as OpenAI and Anthropic), and local LLM runtimes like Ollama and llama.cpp, while real-time progress is streamed to the frontend via Server-Sent Events (SSE). While the application ships with built-in mock fixtures out of the box, it fully supports dynamic ad-hoc use-case submissions. The platform also offers flexible LLM inference support—allowing you to seamlessly run local models via Ollama or llama.cpp, or connect to cloud-based LLM providers, all configurable directly within the application. It incorporates Intel's Dokimi evaluation principles: 1. Paired On/Off Arm Comparisons: Every context arm is evaluated against the exact same question/scenario sets to compute delta scores. 2. Knowledge Atom Decomposition: Context is evaluated not merely on volume, but whether it adds novel facts, repeats redundant knowledge, or degrades accuracy. 3. Statistical Significance Testing: Paired Student's t-test with Holm-Bonferroni family-wise error rate corrections. Technical and Functional Implementation Details Context Arms Under Test | Arm ID | Spec Type | Injected Payload | Purpose | | ------------- | ----------------- | ----------------------- | ------------------------------------------------------------ | | `baseline` | `baseline` | Empty (Unprompted) | Establishes model foundational performance baseline. | | `arm_docs` | `docs:local:path` | `standard_runbook.md` | Measures value of standard static procedural documentation. | | `arm_profile` | `profile:path` | `sre_expert_profile.md` | Measures value of domain persona & behavioral guidelines. | | `arm_skill` | `skill:path` | `SKILL.md` | Measures value of precision action protocols and remediation scripts]. | Dokimi Evaluation Metrics - Mean Score (S∈[0,1]*S*∈[0,1]): Weighted composite of Accuracy (45%), Grounding Completeness (40%), and Conciseness (15%). - Score Delta (ΔΔ): Difference in mean score between treatment arm and baseline. - Paired t*t*-test (p*p*-value): Tests null hypothesis that context addition produces no difference. - Holm-Bonferroni (α=0.05*α*=0.05): Controls family-wise error across multiple simultaneous arms. - Novel Knowledge Atoms: Measures count of verified facts introduced beyond base model knowledge. dokimi-agent-ab-testing/ ├── app/ │ ├── main.py # Application entry point & FastAPI setup │ ├── core/ │ │ ├── config.py # Settings and environment configuration │ │ └── models.py # Pydantic domain models & schemas │ ├── services/ │ │ ├── dokimi_engine.py # Dokimi evaluation & statistical runner │ │ ├── progress_manager.py # Real-time progress tracking & SSE streamer │ │ └── llm_service.py # LLM dispatcher (Mock & real providers) │ ├── api/ │ │ └── router.py # API routes for experiments, variants, chat, tasks │ ├── templates/ │ │ └── index.html # Single-page dashboard UI template │ └── static/ │ ├── css/style.css # IBM Carbon-inspired styles │ └── js/app.js # Dynamic UI logic & ECharts integration ├── data/ │ ├── docs/ # Markdown runbooks for doc arms │ ├── skills/ # Skill definitions for skill arms │ ├── profiles/ # Persona prompts for profile arms │ └── eval_sets/ # Standardized evaluation questions ├── scripts/ │ ├── start.sh # Detached launch script with URL output │ ├── stop.sh # Graceful shutdown script │ ├── cleanup.sh # Clean venvs, cache, and build files │ └── clean_containers.sh # Remove built container images ├── Docs/ │ ├── Architecture.md # This document │ ├── Quickstart.md # Step-by-step setup and execution guide │ └── AdHoc_UseCases.md # Guide and API specs for ad-hoc use-case submissions ├── tests/ # Pytest test suite ├── Dockerfile & Containerfile ├── requirements.txt └── README.md What the Application Demonstrates? !Image description Core Concepts When building AI coding and operations agents, developers often inject large prompt templates, extensive markdown documentation, or complex tool suites. However, without systematic testing, it is impossible to know whether that extra context actually improves performance or merely adds latency and cost. The platform implements Intel's Dokimi evaluation principles: - Treatment Arms: Different context configurations tested in parallel: - baseline: Unprompted model baseline. - arm_docs: Static procedural documentation injection. - arm_profile: Domain persona and behavioral guidelines. - arm_skill: Precision action protocols and step-by-step remediation commands. - arm_mcp: Model Context Protocol server capabilities. - Paired On/Off Arm Testing: Every arm is tested against the exact same scenario queries under identical conditions. - Statistical Significance: Computes paired Student's t-test p-values with Holm-Bonferroni multi-arm corrections (α=0.05*α*=0.05). - Knowledge Atom Decomposition: Distinguishes novel actionable facts from redundant base knowledge. Once the application is launched, several URLs and links are available to demonstrate Dokimi's functionalities: ===================================================================== ✅ Dokimi Agent A/B Testing Platform is LIVE and HEALTHY! 📌 Process PID: 63870 🌐 Web Dashboard URL: http://127.0.0.1:8000 📚 API Swagger Docs: http://127.0.0.1:8000/docs 📖 API Redoc: http://127.0.0.1:8000/redoc ❤️ Health Check: http://127.0.0.1:8000/health 🎯 Use-Cases Endpoint: http://127.0.0.1:8000/api/use-cases 🧬 Variants Endpoint: http://127.0.0.1:8000/api/variants 📋 Questions Endpoint: http://127.0.0.1:8000/api/questions 📊 Experiments API: http://127.0.0.1:8000/api/experiments 📄 Application Logs: output/app.log ===================================================================== The platform navigation tabs provide full control over the evaluation lifecycle: 1. 📊 A/B Experiment Dashboard: Run paired evaluations, view top performing arms, delta improvements, statistical significance badges, and interactive ECharts (Bar & Radar). !Image description 2. 🎯 Use-Case Library: Browse immutable built-in fixtures (SRE Incident Response, Cloud Security Audit) and submit dynamic ad-hoc use-cases. 3. 💬 Dual Agent Chat Playground: Query two context arms side-by-side in real-time. !Image description 4. 🧬 Context Arms & Variants: Inspect and configure custom system prompts, documentation payloads, and skill protocols. !Image description 5. 📋 Evaluation Question Set: Inspect golden evaluation questions and ground truth assertion keywords. !Image description 6. You can submit a custom domain use-case directly from the Web UI or via the REST API, all documented. !Image description !Image description --- - End-to-End Ad-Hoc Use-Case Submission & Evaluation """ End-to-End Dokimi A/B Testing Workflow: 1. Submits an ad-hoc use-case (Kafka consumer group rebalancing) 2. Triggers a full Dokimi A/B evaluation across all context arms 3. Inspects statistical significance (p-values, Holm-Bonferroni) and score deltas 4. Cleans up the ad-hoc use-case """ import json import time import urllib.request import urllib.error BASE_URL = "http://127.0.0.1:8000" def http_post(endpoint: str, data: dict) -> dict: url = f"{BASE_URL}{endpoint}" req = urllib.request.Request( url, data=json.dumps(data).encode("utf-8"), headers={"Content-Type": "application/json"}, method="POST" ) with urllib.request.urlopen(req) as response: return json.loads(response.read().decode("utf-8")) def http_get(endpoint: str) -> dict: url = f"{BASE_URL}{endpoint}" req = urllib.request.Request(url, method="GET") with urllib.request.urlopen(req) as response: return json.loads(response.read().decode("utf-8")) def http_delete(endpoint: str) -> dict: url = f"{BASE_URL}{endpoint}" req = urllib.request.Request(url, method="DELETE") with urllib.request.urlopen(req) as response: return json.loads(response.read().decode("utf-8")) def main(): print("=" * 70) print("🧪 Dokimi A/B Testing Platform - Programmatic Evaluation") print("=" * 70) # 1. Define Ad-Hoc Use-Case use_case_payload = { "name": "Kafka Consumer Lag & Rebalancing Storm Triage", "description": "Evaluate context arms on diagnosing consumer rebalance loops and partition skew.", "parameters": { "domain": "Event Streaming / Messaging", "cluster_type": "Apache Kafka / Strimzi", "alpha": 0.05 }, "expected_outputs": [ "Diagnose max.poll.interval.ms timeout causes", "Tune session.timeout.ms and heartbeat.interval.ms", "Provide cooperative-sticky assignor configuration" ], "scenarios": [ { "id": "kafka_sc_01", "prompt": "Consumer group 'order-processing' is stuck in continuous rebalancing loop. Lag is growing by 5k msg/sec. How to mitigate?", "expected_topics": [ "Check max.poll.interval.ms vs message processing time", "Switch to CooperativeStickyAssignor to prevent stop-the-world rebalance", "Inspect GC pauses on consumer JVM instances", "Scale out partitions and consumers proportionally" ], "category": "Consumer Rebalance" }, { "id": "kafka_sc_02", "prompt": "Two partitions in topic 'payments' have 20x higher lag than all other partitions. How to rebalance data distribution?", "expected_topics": [ "Inspect partition key hashing skew", "Check for hot keys in upstream producer payload", "Verify consumer group partition assignment with kafka-consumer-groups.sh" ], "category": "Partition Skew" } ] } # 2. Submit Use-Case print("\n1. Submitting Ad-Hoc Use-Case...") use_case = http_post("/api/use-cases/submit", use_case_payload) uc_id = use_case["id"] print(f" ✅ Registered: '{use_case['name']}' (ID: {uc_id})") # 3. Trigger Dokimi Experiment Run print(f"\n2. Executing Dokimi Paired A/B Experiment against use-case '{uc_id}'...") exp_payload = { "name": "Kafka Rebalance Context Optimization", "use_case_id": uc_id, "model": "mock-model", "provider": "mock" } start_time = time.time() experiment = http_post("/api/experiments/run", exp_payload) elapsed = time.time() - start_time print(f" ✅ Experiment Complete (ID: {experiment['id']}) in {elapsed:.2f}s") print(f" 📢 Verdict: {experiment['summary_verdict']}\n") # 4. Display Results Table print(f"{'Arm Spec ID':<16} | {'Mean Score':<10} | {'Delta vs Base':<14} | {'p-value':<10} | {'Sig (p<0.05)':<12} | {'Novel Atoms':<12}") print("-" * 88) base_score = experiment["metrics_by_arm"]["baseline"]["mean_score"] for arm_id, m in experiment["metrics_by_arm"].items(): delta = m["mean_score"] - base_score delta_str = f"+{delta:.4f}" if delta >= 0 else f"{delta:.4f}" pval_str = f"{m['p_value']:.4f}" if m["p_value"] is not None else "— (Base)" sig_str = "✅ YES" if m["stat_significant"] else ("Base" if arm_id == "baseline" else "❌ NO") print(f"{arm_id:<16} | {m['mean_score']:<10.4f} | {delta_str:<14} | {pval_str:<10} | {sig_str:<12} | +{m['novel_atoms_added']:<11}") # 5. Clean Up Use-Case print(f"\n3. Cleaning up ad-hoc use-case '{uc_id}'...") del_res = http_delete(f"/api/use-cases/{uc_id}") print(f" ✅ Cleaned up: {del_res['status']}") print("=" * 70) if __name__ == "__main__": main() - Async Client with httpx import asyncio import httpx BASE_URL = "http://127.0.0.1:8000" async def run_async_evaluation(): async with httpx.AsyncClient(base_url=BASE_URL, timeout=30.0) as client: # 1. Health check health_resp = await client.get("/health") assert health_resp.status_code == 200 # 2. Submit use-case payload = { "name": "Cloud IAM Least Privilege Enforcement", "description": "Evaluate context arms on AWS/GCP wildcard permission pruning.", "parameters": {"domain": "Cloud Security", "alpha": 0.05}, "expected_outputs": ["Remove Action: *", "Enforce resource ARNs"], "scenarios": [ { "id": "iam_01", "prompt": "An IAM role has Action: 's3:*' on Resource: '*'. How to remediate to read-only access for bucket 'app-data'?", "expected_topics": [ "Replace 's3:*' with 's3:GetObject' and 's3:ListBucket'", "Scope Resource to 'arn:aws:s3:::app-data' and 'arn:aws:s3:::app-data/*'", "Validate using AWS Access Analyzer" ], "category": "IAM Security" } ] } res = await client.post("/api/use-cases/submit", json=payload) uc = res.json() print(f"Registered use-case: {uc['id']}") # 3. Run evaluation exp_res = await client.post( "/api/experiments/run", json={ "name": "IAM Security Eval", "use_case_id": uc["id"], "model": "mock-model", "provider": "mock" } ) exp = exp_res.json() print(f"Top arm: {exp['summary_verdict']}") # 4. Clean up await client.delete(f"/api/use-cases/{uc['id']}") print("Cleaned up successfully.") if __name__ == "__main__": asyncio.run(run_async_evaluation()) - Fetch & Axios Integration const BASE_URL = "http://127.0.0.1:8000"; async function runDokimiUseCase() { try { // 1. Submit Ad-Hoc Use-Case const submitResponse = await fetch(`${BASE_URL}/api/use-cases/submit`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ name: "Postgres Connection Pool Saturation Drill", description: "Assess context arms on PgBouncer connection queuing and backend worker starvation.", parameters: { domain: "Database SRE", alpha: 0.05 }, expected_outputs: ["Configure transaction pooling", "Tune max_connections"], scenarios: [ { id: "pg_pool_01", prompt: "Postgres server reached max_connections (500). Applications receiving 'FATAL: remaining connection slots are reserved'. What is the immediate fix?", expected_topics: [ "Deploy PgBouncer in transaction pooling mode", "Identify idle in transaction connections", "Tune application pool maxActive limits", "Terminate non-essential idle backend connections" ], category: "Postgres Tuning" } ] }) }); const useCase = await submitResponse.json(); console.log(`✅ Registered use-case: ${useCase.name} (ID: ${useCase.id})`); // 2. Run A/B Experiment const expResponse = await fetch(`${BASE_URL}/api/experiments/run`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ name: "Postgres Pooling Evaluation", use_case_id: useCase.id, model: "mock-model", provider: "mock" }) }); const experiment = await expResponse.json(); console.log("📊 Experiment Result:", experiment.summary_verdict); // 3. Delete Ad-Hoc Use-Case await fetch(`${BASE_URL}/api/use-cases/${encodeURIComponent(useCase.id)}`, { method: "DELETE" }); console.log("🧹 Cleaned up temporary use-case."); } catch (err) { console.error("❌ Error running Dokimi integration:", err); } } runDokimiUseCase(); - Command-Line Workflow # 1. Health check curl -s http://127.0.0.1:8000/health | jq . # 2. Submit new ad-hoc use-case UC_RESP=$(curl -s -X POST http://127.0.0.1:8000/api/use-cases/submit \ -H "Content-Type: application/json" \ -d '{ "name": "Redis Memory Eviction Storm Triage", "description": "Assess agent triage on maxmemory policy OOM errors.", "parameters": {"domain": "Cache Infrastructure", "alpha": 0.05}, "expected_outputs": ["Identify keys without TTL", "Tune volatile-lru"], "scenarios": [ { "id": "redis_sc_1", "prompt": "Redis cluster returning (error) OOM command not allowed when used memory > maxmemory. How to triage?", "expected_topics": [ "Check INFO memory and maxmemory-policy", "Identify big keys with redis-cli --bigkeys", "Enable volatile-lru or allkeys-lru eviction", "Set TTLs on unbounded cache keys" ], "category": "Redis Caching" } ] }') echo "$UC_RESP" | jq . UC_ID=$(echo "$UC_RESP" | jq -r .id) # 3. Run Dokimi A/B experiment curl -s -X POST http://127.0.0.1:8000/api/experiments/run \ -H "Content-Type: application/json" \ -d "{ \"name\": \"Redis Eviction Context Optimization\", \"use_case_id\": \"$UC_ID\", \"model\": \"mock-model\", \"provider\": \"mock\" }" | jq '{id: .id, summary: .summary_verdict, metrics: .metrics_by_arm}' # 4. Clean up use-case curl -s -X DELETE "http://127.0.0.1:8000/api/use-cases/$UC_ID" | jq . - Use-Case Submission & Clean-up #!/usr/bin/env bash set -euo pipefail BASE_URL="http://127.0.0.1:8000" echo "=== Submitting Multiple Use-Cases ===" DOMAINS=("Networking" "Storage" "CI_CD") for DOMAIN in "${DOMAINS[@]}"; do echo "Submitting domain: $DOMAIN..." RESP=$(curl -s -X POST "${BASE_URL}/api/use-cases/submit" \ -H "Content-Type: application/json" \ -d "{ \"name\": \"Domain Benchmark: ${DOMAIN}\", \"description\": \"Automated batch validation for ${DOMAIN}\", \"parameters\": {\"domain\": \"${DOMAIN}\", \"alpha\": 0.05}, \"expected_outputs\": [\"Accuracy > 80%\", \"Valid triage sequence\"], \"scenarios\": [ { \"id\": \"${DOMAIN,,}_sc_1\", \"prompt\": \"How to diagnose common ${DOMAIN} failure modes?\", \"expected_topics\": [\"metrics\", \"logs\", \"remediation\"], \"category\": \"${DOMAIN}\" } ] }") UC_ID=$(echo "$RESP" | grep -o '"id":"[^"]*' | cut -d'"' -f4) echo " -> Created: $UC_ID" done echo "=== Current Registered Use-Cases ===" curl -s "${BASE_URL}/api/use-cases" | grep -o '"id":"[^"]*' | cut -d'"' -f4 --- Conclusion: Bringing Rigor to Agent Engineering Optimizing AI agents has historically been a game of intuition—tweaking system prompts, appending markdown runbooks, or adding tool definitions based on gut feeling rather than empirical evidence. As demonstrated through this implementation combining Bob and Intel's Dokimi framework, moving from subjective tuning to rigorous, statistically grounded A/B testing is essential for production-grade agent deployment. By evaluating context variations against standardized question sets, enforcing paired on/off comparisons, and utilizing statistical tools like Student's t*t*-tests and Holm-Bonferroni corrections, engineering teams can definitively answer whether an artifact adds actual value or simply introduces costly noise and redundancy. Whether you are running local models via Ollama and llama.cpp or leveraging cloud-based LLM providers adopting this systematic evaluation lifecycle ensures you only ship context configurations that have proven their worth. Thanks for reading 📊 Links - GitHub repository for this post: google.com - Intel Dokimi GitHub repository: intel/dokimi - Dokimi Documentation: intel.github.io