
Комментарии 10
Вчера только попалось видео про два свежих исследования. Это как раз касается вашей темы. В исследованиях ставился вопрос, являются ли рассуждения LLM случайными блужданиями или нет. Суть сводилась к тому, что если ли разница между генерацией правильного и неправильного рассуждения. Проверка была на медицинских данных, так как там важно чтобы разные симптомы были объединены в правильные связи и связаны с правильными лекарствами. В случае LLM реальные и вымышленные связи дают одинаковый коэффициент правдоподобия, поэтому они равнозначные - в то время как у людей он отличается. Авторы этого и другого исследования приходят к выводу, что рассуждения являются "случайными блужданиями" созданными на основе статистических данных.
Я к тому, что единственный вариант для точной проверки (к которому вы сами и пришли) - это наличие промежуточного элемента, который проверяет хотя бы валидацию кода или связей, компилируется он или нет. Собственно так обучают LLM для кодовой базы (синтетический датасет), через генерацию множества кода различных задач и затем пропускание его через компилятор. Если проходит, то можно на этом коде обучать иначе нет.
Тут вряд ли играет роль MCP или без него, так как в вашем случае проблема та же, что и со связями симптомов в исследованиях выше. MCP это просто же микросервис с оберткой понятной для LLM. Он нужен в архитектуре только там, где обычно нужен микросервис. В вашем случае, я не понял зачем изначально MCP был там.
Так в том и суть, что эта MCP обёртка всё и портит, она заставляет модель работать через JSON-схему вместо кода(и это приводит к тому, что она гораздо чаще ошибается). А начинал я с MCP просто потому, что это самый быстрый способ подцепить готового агента типа Claude или Cursor к КОМПАСу, вот на нём эти грабли и вылезли.
Если хочется вызовы, то есть же UTCP как MCP без обертки а сразу обращение к API, но их сложнее контролировать. Те же Skill, но они сыроваты и есть проблемы расширяемости, так как много много скиллсов просто приводят к тому, что они игнорируются.
У меня MCP одна из проблем, что забивает контекст огромными JSON-схемам и модель теряет детали. Но она уже решена (например, паттерн Code Mode от Cloudflare или Port of Context). MCP-сервер отдает модели вместо тысячи эндпоинтов, всего два метода: search() и execute(). Короче экономия порядка 99% токенов и контекст не теряется так.
Пробовали UTCP вместо MCP в данном случае (если очень хочется связать с Claude или Cursor)?
Может быть лучше внутри использовать RLM. Это аналог LangChain но умеющий работать с большим контекстом (за счет памяти), H-MEM память и так далее. Так как в вашем случае, контекст с деталями может быть важен.
Про UTCP не слышал, спасибо, гляну. Зашёл посмотреть, а у них самих уже есть Code Mode, многошаговые сценарии одним скриптом вместо десятков вызовов, похоже все туда сходятся. А search()/execute() из Cloudflare'овского паттерна у меня по факту так и работает, модель запрашивает срез из графа и исполняет проверенный скрипт. RLM кстати выглядит здорово, надо будет попробовать
Очень сильный пост, видно что это уже не просто LLM-эксперимент, а полноценная инженерная система. Классно, что вы не боретесь с ошибками промптами, а закрываете их слоями граф API, справочники, ГОСТ и компиляция. Отдельно зашёл live runner, именно он делает систему по-настоящему надёжной, а не почти работающей.
В FreeCAD.GenCAD тоже использован цикл исправлений сгенерированного кода модели, с контекстом ошибки и проверкой в CAD. Без MCP.
В дополнение была сделана визуальная верификация детали, но текущие VLM не особо хороши в пространственной геометрии и поэтому этот способ остается для будущего.
Параметрическая верификация кода LLM моделью работает лучше, но не идеально.
Это очень сильная инженерная система, а не просто LLM-агент. Ты фактически построил многоуровневый компилятор для генерации кода под KOMPAS-3D. Граф API решает проблему путей и типов, справочник фиксирует доменные ограничения, ГОСТ-база закрывает нормативную часть, а компилятор с live runner добавляет реальную проверку исполнения. В итоге ошибки отсекаются поэтапно до запуска в CAD, и это делает систему устойчивой к типичным галлюцинациям LLM.
MCP может быть разный, если вы его написали как кучу функций между собой не связанных, то он и работает как цикл на пять деталей превращается в десяток с лишним обменов, написали бы одну функцию "обойти состав сборки и у каждой детали прочитать обозначение, выдать ответ в формате JSON", то и получили бы сразу что нужно без лишних телодвижений. Хотя конечно польза от статьи однозначно есть, и правильно выкинули MCP и можно вообще ИИ выкинуть, если задача решается простым кодом.
Так в том и дело, что задачи заранее не известны. Сегодня «обойти состав», завтра «обойти, но только папки 10.XX.000 и заполнить штамп у каждой детали». Готовые функции под каждую формулировку руками не напасёшься писать. Любая нарезка на готовые инструменты MCP, крупная или мелкая, упирается в то, что кто-то должен предугадать задачи. А если список задач конечен и известен, ИИ можно выкидывать вместе с MCP, тут вы правы
Я так понял, что MCP таки выкинули и заменили кодом, а значит и готовая функция была вполне уместна. Кроме того, кто мешает расширять MCP функции при появлении новых задач или создавать универсальные, с параметрами, а то и вообще единственную функцию, со списком именованых запросов во внешнем файле...
Почему я выкинул MCP из AI-агента для CAD: граф API, ГОСТы, компилятор и live COM для KOMPAS-3D