Для тех, кто работает с железом, классический RAG вообще не прижился. Ошибка в распиновке, смещении регистра или тайминге на один такт в микроэлектронике обходится слишком дорого. Та же Nvidia в своём проекте ChipNeMo быстро упёрлась в то, что скармливать PDF-спецификации чипов в векторные базы бессмысленно: семантический поиск неизбежно теряет жёсткие связки и ограничения. Поэтому они сразу пошли по пути нормализации проектной документации в строгие машиночитаемые графы, AST и типизированные структуры.
Самой модели «сырой» текст больше не отдают. Ей показывают только схемы метаданных, под которые она генерирует точечный исполняемый код — чаще всего на Python или Tcl, который стандартно используется в EDA-инструментах для проектирования чипов. Скрипт выполняется в рантайме, забирает из базы хирургически точный срез данных и прогоняет его через валидаторы. Если код упал с ошибкой, модель получает traceback и правит запрос сама. В итоге всю критичную проверку правил берёт на себя детерминированный софт, а за LLM остаётся только логика формулирования запроса.
IP-XACT (IEEE 1685 / XML/JSON): Мировой промышленный стандарт описания регистров, шин, адресов и интерфейсов микросхем. PDF переводят в IP-XACT, а уже по нему агент делает точечный парсинг и сборку контекста.
SystemRDL: Специализированный язык описания регистровых карт устройств. Компиляторы SystemRDL (PeakRDL, rdl-compiler) позволяют генерировать C-заголовки, Verilog и Python API на лету.
Tcl / Pyverilog / cocotb:
Tcl — стандарт де-факто для скриптинга всех промышленных САПР (Synopsys, Cadence, Xilinx Vivado).
Читается немного как: «Да, экскаватор действительно копает в десять раз быстрее. Но ведь траншею всё равно надо правильно разметить, проверить грунт, соблюдать технику безопасности и потом обслуживать. Поэтому количество землекопов и смету сокращать ни в коем случае нельзя».
С большинством перечисленных инженерных рисков спорить бессмысленно — security, тесты, observability, backup, rollback и архитектура действительно нужны. Но из факта, что эти работы нужны, совершенно не следует, что на них по-прежнему требуется прежний объём человеко-часов и прежний ФОТ.
Более того, автор сам пишет, что AI уже ускоряет исследование, написание тестов, рефакторинг, документацию и генерацию кода. Но почему-то экономический вывод из этого делается удивительно односторонний: производительность выросла, инструменты стали мощнее, значительная часть рутины автоматизируется — а смета опытной команды, видимо, является фундаментальной физической константой.
Особенно красиво, что в статье есть отдельный пункт про «инженерную экономику», но применяется она в основном к инфраструктуре заказчика. До экономики собственного ФОТ этот принцип почему-то не доезжает.
Поэтому проблема здесь, кажется, не в тезисе «вайбкодинг ≠ зрелая инженерия» — это банально верно. Интереснее другой вопрос: если опытный инженер с AI теперь способен за то же время проверить и реализовать существенно больше, почему заказчик должен продолжать оплачивать организационную структуру и трудозатраты эпохи до AI?
Вот на этот вопрос хотелось бы увидеть цифры, а не очередной рассказ о том, насколько сложен production.
Спасибо за статью! сам растом пока ещё не пользовался, только планирую. Очень здорово что вы поделились местом где лежат грабли и советами как обойти. С вашего позволения хочу предложить свои 5 копеек:
Мне кажется, часть этих проблем можно снижать не только промптами и CI, но и устройством самой кодовой базы.
Если коротко:
Делать в коде “липкие комментарии” в узловых местах. Не комментарии вида “тут создаём кеш”, а предупреждения: “этот кусок связан с таким-то внешним контрактом, не упрощать, не переносить, не менять порядок операций”.
Комментарий должен быть не источником истины, а навигатором: “смотри такой-то контракт / blueprint / ADR / тест”. Тогда агент, который пришёл менять локальный кусок кода, получает шанс добрать нужный внешний контекст.
Важные правила лучше фиксировать в нескольких слоях: документ → схема/тип → тест → runtime check → sticky comment рядом с местом риска. Тогда LLM не просто “прочитала пожелание”, а попала в систему ограничителей.
Нужны не только промпты “напиши правильно”, а проектные skills/runbooks: если меняешь async-код — проверь отмену; если меняешь публичный API — проверь совместимость; если трогаешь кеш/транзакции/lock — проверь порядок владения и побочные эффекты.
Агенту полезно давать не весь репозиторий сразу, а маршрутизированный контекст: какие документы канонические, какие решения уже приняты, какие места нельзя “улучшать”, какие инварианты обязательны.
После реализации агент должен не просто прогнать тесты, а сделать контрактный аудит: какие инварианты затронуты, какие sticky comments обновлены, какие рисковые места проверены.
То есть проблема не только в том, что LLM не видит контекст. Проблема в том, что контекст часто не оформлен как инженерная система. Если превратить его в контракты, локальные маяки, тесты и обязательные проверки, часть “слепых зон LLM” становится обычным управляемым риском.
И все таки еще раз спасибо за статью! В эпоху вайбкодинга, такие материалы от реальных разработчиков на вес золота!
Если говорить про самую громкую идею — что из данных Pokémon Go строится «большая геопространственная модель мира» для ИИ, роботов и автономных систем, — то тут корректнее говорить так: фундамент уже существует, данные уже собираются и используются, но глобальный LGM — это пока стратегическое направление и активная разработка, а не готовый массовый продукт, который повсеместно работает в промышленности. Niantic сама пишет о long term goal и о том, что этот model “will be” основой пространственно-интеллектуального ИИ.
А можно больше деталей? Речь идет о генерации задач, материалов? По каким дисциплинам? Почему fine tuning а не rag? Были ли у вас r&d , неужели системный Промт + rag не вывез бы этот кейс?
Автор (Юрий Строжевский, @ystr — опытный разработчик с 1998 года, автор «КриптоАРМ» и нескольких статей по криптографии/Kerberos) пошёл дальше стандартной документации MSDN и книг типа «Windows Internals». Он собрал в одном месте то, что обычно приходится собирать по кусочкам и за это огромное спасибо!!!
Ключевые "жемчужины", которых почти нигде нет в таком виде:
Полный цикл кодирования/декодирования всех основных типов NDR через низкоуровневые функции (пример в папке NDR2).
Реализация сервера, который работает с произвольными (неструктурированными) данными в многопоточной среде, с разными object ID и manager EPV (RPCServer2).
Как использовать manager EPV нестандартно (автор даже хранит в нём целые числа вместо указателей на функции — это уже хакерский уровень).
Динамическая регистрация object/type ID, security callback, расширенные ошибки (RPC_EE_INFO), impersonation клиента и получение его адреса.
Полноценный клиент без MIDL (RPCClient2) + отдельный пример клиента для самого EPMAPPER с ручным разбором tower.
Так смотрите я правильно понял суть вашего проекта что теперь openclaw может общаться через API с wb, Yandex market, ozon и основной интерфейс у вас это мессенджеры которые подключены к openclaw?
Если бы вы знали, сколько раз ко мне люди обращались с просьбой восстановить удалённую ими же информацию и в этом им не "помогал" агент они сами , вполне самостоятельно мудрялись удалять важную для них информацию.
Все ок. Вы все понятно и доступно объяснили. Возможно я жестянул, если хотите, могу поправить свой коммент. В любом случае респект, что поделились опытом. Кому то может и пригодится.
Описанное в статье «автоматическое чанкование» — это подмена понятий: авторы называют автоматизацией обычную замену стандартного токенизатора на не менее стандартный сплиттер по заголовкам Markdown, который в LangChain существует уже несколько лет. Весь «кастомный алгоритм» сводится к двум эвристикам — «склеивать чанки меньше 100 токенов» и «добавить overlap 15%». Это базовая настройка, которая делается за час любым стажёром, прочитавшим документацию, а не результат R&D, достойный отдельной статьи с пафосным заголовком про «95% точности».
Метрики, которыми авторы козыряют, не выдерживают критики. Бенчмарк составлен «для себя» на неизвестном количестве примеров — нет ни слова про объём выборки, её репрезентативность или хотя бы методологию исключения переобучения под конкретные запросы. Триграммное сходство с порогом 80% — это мера буквального совпадения текста, а не семантической релевантности; такими «метриками» нельзя измерить качество RAG, ими можно только создать иллюзию измеримости. Реранкер поднял точность с 70% до 95% — это неизбежно следует из самой архитектуры cross-encoder, но авторы умалчивают, что эта «точность» посчитана на том же куцем бенчмарке, и что платой за неё стали 16 секунд latency на CPU, которые в продакшене означают непригодность решения без покупки GPU. По сути, перед нами типичный корпоративный отчёт «как мы перестали использовать параметры по умолчанию и начали пользоваться платными моделями», раздутый до масштаба открытия.
Там стоимость считали по api токенам, автор скорей всего использовал подписку, так что там по факту экономика другая.
Для тех, кто работает с железом, классический RAG вообще не прижился. Ошибка в распиновке, смещении регистра или тайминге на один такт в микроэлектронике обходится слишком дорого. Та же Nvidia в своём проекте ChipNeMo быстро упёрлась в то, что скармливать PDF-спецификации чипов в векторные базы бессмысленно: семантический поиск неизбежно теряет жёсткие связки и ограничения. Поэтому они сразу пошли по пути нормализации проектной документации в строгие машиночитаемые графы, AST и типизированные структуры.
Самой модели «сырой» текст больше не отдают. Ей показывают только схемы метаданных, под которые она генерирует точечный исполняемый код — чаще всего на Python или Tcl, который стандартно используется в EDA-инструментах для проектирования чипов. Скрипт выполняется в рантайме, забирает из базы хирургически точный срез данных и прогоняет его через валидаторы. Если код упал с ошибкой, модель получает traceback и правит запрос сама. В итоге всю критичную проверку правил берёт на себя детерминированный софт, а за LLM остаётся только логика формулирования запроса.
IP-XACT (IEEE 1685 / XML/JSON): Мировой промышленный стандарт описания регистров, шин, адресов и интерфейсов микросхем. PDF переводят в IP-XACT, а уже по нему агент делает точечный парсинг и сборку контекста.
SystemRDL: Специализированный язык описания регистровых карт устройств. Компиляторы SystemRDL (
PeakRDL,rdl-compiler) позволяют генерировать C-заголовки, Verilog и Python API на лету.Tcl / Pyverilog / cocotb:
Tcl — стандарт де-факто для скриптинга всех промышленных САПР (Synopsys, Cadence, Xilinx Vivado).
Читается немного как: «Да, экскаватор действительно копает в десять раз быстрее. Но ведь траншею всё равно надо правильно разметить, проверить грунт, соблюдать технику безопасности и потом обслуживать. Поэтому количество землекопов и смету сокращать ни в коем случае нельзя».
С большинством перечисленных инженерных рисков спорить бессмысленно — security, тесты, observability, backup, rollback и архитектура действительно нужны. Но из факта, что эти работы нужны, совершенно не следует, что на них по-прежнему требуется прежний объём человеко-часов и прежний ФОТ.
Более того, автор сам пишет, что AI уже ускоряет исследование, написание тестов, рефакторинг, документацию и генерацию кода. Но почему-то экономический вывод из этого делается удивительно односторонний: производительность выросла, инструменты стали мощнее, значительная часть рутины автоматизируется — а смета опытной команды, видимо, является фундаментальной физической константой.
Особенно красиво, что в статье есть отдельный пункт про «инженерную экономику», но применяется она в основном к инфраструктуре заказчика. До экономики собственного ФОТ этот принцип почему-то не доезжает.
Поэтому проблема здесь, кажется, не в тезисе «вайбкодинг ≠ зрелая инженерия» — это банально верно. Интереснее другой вопрос: если опытный инженер с AI теперь способен за то же время проверить и реализовать существенно больше, почему заказчик должен продолжать оплачивать организационную структуру и трудозатраты эпохи до AI?
Вот на этот вопрос хотелось бы увидеть цифры, а не очередной рассказ о том, насколько сложен production.
MeshCentral. Бесплатно.
Спасибо за статью! сам растом пока ещё не пользовался, только планирую. Очень здорово что вы поделились местом где лежат грабли и советами как обойти. С вашего позволения хочу предложить свои 5 копеек:
Мне кажется, часть этих проблем можно снижать не только промптами и CI, но и устройством самой кодовой базы.
Если коротко:
Делать в коде “липкие комментарии” в узловых местах. Не комментарии вида “тут создаём кеш”, а предупреждения: “этот кусок связан с таким-то внешним контрактом, не упрощать, не переносить, не менять порядок операций”.
Комментарий должен быть не источником истины, а навигатором: “смотри такой-то контракт / blueprint / ADR / тест”. Тогда агент, который пришёл менять локальный кусок кода, получает шанс добрать нужный внешний контекст.
Важные правила лучше фиксировать в нескольких слоях: документ → схема/тип → тест → runtime check → sticky comment рядом с местом риска. Тогда LLM не просто “прочитала пожелание”, а попала в систему ограничителей.
Нужны не только промпты “напиши правильно”, а проектные skills/runbooks: если меняешь async-код — проверь отмену; если меняешь публичный API — проверь совместимость; если трогаешь кеш/транзакции/lock — проверь порядок владения и побочные эффекты.
Агенту полезно давать не весь репозиторий сразу, а маршрутизированный контекст: какие документы канонические, какие решения уже приняты, какие места нельзя “улучшать”, какие инварианты обязательны.
После реализации агент должен не просто прогнать тесты, а сделать контрактный аудит: какие инварианты затронуты, какие sticky comments обновлены, какие рисковые места проверены.
То есть проблема не только в том, что LLM не видит контекст. Проблема в том, что контекст часто не оформлен как инженерная система. Если превратить его в контракты, локальные маяки, тесты и обязательные проверки, часть “слепых зон LLM” становится обычным управляемым риском.
И все таки еще раз спасибо за статью! В эпоху вайбкодинга, такие материалы от реальных разработчиков на вес золота!
Вы к нам давно приехали из идеального мира?)))) тут у людей каждое второе слово галлюцинация!
Если говорить про самую громкую идею — что из данных Pokémon Go строится «большая геопространственная модель мира» для ИИ, роботов и автономных систем, — то тут корректнее говорить так: фундамент уже существует, данные уже собираются и используются, но глобальный LGM — это пока стратегическое направление и активная разработка, а не готовый массовый продукт, который повсеместно работает в промышленности. Niantic сама пишет о long term goal и о том, что этот model “will be” основой пространственно-интеллектуального ИИ.
А можно больше деталей? Речь идет о генерации задач, материалов? По каким дисциплинам? Почему fine tuning а не rag? Были ли у вас r&d , неужели системный Промт + rag не вывез бы этот кейс?
Иммунитет снижает армия, я такой делаю вывод 🤷
https://github.com/techserv/Open-NotebookLM
100%
Гранд респект!!!!
Автор (Юрий Строжевский, @ystr — опытный разработчик с 1998 года, автор «КриптоАРМ» и нескольких статей по криптографии/Kerberos) пошёл дальше стандартной документации MSDN и книг типа «Windows Internals». Он собрал в одном месте то, что обычно приходится собирать по кусочкам и за это огромное спасибо!!!
Ключевые "жемчужины", которых почти нигде нет в таком виде:
Полный цикл кодирования/декодирования всех основных типов NDR через низкоуровневые функции (пример в папке NDR2).
Реализация сервера, который работает с произвольными (неструктурированными) данными в многопоточной среде, с разными object ID и manager EPV (RPCServer2).
Как использовать manager EPV нестандартно (автор даже хранит в нём целые числа вместо указателей на функции — это уже хакерский уровень).
Динамическая регистрация object/type ID, security callback, расширенные ошибки (RPC_EE_INFO), impersonation клиента и получение его адреса.
Полноценный клиент без MIDL (RPCClient2) + отдельный пример клиента для самого EPMAPPER с ручным разбором tower.
Так смотрите я правильно понял суть вашего проекта что теперь openclaw может общаться через API с wb, Yandex market, ozon и основной интерфейс у вас это мессенджеры которые подключены к openclaw?
По сути у вас получился своеобразный "MCP" слой?
Смоки тесты не?
Если бы вы знали, сколько раз ко мне люди обращались с просьбой восстановить удалённую ими же информацию и в этом им не "помогал" агент они сами , вполне самостоятельно мудрялись удалять важную для них информацию.
Подгорает))))
Все ок. Вы все понятно и доступно объяснили. Возможно я жестянул, если хотите, могу поправить свой коммент. В любом случае респект, что поделились опытом. Кому то может и пригодится.
Описанное в статье «автоматическое чанкование» — это подмена понятий: авторы называют автоматизацией обычную замену стандартного токенизатора на не менее стандартный сплиттер по заголовкам Markdown, который в LangChain существует уже несколько лет. Весь «кастомный алгоритм» сводится к двум эвристикам — «склеивать чанки меньше 100 токенов» и «добавить overlap 15%». Это базовая настройка, которая делается за час любым стажёром, прочитавшим документацию, а не результат R&D, достойный отдельной статьи с пафосным заголовком про «95% точности».
Метрики, которыми авторы козыряют, не выдерживают критики. Бенчмарк составлен «для себя» на неизвестном количестве примеров — нет ни слова про объём выборки, её репрезентативность или хотя бы методологию исключения переобучения под конкретные запросы. Триграммное сходство с порогом 80% — это мера буквального совпадения текста, а не семантической релевантности; такими «метриками» нельзя измерить качество RAG, ими можно только создать иллюзию измеримости. Реранкер поднял точность с 70% до 95% — это неизбежно следует из самой архитектуры cross-encoder, но авторы умалчивают, что эта «точность» посчитана на том же куцем бенчмарке, и что платой за неё стали 16 секунд latency на CPU, которые в продакшене означают непригодность решения без покупки GPU. По сути, перед нами типичный корпоративный отчёт «как мы перестали использовать параметры по умолчанию и начали пользоваться платными моделями», раздутый до масштаба открытия.