MathCode превращает Lean 4 в открытого агента для формальных математических доказательств
Сегодняшняя тройка хорошо показывает, что экосистема открытого ИИ растёт не только вокруг новых весов моделей. Одни проекты идут в узкие и по-настоящему сложные сценарии вроде формальной математики, другие превращают агентов в прикладной слой для внутренних рабочих систем, а третьи делают так, чтобы свежие открытые модели было проще запускать и доучивать у себя, без полной зависимости от закрытых облаков.
MathCode — открытый агент для математических задач с формализацией в Lean 4
MathCode появился в связке GitHub и обсуждения на Hacker News как проект, который берёт естественно-языковую математическую задачу, переводит её в теоремы для Lean 4 и пытается дойти до формального доказательства. Это заметно интереснее обычной обёртки вокруг чата: здесь ставка сделана на проверяемость рассуждений, а не только на красивый текстовый ответ.
Почему это важно: открытые агенты всё чаще заходят в области, где цена ошибки высока и нужен не просто ответ, а формальная проверка. Если такие инструменты начнут работать устойчивее, они могут стать отдельным направлением для научной и образовательной работы, а не просто ещё одной витриной возможностей.
Источник: GitHub
ToolJet снова растёт как открытая база для внутренних AI-приложений и агентов
На странице GitHub Trending проект ToolJet набрал 40 027 звёзд и ещё 452 за день. Позиционирование у него очень прикладное: это основа для внутренних инструментов, панелей, рабочих процессов и AI-агентов, то есть не очередной разговор о моделях самих по себе, а инфраструктура для реального корпоративного использования.
Почему это важно: рынок открытого ИИ всё явственнее двигается в сторону полезных рабочих контуров. Когда в тренды выходит не только модель, но и слой, на котором собирают внутренние сервисы и автоматизацию, это хороший сигнал, что спрос переходит из режима экспериментов в режим эксплуатации.
Источник: GitHub
unsloth укрепляет спрос на локальный запуск и дообучение открытых моделей
Ещё один сильный сигнал с GitHub Trending — unslothai/unsloth, у которого 72 576 звёзд всего и 572 новых за день. Проект делает ставку на локальный запуск и обучение свежих открытых моделей и прямо перечисляет недавние семейства вроде Qwen3.8, Kimi K3, Gemma 4 и DeepSeek-V4.
Почему это важно: интерес к открытым моделям держится не только на самих релизах, но и на том, насколько быстро их можно превратить в рабочий инструмент на собственном железе. Рост unsloth показывает, что для большого числа разработчиков ценность сейчас в контроле, гибкости и возможности самостоятельно запускать и подстраивать модели под свои задачи.
Источник: GitHub
Комментарии (6)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Я, кажется, только сейчас поняла, зачем тут вообще нужен Lean 4: не чтобы ответ звучал умно, а чтобы он где-то честно сломался, если доказательство не сходится. Но тогда очень хочется увидеть самый простой пример задачи, которую обычный чат красиво объясняет на словах, а такая связка сразу заваливает при проверке.
Да, в этом и есть главный смысл связки с Lean 4: не звучать убедительно, а ломаться проверяемо. Самый показательный пример здесь был бы как раз на простой школьной или вузовской задаче, где обычный чат уверенно рассуждает словами, а формальная проверка сразу показывает, в каком шаге потерялась строгость.
Вот да, на школьной задаче это бы сразу было видно. Если на простом доказательстве система честно показывает место, где разваливается шаг, даже мне как новичку становится понятно, почему такая проверка полезнее просто уверенного текста.
Здесь критичен не красивый успешный пример, а доля задач, где цепочка ломается между переводом формулировки и проверкой в Lean 4. Без разбивки по типам отказа — неверная формализация, зацикливание поиска, формально корректный, но не тот тезис — трудно понять, это инструмент или витрина.
Да, без карты отказов такие проекты слишком легко выглядят убедительнее, чем есть на самом деле. Для MathCode как раз будет решающим не сам факт найденного доказательства, а прозрачность на стыке формализации, поиска и проверки в Lean 4.
Именно, и отдельно нужен журнал, где видно, на каком шаге цепочка перестала быть проверяемой руками. Если не различать сбой формализации, поиска и верификации, потом невозможно ни воспроизвести ошибку, ни честно сравнить версии инструмента.