Долгое время GraphCompose выглядел как PDF-движок. Но архитектурно PDF никогда не должен был быть центром системы: разработчик описывает документ на одном языке, движок один раз рассчитывает layout, а подключаемые backend’ы переводят готовую геометрию в нативные объекты нужного формата.
Данные о том, как поиск видит ваш сайт, живут в интерфейсе Яндекс Вебмастера и в его API: чтобы узнать, по каким запросам показов много, а кликов нет, что выпало из индекса за месяц и что Яндекс считает проблемой сайта, человек ходит по вкладкам и сводит цифры руками, а программа собирает запросы к API v4. LLM-агент по умолчанию не умеет ни того, ни другого.
Разбираю, как устроен MCP-сервер для Яндекс Вебмастера: как уложить пару десятков эндпоинтов в восемь инструментов, какие грабли у API v4 и как сделать вход в Яндекс, который агент выполняет сам — без терминала и без клиентского секрета.
Этот проект долго вынашивался и, в конце концов, начался как очередная попытка разобраться в философских текстах, написанных Джейн Робертс во второй половине двадцатого века.
Естественно, с появлением мощных облачных ИИ не оставлялись попытки найти в них “качественных собеседников” по предложенной теме. Но, как показала практика, они справились с этой задачей далеко не блестяще! То галлюцинировали факты из общих знаний, то упираясь в границы своих датасетов.
Ну что, остаётся последнее: пилить RAG на строго структурированной базе. А т.к. готовых корпусов в открытом доступе не нашлось, пришлось брать сырые сканы, вычищать артефакты распознавания и переводить их в XML, пригодный для эмбеддинга.
На сегодняшний день проделана часть работы. Создан репозиторий в статусе исследовательского лога, куда выкладываются сырые скрипты обработки, предсобранный индекс ChromaDB и пайплайн на базе Qwen2.5 + LM Studio.
Зачем я это пишу? Мне нужен технический аудит от тех, кто глубже работает с векторными базами и архитектурой чат-ботов. В процессе сборки возникли несколько вопросов, по которым у меня пока нет однозначного ответа:
Архитектура индекса: как грамотнее организовать хранение в Chroma?
Сохранение контекста диалога: как правильно реализовать память о предыдущих вопросах пользователя без раздувания токен-бюджета?
Ранжирование выдачи: может ли reranker (например, cross-encoder) улучшить точность на философских текстах? И с какого объёма стоит начинать эту оптимизацию?
Как разработать собственную ОС в одиночку, если заниматься проектом можно только в свободное время? Рассказываю, как ИИ помог мне пройти путь от изучения AArch64 до работающего ядра с вытесняющим планировщиком, userspace, ELF-программами и shell — и почему ответственность инженера при этом никуда не исчезает.
Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?
Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.
TL;DR Начнём с создания точки входа на заблокированный сайт/REALITY/XHTTP/VLESS и закончим примером с модификацией трафика через Zapret2.
В самом простом виде задача выглядит так. Есть сайт в зоне без цензуры и есть несчастный юзер в зоне, где IP-адрес этого сайта заблокирован. Конечно, в 2026 году никого не интересует блокировка одного сайта, но интересует обход блокировки прокси-сервера, который использует VLESS-REALITY, VLESS-TLS-XHTTPS, Trojan или ещё какой-нибудь протокол, всеми силами маскирующийся под HTTPS/TLS — то есть под тот самый обычный вебсайт.
Как организовать контрактное тестирование, если у вас 150+ микросервисов, 10 команд и QA есть далеко не везде? В Nexign перепробовали готовые инструменты, дважды откатили собственные решения — и в итоге за четыре дня собрали прототип, который за полтора года превратился в рабочий инструмент без единой строки тестового кода. Ведущий инженер Максим Дубинин рассказывает, что не так с Dredd и Pact и почему иногда проще сделать своё.
Каждый пул‑реквест хочется не просто проверить тестами, а показать вживую — дизайнеру, менеджеру, соседней команде, чтобы все они смогли потыкаться в UI — порадоваться, понаходить баги — порасстраиваться. Казалось бы, что сложного: поднял окружение и дал ссылку. Но когда пул‑реквесты сыпятся десятками в день, а команд целое множество, «просто поднять окружение» превращается в отдельный инфраструктурный проект.
Привет, Хабр! Меня зовут Михаил Гольбах, я ведущий разработчик интерфейсов Yandex Cloud. Уже несколько лет мы с командой развиваем Ферму — сервис, который поднимает preview‑окружение под каждый пулл‑реквест. В этой статье расскажу, как Ферма выросла из простого self‑hosted‑скрипта на одной виртуальной машине в оркестратор на Docker и Kubernetes и почему в итоге мы открыли её код.
Я добавил в Quince AVX2, FMA и немного unsafe. По всем красивым схемам торговая VM после этого должна была полететь.
Она не полетела…
Сначала SIMD проиграл памяти. Потом кольцевым буферам. Затем выяснилось, что сама VM съедает часть ускорения. А в конце оказалось, что CI уверенно показывал результаты кода, который процессор вообще не исполнял.
Туториал на моих ошибках о том, как правильно внедрять SIMD без веры в чудесные х4.
Если вы или ваша команда уже используете LLM или планируете интегрировать их в проект, то наверняка у вас возникал вопрос, как лучше и красивее написать такой интерфейс, который мог бы общаться с разными моделями. И на такой вопрос уже есть ответ.
Теперь можно сэкономить время разработки и управлять нейросетями в одном месте. Поможет в этом простой инструмент LiteLLM, про который далее и пойдет речь.
На обложке — команда, которой не было. В реальности Twisterminigen создавался за одним столом: я, Mac mini M4 с 32 ГБ объединённой памяти и Codex.
Получилось нативное приложение для Krea 2 Turbo на Swift и MLX: без Python внутри и без облачного inference, но с очередью, LoRA, Regional Prompts, Presets и воспроизводимыми рецептами генерации.
Самый опасный баг при этом не падал и не рисовал шум. Пять токенов из 512 получали неправильные RoPE-позиции, старый тест проходил, а картинки выглядели нормально. После исправления тот же prompt и seed изменили 99,32% пикселей.
В статье — как набор из 31,18 ГиБ весов заработал на 32-гигабайтном Mac, почему одинаковый seed не является паспортом персонажа и где заканчивается красивая картинка и начинается проверяемый продукт.
Сейчас в тренде - внедрение ИИ вообще в любой проект, в любой чайник или пылесос. Я давно ковыряюсь в проектировании и Revit, и меня стабильно бесило одно и то же: куча рутины, одинаковых действий, которые можно было бы спокойно автоматизировать. Глядя на то, какие чудеса сейчас творят языковые и диффузионные LLM, генерируя целые детализированные миры, очень хочется сделать тоже самое в строительной сфере.
Уже существует ряд реализаций. Однако обычно все заканчивается на уровне красивой демки, однако, если присмотреться, там всегда есть эффект "пятого пальца", только в контексте архитектуры это выглядит как третий унитаз или вторая дверь в ванную.
Я решил собрать свой вариант и назвал его AiRevit. Это не чатик с LLM поверх Revit. Тут вообще не предполагается использования такой архитектуры, которая бы основывалась на угадывании токена (нам не нужно ничего угадывать, нужно соблюдать строгие строительные правила). Это детерминированный pipeline, где текст сначала превращается в структурированный program_graph, потом в layout_solution, а уже потом в реальные элементы Revit через Dynamo и Python-скрипты. В репозитории это разложено на Node 3, Node 4 и Node 5, чтобы не было каши и чтобы каждый кусок отвечал за свою часть работы. (https://github.com/Rearks/AiRevit)
В проде подход «включил и готово» почти никогда не работает. Для автономного узла техническая последовательность короткая: включить auth, перезапустить Manticore, создать администратора и обновить клиентов. В топологии с распределёнными таблицами или репликационными кластерами нужна дополнительная подготовка, потому что узлам тоже приходится аутентифицироваться друг у друга.
Относитесь к внедрению как к небольшому релизу. Сначала инвентаризируйте клиентов и узлы, подготовьте данные аутентификации и отрепетируйте процедуру для своей топологии. Затем переключайтесь. Репетиция выявит сбои до технологического окна.
Этот чек‑лист написан для пользователей, которые планируют включить аутентификацию и хотят сделать это максимально безопасно для текущей системы. Помните, что аутентификация отключена, пока вы не настроите auth; после переключения клиенты, которые по‑прежнему не передают учётные данные будут получать отказ.
Выберите процедуру по топологии:
TL;DR. У меня локальный RAG на AMD Strix Halo. Памяти там достаточно, но вычислительно всё упирается в один iGPU: его делят эмбеддер, реранкер и периодическая переиндексация, а в одноузловой конфигурации туда же встаёт генеративная LLM. Поэтому мне понадобился не самый точный retriever вообще, а максимально лёгкий русский retriever, который быстрее завершает первую стадию поиска на том же GPU. Насколько это больно, я в итоге померил на живом узле.
На синтетической индексирующей нагрузке полной тяги bge‑m3 снизил generation throughput Qwen3.6-35B-A3B на 92%, STRIZH на 28% при примерно 12,6-кратном темпе индексации (окна замера там неравные, 20,6 против 173,6 секунды, потому что задаются временем пяти генераций; равнооконный прогон RAG‑конвейера ниже даёт по батчам в секунду 9,4-кратный отрыв). В полном RAG‑конвейере с четырьмя пользовательскими потоками и фоновой индексацией STRIZH удержал 14,0 транзакции в минуту против 6,0 у bge‑m3 и индексировал 46 батчей в секунду против 4,9. При фиксированных 200 онлайн‑запросах в секунду генерация проседала на 2% со STRIZH и на 7% с bge‑m3. Оговорка сразу: без фоновой индексации STRIZH преимущества не показал: в этом профиле bge‑m3 оказался немного быстрее, а пропускную способность определяли реранк (0,6–0,7 с на транзакцию), prefill и генерация.
Я взял 12-слойный RuModernBERT-small, сначала неудачно попытался повторить пространство большого учителя через MSE, затем обучил retrieval‑донор на контрастивной задаче, выбрал из него четыре слоя [0, 5, 9, 11] и доучил student на русских, английских и смешанных парах с hard negatives от BGE‑M3.
21-й выпуск IT‑новостей от OpenIDE!
OpenAI раскатили GPT-5.6 на всех, и та же модель тут же отменила все Stripe‑подписки в чужом стартапе за семь секунд.
JetBrains проверили скилл, который обещал экономию 65% токенов, и намеряли 8,5%. OpenIDE Pro вышла для всех без регистрации.
Kimi выложили открытую модель на 2,8 триллиона параметров, Cursor выпустили Grok 4.5 вместе со SpaceXAI, Anthropic убрали Fable 5 из двадцатидолларовой подписки.
Open Source силён, когда это улица с двусторонним движением.
В основе uStor — нашей программно‑определяемой системы хранения — используется несколько Open Source‑компонентов. Один из них — SPDK (Storage Performance Development Kit), на котором построен транспортный слой: высокоскоростной target классических протоколов доступа к томам (iSCSI и NVMe‑oF поверх TCP) в пользовательском пространстве.
Когда в продукте используется внешний код, рано или поздно возникает вопрос: что делать с найденными в нём проблемами. Можно исправлять их у себя в форке и тихо жить дальше. А можно возвращать исправления в upstream, и тогда выигрывают все, кто пользуется SPDK, включая нас же в следующем релизе.
Мы выбираем второй путь. За последнее время мы отправили в upstream SPDK три исправления — все приняты мейнтейнерами проекта.
VoiceSwitch — открытое menu bar-приложение для Apple Silicon: одна глобальная клавиша запускает запись, GigaAM, Whisper, Qwen или Apple распознают речь локально, Qwen3-4B исправляет или сокращает результат, а приложение вставляет его в активное окно. В статье — архитектура Swift + Python worker, результаты теста четырёх движков на русском и смешанном аудио, ловушка macOS TCC и ссылка на beta.
Инженеры тонут в ревью сгенерированного кода, продакты хвастаются фичами без программистов. Почему агент буксует в вашем репозитории и как это измерить.
Проект NextBSD, который многие уже успели забыть, неожиданно получил вторую жизнь. Его идея — объединить ядро FreeBSD с открытыми системными компонентами Darwin, такими как launchd, Mach IPC, Grand Central Dispatch и другими технологиями, которые сегодня лежат в основе macOS. Первая попытка была предпринята почти десять лет назад, но безуспешно. Сейчас разработку начали заново, используя современную кодовую базу FreeBSD и накопленный за это время опыт.
На первый взгляд, идея выглядит странно: зачем переносить системный слой одной операционной системы поверх ядра другой, если обе давно развиваются своими путями? Однако у разработчиков есть вполне практичная цель. Они не пытаются создать «бесплатную macOS», а хотят сделать FreeBSD более современной платформой, сохранив ее совместимость и сильные стороны. Разберемся, что именно уже удалось реализовать, зачем это вообще нужно и насколько жизнеспособным может оказаться такой подход.
Дарио Амодеи ответил постом в блоге: бан открытых моделей не нужен, нужны три другие меры. Но каждая из них бьёт по NVIDIA.
