• Дешевле Perplexity: на DeepResearch Bench получили 44.37 (RACE overall) на Claude Haiku 4.5 — модель заметно дешевле типичных "фронтирных" стэков.

• Локально и прозрачно: реальный Chrome перед глазами — можно остановить, залогиниться, закрыть баннер, перезапустить шаг, расширить сбор, уточнить запрос. Итераций — сколько угодно.

• Не только deep research: ещё и инструмент для браузерной автоматизации + извлечения контента, форм, HTML-данных.

• Расширяемо: новые сайты добавляются профилями в scripts/sites/*.json — селекторы и «контролы» живут отдельно от кода и промптов.

Есть паттерн, который видит каждый, кто работает с агентами: первые 5–15 минут уходят не на задачу, а на "ориентацию". Где точка входа? Откуда растут зависимости? Почему эта библиотека, а не другая? Кто считает это публичным API? В маленьком проекте раздражает. В большом — превращается в постоянный налог на токены и внимание.

DSP (Data Structure Protocol) "выносит карту проекта наружу" — в простой, версионируемый, языковой граф, который живёт рядом с кодом и доступен агенту как постоянная память.

k-kolomeitsev/data-structure-protocol

Цель в архитектуре сформулирована так:

1) Цель и границы

Цель DSP — хранить минимальный, но достаточный контекст о репозитории/системе артефактов в виде графа «сущности → зависимости/публичный API», чтобы LLM могла:

- быстро находить нужные фрагменты по UID,

- понимать «зачем» сущности существуют и «как» они связаны,

- не требовать загрузки исходников целиком в контекстное окно.

DSP — это долговременная память и индекс проекта для LLM. Агент может в любой момент выполнить поиск (grep) по проекту, найти нужные сущности по описаниям/ключевым словам и от найденного UID раскрутить весь граф связей: входящие зависимости, исходящие импорты, реципиентов через exports. Это заменяет необходимость «помнить» структуру проекта или загружать его целиком — вся карта проекта всегда доступна через .dsp.

Это перевод моей статьи в LinkedIn

Главная мечта современных инвесторов в ИИ - это автономный ИИ сотрудник, который может полностью заменить некоторых специалистов и работать без постороннего вмешательства.

На мой взгляд это уже вполне достижимая цель, которая достижима с текущим уровнем технологий.

Приведу пример на близкой мне области - программирование (но вообще применим к большинству digital профессий). Сделаем автономного ИИ middle backend разработчика.

Сделаем мы его на локальной серверной машине, внутри контура компании.

Сразу скажу что Я не буду выкладывать свой код, настройки или workflows для открытого доступа. Моя цель - верхнеуровнево показать рабочее для меня решение, потому что вижу не то что пробел, а вообще отсутствие материалов такого рода информации, даже с таким поверхностным уровнем детализации.

Когда-то я уже делился мыслями о том, как нанимать разработчиков.

С тех пор в жизнь ИТ-команд вошёл искусственный интеллект, а задача подбора сотрудников стала ещё сложнее.

PTTJS - plain text table javascript, формат разработанный из личной необходимости и острой нужды.

Главная цель формата PTTJS - получить текстовый формат таблиц, который позволяет хранить более сложные таблицы, нежели существующие форматы, но при этом сохранять читаемость и текстовую основу.

Уже написаны JS библиотека с парсером и сериализатором, а также Obsidian плагин.

Это статья обобщение моего исследования передачи знаний от большой модели с замороженными весами в малую модель, которую мы будем обучать через расширенный механизм кросс внимания или проще говоря через LLM модули. Оригинальное исследование доступно по ссылке: arxiv.org/abs/2502.08213 . Репозиторий с кодом и весами доступен на Hugging Face: LLM модули.

Само исследование появилось из необходимости использовать знания больших обученных моделей в ограниченных рамках для четкого списка задач, при этом ни бюджета ни мощностей на файн-тюнинг моделей, даже не слишком больших, нет.

Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.

* В данной статье примеры будут на TypeScript

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

Что такое DDD (Domain Driven Design) вопрос обширный, но если в кратце (как Я это понимаю) — это про перенос бизнес логики, как она есть, в код, без углубления в технические детали. То есть в идеале, человек, который знает за бизнес процессы, может открыть код и понять, что там происходит (так кстати часто бывает в 1С).

Всё это сопровождается кучей разных рекомендаций по технической реализации вопроса.

Для лучшего понимания статьи советую прочитать материалы, касающиеся DDD.