Поиск на основе триграмм
Если вы разрабатываете свои агентные системы и "второй мозг", где необходим поиск по огромным массивам документов, то эта новость для вас.
Microsoft выпустила tgrep — инструмент для очень быстрого поиска текста по большим кодовым базам. Он уже используется внутри GitHub Copilot CLI.
Главное отличие tgrep от обычного grep или ripgrep в том, что он использует предварительно построенный индекс.
Обычный поиск при каждом запросе проходит по файлам проекта и проверяет их содержимое. ripgrep делает это очень эффективно и быстро, но принцип остаётся тем же: файлы нужно просмотреть при выполнении поиска.
tgrep сначала индексирует проект. Во время индексации он анализирует содержимое файлов и создаёт специальный триграммный индекс. Триграмма — это последовательность из трёх символов. Для каждой такой последовательности индекс хранит информацию о том, в каких файлах она встречается.
После этого при поиске tgrep сначала обращается к индексу и определяет небольшой набор файлов, в которых вообще может находиться искомый текст. И только затем проверяет эти файлы непосредственно.
Например, если в репозитории 500 тысяч файлов, поиск не обязательно будет читать все 500 тысяч. Индекс может показать, что подходящие файлы находятся, например, среди нескольких сотен — и проверить нужно уже их.
При этом индекс не остаётся статичным. tgrep может работать в режиме сервера, который отслеживает изменения в проекте и обновляет индекс при изменении файлов.
Именно поэтому основное преимущество tgrep проявляется при повторных поисках в очень больших репозиториях.
В тестах Microsoft поиск по Firefox занимал у ripgrep около 33 секунд, а у tgrep — около 643 миллисекунд. Для Chromium результаты составляли примерно 41 секунду против 2,6 секунды, а для Linux — 5,4 секунды против 256 миллисекунд.
То есть в зависимости от проекта поиск может ускоряться в несколько, десятки и даже больше раз.
При этом tgrep не является безусловной заменой ripgrep. Для небольших проектов предварительная индексация может быть просто не нужна. Если нужно один раз найти что-то в нескольких тысячах файлов, обычный ripgrep зачастую будет проще.
tgrep имеет смысл там, где кодовая база очень большая, а поиск выполняется постоянно.
По сути, его основная идея довольно простая: не искать одно и то же по всему проекту заново при каждом запросе, а заранее создать индекс и использовать его для следующих поисков.
Для агентных ИИ такая система поиска тоже может быть очень полезна. Агенту часто приходится много раз искать по исходному коду: находить функции, классы, места использования переменных, похожие участки кода или конкретные реализации. Если проект большой, использование индексированного поиска позволяет выполнять такие операции значительно быстрее и не тратить время на повторное сканирование всей кодовой базы.
В RAG-системах принцип похожий. Вместо того чтобы каждый раз просматривать весь набор документов или файлов, можно использовать индекс для быстрого определения релевантных документов, а уже затем передавать найденное содержимое модели. При этом tgrep не заменяет векторный поиск: это другой подход. Его сильная сторона — очень быстрый точный поиск по содержимому, который можно использовать как отдельный этап retrieval или вместе с семантическим поиском.
#indexsearch
Если вы разрабатываете свои агентные системы и "второй мозг", где необходим поиск по огромным массивам документов, то эта новость для вас.
Microsoft выпустила tgrep — инструмент для очень быстрого поиска текста по большим кодовым базам. Он уже используется внутри GitHub Copilot CLI.
Главное отличие tgrep от обычного grep или ripgrep в том, что он использует предварительно построенный индекс.
Обычный поиск при каждом запросе проходит по файлам проекта и проверяет их содержимое. ripgrep делает это очень эффективно и быстро, но принцип остаётся тем же: файлы нужно просмотреть при выполнении поиска.
tgrep сначала индексирует проект. Во время индексации он анализирует содержимое файлов и создаёт специальный триграммный индекс. Триграмма — это последовательность из трёх символов. Для каждой такой последовательности индекс хранит информацию о том, в каких файлах она встречается.
После этого при поиске tgrep сначала обращается к индексу и определяет небольшой набор файлов, в которых вообще может находиться искомый текст. И только затем проверяет эти файлы непосредственно.
Например, если в репозитории 500 тысяч файлов, поиск не обязательно будет читать все 500 тысяч. Индекс может показать, что подходящие файлы находятся, например, среди нескольких сотен — и проверить нужно уже их.
При этом индекс не остаётся статичным. tgrep может работать в режиме сервера, который отслеживает изменения в проекте и обновляет индекс при изменении файлов.
Именно поэтому основное преимущество tgrep проявляется при повторных поисках в очень больших репозиториях.
В тестах Microsoft поиск по Firefox занимал у ripgrep около 33 секунд, а у tgrep — около 643 миллисекунд. Для Chromium результаты составляли примерно 41 секунду против 2,6 секунды, а для Linux — 5,4 секунды против 256 миллисекунд.
То есть в зависимости от проекта поиск может ускоряться в несколько, десятки и даже больше раз.
При этом tgrep не является безусловной заменой ripgrep. Для небольших проектов предварительная индексация может быть просто не нужна. Если нужно один раз найти что-то в нескольких тысячах файлов, обычный ripgrep зачастую будет проще.
tgrep имеет смысл там, где кодовая база очень большая, а поиск выполняется постоянно.
По сути, его основная идея довольно простая: не искать одно и то же по всему проекту заново при каждом запросе, а заранее создать индекс и использовать его для следующих поисков.
Для агентных ИИ такая система поиска тоже может быть очень полезна. Агенту часто приходится много раз искать по исходному коду: находить функции, классы, места использования переменных, похожие участки кода или конкретные реализации. Если проект большой, использование индексированного поиска позволяет выполнять такие операции значительно быстрее и не тратить время на повторное сканирование всей кодовой базы.
В RAG-системах принцип похожий. Вместо того чтобы каждый раз просматривать весь набор документов или файлов, можно использовать индекс для быстрого определения релевантных документов, а уже затем передавать найденное содержимое модели. При этом tgrep не заменяет векторный поиск: это другой подход. Его сильная сторона — очень быстрый точный поиск по содержимому, который можно использовать как отдельный этап retrieval или вместе с семантическим поиском.
#indexsearch
👍5
Работа с чистой энергией
Дисклеймер
Сегодня ава и название канала, наконец, поменялись. Я долго колебался на этот счет и думал оставить "как есть", но лучше уже сделать этот шаг и перейти более регулярным постам на темы, которые заходят и нравятся мне самому. Надеюсь, вам все также будут заходить формат.
---
Мне нравится, что когда коммерческая технология заходит в тупик, она ищет новые пути решения намного эффективнее, чем какая-либо другая структура. Она нанимает специалистов из смежных областей, открывает гранты и лаборатории, старается найти решение в местах, куда другие даже не смотрят.
Также произошло и с компанией Cerebras. Это компания, которая разрабатывает суперкомпьютеры и процессоры для ускорения работы искусственного интеллекта.
Недавно она презентовала свои новые чипы, которые по площади гораздо объемнее всех остальных чипов (она на фото к посту). И многие стали шутить, что с такими "решениями" чипы станут размером с солнечные панели.
Но для тех, кто попытался разобраться в этом, открылась реальная причина в таком размере.
Cerebras долго разбиралась как сделать свои чипы эффективнее. Все мы знаем, что в мире, из-за развития ИИ, стало строиться гораздо больше дата центров и выпускаться чипов для них. И в какой-то момент это стало практически лидером по потреблению электроэнергии.
На регулярное обучение сверхмоделей и поддержки бесплатного доступа к чату (а значит и к вычислительным мощностям миллионам пользователей) требуется огромный расход энергии каждый день.
В итоге все упирается в то, сколько энергии и как потребляют эти чипы.
По расчетам Cerebras для перемещения 1 бита информации в чипе требуется около 1–10 pJ энергии. А с их новым чипом большей площади для той же операции требуется всего 0.1 pJ энергии! Экономия значительная!
Это достигается за счет того, что перемещение битов информации в рамках чипа намного дешевле, чем перемещение данных с одного чипа на другой.
На мой взгляд это потрясающе! В то время, как все взгляды устремлены на флагманские модели типа Астры и Фейбл, такие компании действительно делают революцию в мире.
#chips
Дисклеймер
Сегодня ава и название канала, наконец, поменялись. Я долго колебался на этот счет и думал оставить "как есть", но лучше уже сделать этот шаг и перейти более регулярным постам на темы, которые заходят и нравятся мне самому. Надеюсь, вам все также будут заходить формат.
---
Мне нравится, что когда коммерческая технология заходит в тупик, она ищет новые пути решения намного эффективнее, чем какая-либо другая структура. Она нанимает специалистов из смежных областей, открывает гранты и лаборатории, старается найти решение в местах, куда другие даже не смотрят.
Также произошло и с компанией Cerebras. Это компания, которая разрабатывает суперкомпьютеры и процессоры для ускорения работы искусственного интеллекта.
Недавно она презентовала свои новые чипы, которые по площади гораздо объемнее всех остальных чипов (она на фото к посту). И многие стали шутить, что с такими "решениями" чипы станут размером с солнечные панели.
Но для тех, кто попытался разобраться в этом, открылась реальная причина в таком размере.
Cerebras долго разбиралась как сделать свои чипы эффективнее. Все мы знаем, что в мире, из-за развития ИИ, стало строиться гораздо больше дата центров и выпускаться чипов для них. И в какой-то момент это стало практически лидером по потреблению электроэнергии.
На регулярное обучение сверхмоделей и поддержки бесплатного доступа к чату (а значит и к вычислительным мощностям миллионам пользователей) требуется огромный расход энергии каждый день.
В итоге все упирается в то, сколько энергии и как потребляют эти чипы.
По расчетам Cerebras для перемещения 1 бита информации в чипе требуется около 1–10 pJ энергии. А с их новым чипом большей площади для той же операции требуется всего 0.1 pJ энергии! Экономия значительная!
Это достигается за счет того, что перемещение битов информации в рамках чипа намного дешевле, чем перемещение данных с одного чипа на другой.
На мой взгляд это потрясающе! В то время, как все взгляды устремлены на флагманские модели типа Астры и Фейбл, такие компании действительно делают революцию в мире.
#chips
👍10❤4
GTA6, Cyberleek, блокчейн и безопасность
Увидел несколько постов (тут и тут) про Cyberleek — хакера или группу, стоящую за утечками материалов по GTA 6, — и решил сделать пост на канале, так как это высший уровень анонимности и профессионализма!
У них довольно необычная система контакта, построенная вокруг Session и Monero.
Пройдусь кратко, о чем узнал из твитов.
На странице Contact сайт сначала генерирует новую анонимную учётную запись Session и выдаёт recovery-фразу из 12 слов. Её нужно сохранить самостоятельно: если потерять эти слова, восстановить аккаунт уже невозможно, и Cyberleek не сможет связаться с вами.
После этого генерируется уникальная сумма в Monero. Например, на скриншоте — 400.818811529987 XMR. И здесь самое интересное: Cyberleek прямо пишет, что цифры после десятичной точки являются уникальным ID. Отправить нужно именно эту сумму, без округления.
Получается, 400 XMR — это contact fee, а 12 цифр после запятой используются как идентификатор конкретного Session-аккаунта. По описанию системы, эта информация генерируется на стороне клиента, поэтому после получения платежа Cyberleek может определить соответствующий Session и связаться с отправителем.
Именно поэтому они рекомендуют отправлять Monero с личного кошелька вроде Cake Wallet или Feather, а не с биржи. При выводе с exchange дробная часть суммы может быть округлена или изменена, и тогда идентификатор перестанет работать.
При этом это не совсем тот ransom-сценарий, который можно было представить из новостей о хакере. На самом сайте Cyberleek отдельно подчёркивает, что это не выкуп за прекращение утечек. Они заявляют, что привлекают средства через поддержку сообщества и стратегические партнёрства, а Monero-платёж используется как плата за установление контакта. Через Session можно обсуждать рекламные размещения, например watermark'и в видео, или заказывать эксклюзивные и кастомные игровые материалы для конкретных брендов.
Интересно устроен и сам сайт. Он размещён через Arweave — децентрализованную сеть хранения данных, а доступ к нему осуществляется через множество gateway сети ar.io. Поэтому отключение одного сервера или gateway не означает, что сайт исчезнет: тот же контент продолжает храниться в Arweave и может быть доступен через другие точки входа.
В итоге получается довольно необычная комбинация: Session для приватной коммуникации, Monero одновременно как платёж и механизм идентификации контакта, а Arweave — для устойчивого размещения сайта.
Это, конечно, само по себе не доказывает, что Cyberleek — именно группа профессиональных хакеров. Но их инфраструктура явно отличается от банальной схемы с Telegram, обычным криптокошельком и арендованным сервером. Здесь заметен осознанный упор на приватность, децентрализацию и устойчивость инфраструктуры.
И что особенно интересно — за довольно троллинговым образом Cyberleek скрывается достаточно продуманная техническая часть.
P.S. Сайт хакеров не хочу распространять, поэтому ссылок не будет.
#leak #monero
Увидел несколько постов (тут и тут) про Cyberleek — хакера или группу, стоящую за утечками материалов по GTA 6, — и решил сделать пост на канале, так как это высший уровень анонимности и профессионализма!
У них довольно необычная система контакта, построенная вокруг Session и Monero.
Пройдусь кратко, о чем узнал из твитов.
На странице Contact сайт сначала генерирует новую анонимную учётную запись Session и выдаёт recovery-фразу из 12 слов. Её нужно сохранить самостоятельно: если потерять эти слова, восстановить аккаунт уже невозможно, и Cyberleek не сможет связаться с вами.
После этого генерируется уникальная сумма в Monero. Например, на скриншоте — 400.818811529987 XMR. И здесь самое интересное: Cyberleek прямо пишет, что цифры после десятичной точки являются уникальным ID. Отправить нужно именно эту сумму, без округления.
Получается, 400 XMR — это contact fee, а 12 цифр после запятой используются как идентификатор конкретного Session-аккаунта. По описанию системы, эта информация генерируется на стороне клиента, поэтому после получения платежа Cyberleek может определить соответствующий Session и связаться с отправителем.
Именно поэтому они рекомендуют отправлять Monero с личного кошелька вроде Cake Wallet или Feather, а не с биржи. При выводе с exchange дробная часть суммы может быть округлена или изменена, и тогда идентификатор перестанет работать.
При этом это не совсем тот ransom-сценарий, который можно было представить из новостей о хакере. На самом сайте Cyberleek отдельно подчёркивает, что это не выкуп за прекращение утечек. Они заявляют, что привлекают средства через поддержку сообщества и стратегические партнёрства, а Monero-платёж используется как плата за установление контакта. Через Session можно обсуждать рекламные размещения, например watermark'и в видео, или заказывать эксклюзивные и кастомные игровые материалы для конкретных брендов.
Интересно устроен и сам сайт. Он размещён через Arweave — децентрализованную сеть хранения данных, а доступ к нему осуществляется через множество gateway сети ar.io. Поэтому отключение одного сервера или gateway не означает, что сайт исчезнет: тот же контент продолжает храниться в Arweave и может быть доступен через другие точки входа.
В итоге получается довольно необычная комбинация: Session для приватной коммуникации, Monero одновременно как платёж и механизм идентификации контакта, а Arweave — для устойчивого размещения сайта.
Это, конечно, само по себе не доказывает, что Cyberleek — именно группа профессиональных хакеров. Но их инфраструктура явно отличается от банальной схемы с Telegram, обычным криптокошельком и арендованным сервером. Здесь заметен осознанный упор на приватность, децентрализацию и устойчивость инфраструктуры.
И что особенно интересно — за довольно троллинговым образом Cyberleek скрывается достаточно продуманная техническая часть.
P.S. Сайт хакеров не хочу распространять, поэтому ссылок не будет.
#leak #monero
🔥11❤3
Графы повсюду
Если вы также следите за новостями в мире ИИ, то наверняка уже все чаще встречаете слово "граф": graph Rag, графовые нейронные сети, графовые агенты и т.д. Даже популярный блогер - математик Tivadar Danka обращал внимание, что "самый недооценённый факт линейной алгебры заключается в том, что матрицы - это графы, а графы - это матрицы".
И тогда я задумался, что, вероятно, графы это не просто схематическое изображение чего-либо, а какая-то неизученная мной сфера. И оказалось, что есть полноценная математическая область посвященная исключительно изучению графов - Теория графов.
В то же время мне на Озоне попалась книга "Введение в теорию графов" от Робина Уилсона, пятое издание. После быстрого изучения содержания книги и радости, что там много рисунков графов, я решил купить ее. Далее пару слов скажу о книге.
Если вы не математик и не любите математику, то не покупайте эту книгу. Только поначалу она кажется понятной, но чуть дальше идут сплошные теоремы и их доказательства. Это действительно сложно читать, если вы не собираетесь сильно погружаться в детали. Все эти обороты: "тогда и только тогда, когда...", "из следствия выше исходит, что..."... Очень мало понятной теории.
Лучше посмотрите видео на Ютуб по теории графов...
В общем, графы оказались куда более глубокой и интересной темой. И результаты работ по этой области окружают нас повсюду: от нейронных сетей до навигации по картам в городе!
Это сложно (пока что) объяснить, но при понимании структур графов (узлы, грани, вершины, листы, циклы и петли) начинаешь по-другому смотреть на некоторые концепции линейной алгебры и манипуляцией с пространством в ней: растяжение, сжатие и повороты. Понимаешь, что "самый быстрый маршрут" на карте, это проработанный алгоритм Дейкстры, и в основе его те же взвешенные графы и поиск пути между вершинами. Удивляешься, что графы можно легко переложить в матрицы и проводить матричные операции.
А если вы научитесь понимать продвинутые концепции теории графов типа матроидов и трансверсалей, то даже сложные алгоритмы вам покажутся очень логичными и простыми.
Если вы хотели получить новые интересные теоретические знания за пару недель, то очень рекомендую обратить внимание на теорию графов и изучить базис.
#graph
Если вы также следите за новостями в мире ИИ, то наверняка уже все чаще встречаете слово "граф": graph Rag, графовые нейронные сети, графовые агенты и т.д. Даже популярный блогер - математик Tivadar Danka обращал внимание, что "самый недооценённый факт линейной алгебры заключается в том, что матрицы - это графы, а графы - это матрицы".
И тогда я задумался, что, вероятно, графы это не просто схематическое изображение чего-либо, а какая-то неизученная мной сфера. И оказалось, что есть полноценная математическая область посвященная исключительно изучению графов - Теория графов.
В то же время мне на Озоне попалась книга "Введение в теорию графов" от Робина Уилсона, пятое издание. После быстрого изучения содержания книги и радости, что там много рисунков графов, я решил купить ее. Далее пару слов скажу о книге.
Если вы не математик и не любите математику, то не покупайте эту книгу. Только поначалу она кажется понятной, но чуть дальше идут сплошные теоремы и их доказательства. Это действительно сложно читать, если вы не собираетесь сильно погружаться в детали. Все эти обороты: "тогда и только тогда, когда...", "из следствия выше исходит, что..."... Очень мало понятной теории.
Лучше посмотрите видео на Ютуб по теории графов...
В общем, графы оказались куда более глубокой и интересной темой. И результаты работ по этой области окружают нас повсюду: от нейронных сетей до навигации по картам в городе!
Это сложно (пока что) объяснить, но при понимании структур графов (узлы, грани, вершины, листы, циклы и петли) начинаешь по-другому смотреть на некоторые концепции линейной алгебры и манипуляцией с пространством в ней: растяжение, сжатие и повороты. Понимаешь, что "самый быстрый маршрут" на карте, это проработанный алгоритм Дейкстры, и в основе его те же взвешенные графы и поиск пути между вершинами. Удивляешься, что графы можно легко переложить в матрицы и проводить матричные операции.
А если вы научитесь понимать продвинутые концепции теории графов типа матроидов и трансверсалей, то даже сложные алгоритмы вам покажутся очень логичными и простыми.
Если вы хотели получить новые интересные теоретические знания за пару недель, то очень рекомендую обратить внимание на теорию графов и изучить базис.
#graph
🔥10❤2
Интересная модель Jev
Буквально пару дней назад в Твиттере многие начали обсуждение новой модели Jev от TypeSafe. Вообще, сначала появился небольшой пост на HackerNews, а затем пошел какой-то невиданный ажиотаж вокруг этой недо-llm пере-ml. Далее расскажу, что в ней особенного.
Jev показался мне интересным не столько как очередная AI-модель, сколько как попытка переосмыслить интерфейс между AI и обычным софтом.
Классический ML обычно решает конкретную задачу: классификация, ранжирование, регрессия. Если появляется новая задача, под неё часто приходится собирать данные и обучать отдельную модель.
LLM пошли в другую сторону: одна универсальная модель может решать огромное количество задач, но взаимодействие с ней обычно происходит через генерацию текста. Даже когда мы просим JSON, внутри всё равно остаётся token-by-token генерация, а значит появляются задержки, стоимость, парсинг и проблемы с надёжностью интерфейса.
Jev предлагает промежуточный вариант. Вместо генерации произвольного текста модель возвращает типизированное решение и вероятность этого решения. То есть AI становится чем-то вроде "вероятностной функции" внутри программы.
Условно:
То есть модель не генерирует произвольный текст. Вместо этого разработчик задаёт пространство возможных решений, а модель возвращает структурированный результат и confidence.
В таком виде AI становится похож на "вероятностную функцию" внутри обычного software:
Это особенно интересно для AI workflows и агентов, где не обязательно отдавать модели контроль над всем процессом. Можно декомпозировать workflow на десятки небольших решений: routing, classification, risk assessment, tool selection, human escalation и т.д.
При этом Jev не заменяет классический ML там, где есть много хорошо размеченных данных и одна стабильная задача. И это не замена LLM для сложного reasoning или генерации текста.
Интереснее другое: может появиться отдельный слой между task-specific ML и большими генеративными моделями — достаточно универсальный, чтобы не обучать новую модель под каждое решение, но достаточно специализированный, чтобы работать намного быстрее и дешевле LLM.
Если такой подход действительно удастся масштабировать для реальных приложений, у разработчиков может появиться новый базовый инструмент для создания ИИ-систем — не чат-бот и не обычный классификатор, а модель, которую можно напрямую встраивать в логику программы и использовать для принятия отдельных решений.
На данном этапе модель находится в стадии листов ожидания, и подать заявку можно здесь: https://typesafe.ai/
А буквально утром, пару часов назад, они выкатили доступ и на OpenRouter: https://openrouter.ai/~typesafe/jev-latest
#jev
Буквально пару дней назад в Твиттере многие начали обсуждение новой модели Jev от TypeSafe. Вообще, сначала появился небольшой пост на HackerNews, а затем пошел какой-то невиданный ажиотаж вокруг этой недо-llm пере-ml. Далее расскажу, что в ней особенного.
Jev показался мне интересным не столько как очередная AI-модель, сколько как попытка переосмыслить интерфейс между AI и обычным софтом.
Классический ML обычно решает конкретную задачу: классификация, ранжирование, регрессия. Если появляется новая задача, под неё часто приходится собирать данные и обучать отдельную модель.
LLM пошли в другую сторону: одна универсальная модель может решать огромное количество задач, но взаимодействие с ней обычно происходит через генерацию текста. Даже когда мы просим JSON, внутри всё равно остаётся token-by-token генерация, а значит появляются задержки, стоимость, парсинг и проблемы с надёжностью интерфейса.
Jev предлагает промежуточный вариант. Вместо генерации произвольного текста модель возвращает типизированное решение и вероятность этого решения. То есть AI становится чем-то вроде "вероятностной функции" внутри программы.
Условно:
input → model → { decision, probability } → application logicТо есть модель не генерирует произвольный текст. Вместо этого разработчик задаёт пространство возможных решений, а модель возвращает структурированный результат и confidence.
В таком виде AI становится похож на "вероятностную функцию" внутри обычного software:
if model(x).probability > threshold:
Это особенно интересно для AI workflows и агентов, где не обязательно отдавать модели контроль над всем процессом. Можно декомпозировать workflow на десятки небольших решений: routing, classification, risk assessment, tool selection, human escalation и т.д.
При этом Jev не заменяет классический ML там, где есть много хорошо размеченных данных и одна стабильная задача. И это не замена LLM для сложного reasoning или генерации текста.
Интереснее другое: может появиться отдельный слой между task-specific ML и большими генеративными моделями — достаточно универсальный, чтобы не обучать новую модель под каждое решение, но достаточно специализированный, чтобы работать намного быстрее и дешевле LLM.
Если такой подход действительно удастся масштабировать для реальных приложений, у разработчиков может появиться новый базовый инструмент для создания ИИ-систем — не чат-бот и не обычный классификатор, а модель, которую можно напрямую встраивать в логику программы и использовать для принятия отдельных решений.
На данном этапе модель находится в стадии листов ожидания, и подать заявку можно здесь: https://typesafe.ai/
А буквально утром, пару часов назад, они выкатили доступ и на OpenRouter: https://openrouter.ai/~typesafe/jev-latest
#jev
👍7
Какой язык программирования учить сейчас?
На днях в Твиттере увидел небольшой пост о развитии нейронок и агентов для программирования и то, как это влияет на текущий тренд в использовании языков для разработки проектов. Кратко говоря, там говорилось, что при стирании границ между сложностью изучения языков, ведь для llm вообще без разницы, что использовать, чаша весов будет склоняться в сторону более быстрых и оптимальных языков программирования, вроде Rust или Go. Python же может отойти на второй план.
В общем, мне кажется, что это имеет смысл.
Я работаю сейчас над двумя своими новыми задумками, и с развитием моделей вроде Opus 5 / Fable 5.1, я перестал контролировать выбор языка для написания приложений. После нескольких итераций по архитектуре приложений, выбор был сделан в сторону Rust в одном случае, и Rust / Go в другом. И выбор аргументировался тем, что с ними будет меньше проблем при реализации кода, а также они намного быстрее работают.
К чему это может привести на рынке?
1. На мой взгляд, в течение последующих нескольких лет крупные игроки также начнут оптимизировать свои платформы, снижая затраты на оборудования и нагрузку на него.
2. Знания языков, в плане технических интервью, могут отойти на второй план. На собеседованиях могут начать спрашивать не столько самому написать код, сколько написать запрос в нейронку на создание блока кода с определенным техническим решением. И тут от кандидата потребуется знать намного больше "общей" информации о языках и программировании, чем о формировании циклов в Python или Rust. Нужны будут знания алгоритмов, сетевых архитектур, базовой математики, работы dns и cdn, и т.д.
3. Оценены будут только сеньоры с опытом до бума программирования с нейронками. Вероятно, только они смогут создавать абсолютно новые решения, тем самым двигая и развитие нейронок.
4. Для нас с вами появятся места для поддержания и развития продукта, мелкой разработки и оркестрации потоков агентов.
5. При этом вполне вероятно, что задачи в компаниях уже будут распределяться не тимлидами и руководящими должностями, а другим типом нейронок типа Jev. Это сделает процессы более быстрыми и прозрачными.
Вообще очень интересно к чему это действительно приведет. А какие у вас прогнозы?
#langs
На днях в Твиттере увидел небольшой пост о развитии нейронок и агентов для программирования и то, как это влияет на текущий тренд в использовании языков для разработки проектов. Кратко говоря, там говорилось, что при стирании границ между сложностью изучения языков, ведь для llm вообще без разницы, что использовать, чаша весов будет склоняться в сторону более быстрых и оптимальных языков программирования, вроде Rust или Go. Python же может отойти на второй план.
В общем, мне кажется, что это имеет смысл.
Я работаю сейчас над двумя своими новыми задумками, и с развитием моделей вроде Opus 5 / Fable 5.1, я перестал контролировать выбор языка для написания приложений. После нескольких итераций по архитектуре приложений, выбор был сделан в сторону Rust в одном случае, и Rust / Go в другом. И выбор аргументировался тем, что с ними будет меньше проблем при реализации кода, а также они намного быстрее работают.
К чему это может привести на рынке?
1. На мой взгляд, в течение последующих нескольких лет крупные игроки также начнут оптимизировать свои платформы, снижая затраты на оборудования и нагрузку на него.
2. Знания языков, в плане технических интервью, могут отойти на второй план. На собеседованиях могут начать спрашивать не столько самому написать код, сколько написать запрос в нейронку на создание блока кода с определенным техническим решением. И тут от кандидата потребуется знать намного больше "общей" информации о языках и программировании, чем о формировании циклов в Python или Rust. Нужны будут знания алгоритмов, сетевых архитектур, базовой математики, работы dns и cdn, и т.д.
3. Оценены будут только сеньоры с опытом до бума программирования с нейронками. Вероятно, только они смогут создавать абсолютно новые решения, тем самым двигая и развитие нейронок.
4. Для нас с вами появятся места для поддержания и развития продукта, мелкой разработки и оркестрации потоков агентов.
5. При этом вполне вероятно, что задачи в компаниях уже будут распределяться не тимлидами и руководящими должностями, а другим типом нейронок типа Jev. Это сделает процессы более быстрыми и прозрачными.
Вообще очень интересно к чему это действительно приведет. А какие у вас прогнозы?
#langs
🤔11
Задача с полуоткрытым кодом
На днях, в процессе создания одного приложения, столкнулся с интересной задачей, кейсом которой хочу сегодня поделиться с вами.
История разработки долгая, поэтому опишу ее кратко: в работе я пришел к потребности отслеживать состояние сервера vps и сайтов в каком-нибудь "одном окне". Существующие решения меня не устроили и я захотел создать свое приложение, которое будет решать мои задачи. Ну, и в последствии сделать проект доступным для каждого.
Суть заключается в том, что ты ставишь пакет с опенсорс решениями к себе на vps и приложение может читать данные на основе запросов этого пакета. По сути, это полностью независимое локальное приложение. Данные никуда не уходят к третьим лицам. Только прямая связь между приложением на компьютере и личным vps. Работает без облака, без регистрации и смс.
И вот встала проблема доверия. Я-то понятно, создал приложение, собрал пакет, знаю, что там и как работает. Но если кто-то попросит меня установить к себе на сервер vps какое-то опенсорс решение без возможности изучить его, я просто пошлю подальше такую просьбу.
Задача осложнялась тем, что я не хотел открывать фактический код приложения. В идеале предполагалось, чтобы пользователи могли заранее изучить, все то, что будет ставиться на их сервер (сами или с нейронкой) и, что еще важнее, быть уверенными, что это будет именно тот пакет, который был открыт. Дальше будут технические подробности решения.
Граница проведена так: открыто всё, что работает на сервере клиента. Это установочные файлы (скрипты установки, обновления и отката, шаблон docker-compose, конфиг Caddy), исходники агента мониторинга на Go, наша сборка Caddy с модулями ограничения частоты и DNS, а также каждая команда, которую приложение отправляет по SSH: поиск сайтов и сертификатов, копии, проверка безопасности, чтение журнала установки. Само приложение для компьютера остаётся закрытым. Проверить, что закрытое приложение отправляет именно эти команды, по репозиторию нельзя — но всё выполненное на вашем сервере видно в журнале sudo или auditd.
Первая сложность была в самих командах. Они жили строками внутри кода приложения на Rust и собирались на лету, а выложенная копия рано или поздно разошлась бы с тем, что реально выполняется. Пришлось вынести все 36 скриптов в отдельные файлы. Приложение встраивает их в себя при сборке без изменений и добавляет только две вещи: параметры строками вида ИМЯ='значение' в начале файла и данные (содержимое загружаемого конфига или текст SQL-запроса) на место специальной метки — только вызовами функций, объявленных в самом файле. К каждому скрипту есть строка в описи SERVER-SIDE.md: когда запускается, что читает, что меняет. Автоматические тесты следят, чтобы опись не отставала: каждый файл назван в описи, каждый модуль приложения, который ходит на сервер по SSH, тоже в ней есть, а скрипт, собранный строкой в коде на Rust, роняет тесты. Все скрипты прогнаны на настоящем Linux, включая полный запуск установки.
На днях, в процессе создания одного приложения, столкнулся с интересной задачей, кейсом которой хочу сегодня поделиться с вами.
История разработки долгая, поэтому опишу ее кратко: в работе я пришел к потребности отслеживать состояние сервера vps и сайтов в каком-нибудь "одном окне". Существующие решения меня не устроили и я захотел создать свое приложение, которое будет решать мои задачи. Ну, и в последствии сделать проект доступным для каждого.
Суть заключается в том, что ты ставишь пакет с опенсорс решениями к себе на vps и приложение может читать данные на основе запросов этого пакета. По сути, это полностью независимое локальное приложение. Данные никуда не уходят к третьим лицам. Только прямая связь между приложением на компьютере и личным vps. Работает без облака, без регистрации и смс.
И вот встала проблема доверия. Я-то понятно, создал приложение, собрал пакет, знаю, что там и как работает. Но если кто-то попросит меня установить к себе на сервер vps какое-то опенсорс решение без возможности изучить его, я просто пошлю подальше такую просьбу.
Задача осложнялась тем, что я не хотел открывать фактический код приложения. В идеале предполагалось, чтобы пользователи могли заранее изучить, все то, что будет ставиться на их сервер (сами или с нейронкой) и, что еще важнее, быть уверенными, что это будет именно тот пакет, который был открыт. Дальше будут технические подробности решения.
Граница проведена так: открыто всё, что работает на сервере клиента. Это установочные файлы (скрипты установки, обновления и отката, шаблон docker-compose, конфиг Caddy), исходники агента мониторинга на Go, наша сборка Caddy с модулями ограничения частоты и DNS, а также каждая команда, которую приложение отправляет по SSH: поиск сайтов и сертификатов, копии, проверка безопасности, чтение журнала установки. Само приложение для компьютера остаётся закрытым. Проверить, что закрытое приложение отправляет именно эти команды, по репозиторию нельзя — но всё выполненное на вашем сервере видно в журнале sudo или auditd.
Первая сложность была в самих командах. Они жили строками внутри кода приложения на Rust и собирались на лету, а выложенная копия рано или поздно разошлась бы с тем, что реально выполняется. Пришлось вынести все 36 скриптов в отдельные файлы. Приложение встраивает их в себя при сборке без изменений и добавляет только две вещи: параметры строками вида ИМЯ='значение' в начале файла и данные (содержимое загружаемого конфига или текст SQL-запроса) на место специальной метки — только вызовами функций, объявленных в самом файле. К каждому скрипту есть строка в описи SERVER-SIDE.md: когда запускается, что читает, что меняет. Автоматические тесты следят, чтобы опись не отставала: каждый файл назван в описи, каждый модуль приложения, который ходит на сервер по SSH, тоже в ней есть, а скрипт, собранный строкой в коде на Rust, роняет тесты. Все скрипты прогнаны на настоящем Linux, включая полный запуск установки.
Вторая сложность — как доказать, что установилось именно опубликованное. В первом варианте плана человек должен был сравнить скачанный архив с архивом, собранным из открытого кода. Это оказалось невыполнимо: сервер упаковывает архив сам, и байты сжатия могут отличаться. Решение такое: подписывается не архив, а опись версии — список файлов с правами и отпечатком SHA-256 каждого. Подпись делается ключом minisign (Ed25519 поверх хеша BLAKE2b), тем же, которым подписываются обновления приложения, и приложение не ставит версию без годной подписи. Приватная половина ключа хранится только на компьютере разработчика и никогда не попадает ни на сервер, ни в CI. Каталог версии в открытом репозитории — содержимое архива байт в байт, разложенное тем же кодом, которым сервер этот архив раздаёт. В репозитории лежит небольшая утилита на Go: одна команда проверяет подпись, сверяет каждый файл с описью, проверяет, что все образы закреплены дайджестом, а с ключом - archive сравнивает с тегом скачанный архив файл за файлом. Подпись можно проверить и стандартной программой minisign — публичный ключ лежит в репозитории, а его отпечаток опубликован ещё в двух независимых местах.
Третья часть — образы Docker. Раньше я собирал их на своей машине, и связь «этот образ собран из этого кода» держалась на моем честном слове. Теперь образы агента и Caddy собирает GitHub Actions самого открытого репозитория по метке agent-<версия> или caddy-<версия>, сразу для amd64 и arm64. Go кросс-компилируется, а не собирается в эмуляции: под QEMU он у нас однажды намертво зависал. Каждый образ получает аттестацию происхождения через Sigstore — подписанную запись о том, из какого коммита и каким процессом он собран. Проверить её можно командой gh attestation verify. По дороге обнаружилось, что сборка Caddy брала сторонние модули «самые свежие на сегодня», и из одного и того же кода в разные дни получался немного разный результат. Теперь модули закреплены точными версиями, а базовые образы — дайджестами.
На каждую метку версии GitHub запускает публичную проверку. Она сверяет подпись и опись, проверяет аттестацию наших образов и сравнивает исходники агента в коммите, из которого собран образ, с исходниками в метке версии, а заодно ищет в коде случайно попавшие секреты. Красный крестик у метки видят все. Сам CI защищён: все сторонние действия закреплены полным хешем коммита, а не тегом, который автор может передвинуть. У процессов минимальные права, сборка из чужих pull request не запускается вовсе. Опубликованные метки нельзя удалить или передвинуть никому, включая нас, поэтому ошибка в выпущенной версии исправляется только следующей версией. Так и случилось с первым выпуском: мы опубликовали его не в том порядке, и исходники агента в нём на пару комментариев новее образа. Переписывать опубликованное не стали, а написали об этом прямо в README. Начиная со следующей версии такое расхождение ловит автоматическая проверка.
Публикует всё это скрипт: он собирает зеркало строго по белому списку каталогов, сам гоняет те же проверки и откажется публиковать, если нашёл адрес наших серверов, путь с машины разработчика, приватный ключ или токен. Ссылки на открытый код есть на главной сайта (расскажу о нем позже), в документации, на странице загрузки и в самом приложении: на шаге проверки сервера ещё до установки и на экране установки — со ссылкой на метку именно той версии, которая поедет на ваш сервер.
Если все вышесказанное обобщить в пару слов то: я постарался сделать так, чтобы весь код, который будет установлен на сервере клиента мог быть проверен как вручную, так и автоматически. Кроме того, построена достаточно сильная защита от подделки пакета на каком-либо этапе.
Думаю, нужно добавить, что я сам бы такую систему не смог бы придумать, и всю работу сделал Claude Code, объясняя мне каждый этап и отвечая на вопросы "почему и как".
На самом деле, нейронки могут вас очень круто обучить новым сферам разработки, если вы будете не просто соглашаться со всем, что он предлагает, а задавать вопросы и также погружаться в тему.
Третья часть — образы Docker. Раньше я собирал их на своей машине, и связь «этот образ собран из этого кода» держалась на моем честном слове. Теперь образы агента и Caddy собирает GitHub Actions самого открытого репозитория по метке agent-<версия> или caddy-<версия>, сразу для amd64 и arm64. Go кросс-компилируется, а не собирается в эмуляции: под QEMU он у нас однажды намертво зависал. Каждый образ получает аттестацию происхождения через Sigstore — подписанную запись о том, из какого коммита и каким процессом он собран. Проверить её можно командой gh attestation verify. По дороге обнаружилось, что сборка Caddy брала сторонние модули «самые свежие на сегодня», и из одного и того же кода в разные дни получался немного разный результат. Теперь модули закреплены точными версиями, а базовые образы — дайджестами.
На каждую метку версии GitHub запускает публичную проверку. Она сверяет подпись и опись, проверяет аттестацию наших образов и сравнивает исходники агента в коммите, из которого собран образ, с исходниками в метке версии, а заодно ищет в коде случайно попавшие секреты. Красный крестик у метки видят все. Сам CI защищён: все сторонние действия закреплены полным хешем коммита, а не тегом, который автор может передвинуть. У процессов минимальные права, сборка из чужих pull request не запускается вовсе. Опубликованные метки нельзя удалить или передвинуть никому, включая нас, поэтому ошибка в выпущенной версии исправляется только следующей версией. Так и случилось с первым выпуском: мы опубликовали его не в том порядке, и исходники агента в нём на пару комментариев новее образа. Переписывать опубликованное не стали, а написали об этом прямо в README. Начиная со следующей версии такое расхождение ловит автоматическая проверка.
Публикует всё это скрипт: он собирает зеркало строго по белому списку каталогов, сам гоняет те же проверки и откажется публиковать, если нашёл адрес наших серверов, путь с машины разработчика, приватный ключ или токен. Ссылки на открытый код есть на главной сайта (расскажу о нем позже), в документации, на странице загрузки и в самом приложении: на шаге проверки сервера ещё до установки и на экране установки — со ссылкой на метку именно той версии, которая поедет на ваш сервер.
Если все вышесказанное обобщить в пару слов то: я постарался сделать так, чтобы весь код, который будет установлен на сервере клиента мог быть проверен как вручную, так и автоматически. Кроме того, построена достаточно сильная защита от подделки пакета на каком-либо этапе.
Думаю, нужно добавить, что я сам бы такую систему не смог бы придумать, и всю работу сделал Claude Code, объясняя мне каждый этап и отвечая на вопросы "почему и как".
На самом деле, нейронки могут вас очень круто обучить новым сферам разработки, если вы будете не просто соглашаться со всем, что он предлагает, а задавать вопросы и также погружаться в тему.
👍6
Промо видео для SaaS и других ваших проектов
Хочу поделить с вами одним из своих открытий этой осени и рассказать, что сейчас очень легко делать различные промо / обучающие ролики с помощью нейронных сетей.
Вообще у меня всегда было большой проблемой варианты продвижения своих проектов на рынок. Можно создать красивый продукт, анализатор багов и т.д., но без внятного рассказа, что это такое и какую проблему решает, никакого внимания в соцсетях это не привлечет.
Кроме того, одно дело создать видео, как визуальную рекламу, которую мы все можем увидеть по телевизору, другое - видео с демонстрацией кода. Если вы никогда ранее не пытались создать видео с кодом, то будет сложно объяснить, как это напряжно.
Сейчас же нейросети значительно облегчили эту работу.
На днях я выпускаю один небольшой проект, который изначально создавал под свои нужды, но потом решил немного оформить и выпустить в свет. В коце разработки, как обычно, встала проблема визуальной рекламы.
И Claude посоветовал мне обратить внимание на проекты, которые помогают сделать видео из React кадров.
Ты описываешь каждый кадр видео как React-компонент: текст, изображения, анимации, графику и т.д. Remotion последовательно рендерит эти кадры и собирает их в обычный видеофайл, например MP4.
То есть логика примерно такая: React-код → набор кадров → рендеринг → видео.
Главное преимущество — видео можно програмно генерировать и автоматически менять его содержимое: текст, данные, изображения, длительность, анимации и т.д.
Что самое замечательное, так это то, что Claude или другая нейронка могут сами создавать эти react-компоненты, наполнять демо данными ваш проект и собирать финальное видео.
Процесс работы строится так: вы создаете (сами или с нейронкой) сценарий, обсуждаете его и потом просите собрать видео. После сборки можно свободно корректировать кадры и послания. Все работает исключительно из диалога с моделью ии.
Единственный минус, видео получается без звука. Для решения этой проблемы можно также попросить специализированную нейронку озвучить текст сценария.
Из своих опытом могу сказать, что опенсорс проекты, типа voice studio или fish audio, хороши, но не достаточно правдоподобны. В ролике выше голос был создан с помощью 11 labs. Там можно прослушать множество вариантов звучания текста и подобрать тот, который вам понравится. Это также очень удобно.
В самом конце, единственное, что вам нужно будет сделать, это подобрать фоновую музыку и правильно наложить озвучку на видео, чтобы совпадали кадры и слова. Я использовал программу Capcut.
В итоге получился ролик, который вы можете увидеть выше. Мне кажется, что получилось довольно хорошо, учитывая тот факт, что я сам бы намного хуже озвучил текст на английском языке.
Пару лет назад, когда я сам создавал пару роликов на канале, я тратил день-два на запись и монтаж. Видео выше было создано буквально за час.
Если у вас будут свои проекты, то крайне рекомендую вам связку програм:
Claude -> Remotion -> 11 labs -> Capcut
Если вы что-то создаете свое, буду раз услышать! Может соберем чатик с обсуждениями продвижения и стратегий для этого!
#video
Хочу поделить с вами одним из своих открытий этой осени и рассказать, что сейчас очень легко делать различные промо / обучающие ролики с помощью нейронных сетей.
Вообще у меня всегда было большой проблемой варианты продвижения своих проектов на рынок. Можно создать красивый продукт, анализатор багов и т.д., но без внятного рассказа, что это такое и какую проблему решает, никакого внимания в соцсетях это не привлечет.
Кроме того, одно дело создать видео, как визуальную рекламу, которую мы все можем увидеть по телевизору, другое - видео с демонстрацией кода. Если вы никогда ранее не пытались создать видео с кодом, то будет сложно объяснить, как это напряжно.
Сейчас же нейросети значительно облегчили эту работу.
На днях я выпускаю один небольшой проект, который изначально создавал под свои нужды, но потом решил немного оформить и выпустить в свет. В коце разработки, как обычно, встала проблема визуальной рекламы.
И Claude посоветовал мне обратить внимание на проекты, которые помогают сделать видео из React кадров.
Ты описываешь каждый кадр видео как React-компонент: текст, изображения, анимации, графику и т.д. Remotion последовательно рендерит эти кадры и собирает их в обычный видеофайл, например MP4.
То есть логика примерно такая: React-код → набор кадров → рендеринг → видео.
Главное преимущество — видео можно програмно генерировать и автоматически менять его содержимое: текст, данные, изображения, длительность, анимации и т.д.
Что самое замечательное, так это то, что Claude или другая нейронка могут сами создавать эти react-компоненты, наполнять демо данными ваш проект и собирать финальное видео.
Процесс работы строится так: вы создаете (сами или с нейронкой) сценарий, обсуждаете его и потом просите собрать видео. После сборки можно свободно корректировать кадры и послания. Все работает исключительно из диалога с моделью ии.
Единственный минус, видео получается без звука. Для решения этой проблемы можно также попросить специализированную нейронку озвучить текст сценария.
Из своих опытом могу сказать, что опенсорс проекты, типа voice studio или fish audio, хороши, но не достаточно правдоподобны. В ролике выше голос был создан с помощью 11 labs. Там можно прослушать множество вариантов звучания текста и подобрать тот, который вам понравится. Это также очень удобно.
В самом конце, единственное, что вам нужно будет сделать, это подобрать фоновую музыку и правильно наложить озвучку на видео, чтобы совпадали кадры и слова. Я использовал программу Capcut.
В итоге получился ролик, который вы можете увидеть выше. Мне кажется, что получилось довольно хорошо, учитывая тот факт, что я сам бы намного хуже озвучил текст на английском языке.
Пару лет назад, когда я сам создавал пару роликов на канале, я тратил день-два на запись и монтаж. Видео выше было создано буквально за час.
Если у вас будут свои проекты, то крайне рекомендую вам связку програм:
Claude -> Remotion -> 11 labs -> Capcut
Если вы что-то создаете свое, буду раз услышать! Может соберем чатик с обсуждениями продвижения и стратегий для этого!
#video
🔥3