Сколько нужно бит, чтобы представить одно число из континуума ℵ₁ чисел?
Ответ: ℵ₀ бит.
Сколько нужно бит, чтобы представить одно число из счётного множества ℵ₀ чисел?
Ответ: ℵ₋₁ бит.
Произвольное число из континуума (почти все они трансцендентные) требует бесконечно бит для представления, а произвольное число из счётного множества (натуральные, целые, рациональные) требует непременно конечно бит.
ℵ₋₁ это достаточно.
Эта статья про мои эксперименты с языковыми моделями, в которых не используется машинное обучение и аппаратное ускорение. Чтобы избежать недопонимания поясню, что я имею ввиду под языковой моделью (ЯМ).
ЯМ это совокупность алгоритмов, структур данных и собственно данных для генерации связного текста в ответ на запрос. Каким образом ЯМ генерирует ответы определяется способом её реализации. В канонической реализации ЯМ используются методы машинного обучения и мощные аппаратные ускорители. В моей реализации ЯМ я хочу получать связный текст в ответ на запрос без машинного обучения и без аппаратного ускорения.
Если свериться с Википедией на английском и на русском языках, или с многочисленными публикациями про (Large/Small) Language Models, то мои определение и понимание… несколько неканонические. Поскольку я экспериментирую для себя (я сам себе работодатель), то заранее соглашусь с любыми мнениями о неканоничности моего определения ЯМ.
Буду благодарен комментариям - если окажется, что подобное изложенному в этой статье уже было на просторах интернета. Как минимум такие подсказки избавят меня от хождения по тупикам. А как максимум, я надеюсь, позволят сделать мои дальнейшие эксперименты более успешными.
Последующий текст состоит из нескольких небольших частей. Сначала расскажу о своих мыслях, из которых возникли мои идеи для экспериментов. Далее, о своём текущем подходе к реализации ЯМ. Пока он совсем прост. Чем-то напоминает классический подходы Markov chains и n-grams, но без статистических и вероятностных методов.
Проверяем, может ли GPU-планировщик MPPI-Generic работать без глобального планера. Самодельный симулятор, контроллер с приоритетом угловой скорости, сравнение с State Lattice и RPP vs MPPI, справился, но есть нюансы.
Месяц назад я прочитал на Хабре статью про нейронные клеточные автоматы. Маленькие нейросети управляют клетками на сетке, клетки сами собираются в букву T или крест, и всё это обучается без учителя через что‑то вроде эволюции. Я подумал: круто, повторю за пару вечеров, посмотрю, как себя ведёт.
Эта статья — о том, что было дальше. Спойлер: пара вечеров превратилась в месяц, я провёл 22 эксперимента, упёрся в потолок IoU 0.44 на простой букве T, и главное, чему научился — вообще не о нейросетях.
Привет, Хабр. Видел в интернете кейс. где сделали бота с LLM для торговли на Polymarket и он сделал $10k из $1k за месяц. Ну и чо бы не попробовать что то такое же сделать! Побочный проект, чисто по приколу. Вооружил его вирутальным стартовым капиталом — $100 нарисованных.
И вот на второй день этот несерьёзный проект показал +9% на счёте.
В разработке ПО произведение двух целых чисел часто вычисляется до фиксированного количества битов с переполнением. Возьмём для примера 8-битные целые. Если умножить 127 на 127, то мы получим число 1 в виде 8-битного беззнакового целого с переполнением. Реальное полное произведение равно 16129. Для представления 16129 обычно используются 16 бит точности.
Таким образом у нас появляется понятие полного произведения. Полное произведение двух 32-битных чисел обычно представляется при помощи 64 бит. У меня возник вопрос, какую долю всех 64-битных чисел можно записать, как произведение двух 32-битных целых.
Всем привет, на связи команда NeuroCore. Сегодня расскажем про кейс разработки системы видеоаналитики для магазинов самообслуживания: почему fisheye-камеры - настоящее проклятие, почему SORT и DeepSORT не справились с задачей, как мы выстроили конвейер от детекции до бизнес-событий, и какие инженерные решения позволили добиться стабильной работы в продакшене.
Дано: магазины самообслуживания, которые работают без кассиров и продавцов. Покупатель входит по QR, выбирает товары, рассчитывается и выходит. Заказчику нужна автоматизированная система отслеживания: кто находится внутри, сколько времени, в каких зонах, а также распознает несанкционированный доступ и вход группами. В случае нарушений, система должна генерировать алерты по 7 типам событий.
Что есть: одна потолочная fisheye-камера, которая покрывает весь зал. Это идеальный выбор для ритейла: угол обзора 180 градусов, не нужно ставить десятки обычных камер, не нужно сшивать панорамы. Но за этот комфорт приходится платить.
В первой статье я высказал простую идею: если вычисление можно свести к конечной таблице операции, его можно проверять, а не угадывать. То есть его можно свести не к "модель выдала вероятность 0,67", а просто открыть таблицу и сказать: вот ячейка, вот результат, rc=0.
Эта статья — прямое продолжение первой статьи (сейчас у меня на руках значительно отличающаяся рабочая модель ИИ-движка). Но сразу честно: я не собираюсь раскрывать здесь внутреннюю кухню "GALO AI". Ни устройство нейрона, ни приватные маршруты мышления. Покажу только основополагающую математику, вернее, маленькую конечную структуру, которую можно взять руками, прогнать скриптом и попытаться сломать контрпримером.
Ключевая идея проста до невозможности: я взял обычное сложение по модулю и изменил в его таблице ровно одну строку.
Этого хватило, чтобы структура перестала быть полем, кольцом и моноидом.
В этой статье разберём архитектуру полноценного фьючерсного сканера для биржи BingX, построенного на Python. Система анализирует десятки и сотни торговых инструментов в реальном времени, фильтрует активы по Open Interest и Funding Rate, рассчитывает технические индикаторы EMA и MACD, а затем формирует торговые сигналы на основе синхронизации нескольких независимых факторов.
Речь пойдёт не о полноценной архитектуре рыночного анализатора, пригодного для дальнейшего масштабирования: подключения Telegram-уведомлений, машинного обучения, кластерного анализа, order flow и полностью автоматической торговли через API.
Все файлы загружены на GITHUB. В статье описываю в основном логическую часть и ньюансы. Так что крайне советую к параллельному изучению самого скрипта и кода.
Меня часто спрашивают, почему для математиков так важны простые числа. Роль, которую они играют в математике, сравнима с ролью атомов в химии. Это фундаментальные строительные блоки целых чисел, по крайней мере, когда дело касается умножения, и довольно часто решение какой-то задачи можно редуцировать до решения её сначала для простых. Но если честно, во многом математики интересуются простыми числами из-за того, что их сложно понять. В математике куча нерешённых задач о простых числах, поэтому для тех, кого привлекают сложные головоломки, простые числа обладают определённой привлекательностью, которая почти не зависит от их практической важности в математике и связанных с ней областях наподобие криптографии.
Во многом красота математики заключается в том, что благодаря произвольному выбору можно связать две кажущиеся далёкими концепции. Впервые я увидел этот паттерн в вопросе на Math Stack Exchange. Его задал пользователь dwymark, а ответил на него Грег Мартин; вопрос связан с распределением простых чисел, а также с рациональными аппроксимациями 
.
Этот пользователь баловался с созданием графиков данных в полярных координатах, то есть нанесением точек в 2D-пространстве, но не по обычным координатам XY, а по расстоянию от точки начала координат, обычно называемому 
(радиус), и по углу прямой относительно горизонтали, обычно называемому «тета», 
.
В фольклоре разработчиков встречаются утверждения о том, что Jira (система управления проектами, разработанная Atlassian) полна по Тьюрингу. Однако в таких заявлениях нет конкретики, лишь смутные упоминания фич автоматизации. В этой статье будет приведено доказательство с инструкциями по реализации и трассировкой исполнения.
В этой части мы рассмотрим вторую важную составляющую шахматных программ - оценочную функцию. Долгие годы она находилась в роли "пасынка" для процесса разработки. Но на то существовали объективные причины.
Аннотация. В статье рассматривается физическая основа измерений Ekahau Sidekick и механизм применяемого RSSI‑offset с позиций теории антенн, теории шума радиоприёмных устройств, статистической теории сигналов и стандартов IEEE 802.11. Показано, что scalar RSSI‑offset является линейным сдвигом уровня и не моделирует ни реальный SNR клиентского устройства, ни структуру QAM‑созвездия, ни алгоритм rate adaptation, ни роуминговое поведение. Помимо пяти независимых физических и системных причин неточности, рассматриваются системные упрощения Ekahau, касающиеся MIMO‑усиления, многолучёвости, оценки airtime и визуализации SNR. Приведены верифицированные численные оценки погрешности для конкретных сценариев и практические рекомендации.
При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение.
После серии экспериментов и улучшений пришло понимание, что промышленный ИИ-агент — это не столько про LLM, сколько про качество извлечения информации и гибкую оркестрацию компонентов ИИ-агента. Что в итоге полностью поменяло архитектуру моей системы.
В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.
Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. В нашей команде мы занимаемся исследованиями в области рекомендаций на последовательностях (sequential recommendations). Например, прослушивания музыки или просмотры карточек товаров можно представить как последовательность взаимодействий пользователя. А для моделирования последовательностей, как мы знаем, отлично подходят трансформеры: популярные варианты в рекомендациях — SASRec и BERT4Rec. Эти модели прекрасно справляются с задачей рекомендаций на основе взаимодействий, но они ничего не знают о самих товарах.
Допустим, пользователь покупает безлактозный йогурт и растительный сыр. У нас сразу появляется гипотеза: возможно, пользователь не переносит лактозу. Однако для sequential‑модели это не очевидный факт, а статистический паттерн, который нужно выучить из взаимодействий. Если данных мало, товары редкие или связи между ними плохо представлены в истории, то такой смысл легко потерять.
Большие языковые модели в данной ситуации выглядят подходящим решением. Они умеют читать описания товаров, анализировать историю взаимодействий и выделять предпочтения пользователя. Казалось бы, можно просто взять LLM и использовать её как рекомендательную систему. Но и здесь всё не так просто: использовать LLM на инференсе дорого, медленно и сложно с точки зрения масштабирования на миллионы пользователей.
Это третья и финальная часть истории. По исходному плану их должно было быть две, потом я честно обещал уложиться в три после второй, и вот мы здесь. Будем считать это уроком: при оценке объёма любого личного проекта смело умножайте свою оценку на полтора, как учит классика. Спасибо тем, кто дочитал до этого момента, и отдельное уважение тем, кто пришёл сюда с первой части без перерывов.
Если совсем коротко напомнить, где мы остановились во второй части, то картинка такая. Гибридная архитектура из трёх слоёв: ECS-миры снизу как операционный движок для большого количества однотипных сущностей, акторы-менеджеры посередине как тактический уровень, и более тяжёлые акторы или сервисы наверху как стратегический мозг. Сбоку реактивная среда, которая подбрасывает события. Под всем этим слой данных на DuckDB. Технологически: Bevy ECS на Rust для движка, лёгкая акторная абстракция поверх, egui для дев-интерфейса, WASM для демонстраций в браузере, Godot 4 опционально как 3D-витрина. Этот расклад мне показался самым интересным, и в этой части я попытаюсь показать, к чему он прикладывается на практике.
Классические рекомендательные системы в крупных компаниях — это десятки микросервисов, каскадная фильтрация и тысячи ручных признаков. Такой стек может надёжно работать годами, но неизбежно упирается в фундаментальную проблему: он перестаёт масштабироваться. Качество выходит на плато — всё меньше отдачи от новых фич, усложнения моделей и наращивания данных.
Генеративная постановка, когда модель восстанавливает целые последовательности пользовательских действий, обещает принести в рекомендации законы масштабирования, снизить операционную сложность и открыть путь к единой кросс‑сервисной модели. Но между обещанием и продакшеном — огромная дистанция. Нужно понять, какая токенизация работает, как устроить претрейн, что делать с контекстом, негативами и задержками в реальных распределённых системах.
Последний год мы адаптировали нашу генеративную модель персонализации ARGUS под разные домены внутри Яндекса, меняли архитектуру, пересобирали обучение и пробовали новые способы интеграции в продакшене. В этой статье я расскажу, какие решения сработали, какие — нет и что нам дала генеративная постановка в реальных рекомендательных системах.
В этой части мы коснемся некоторых наиболее ходовых понятий, которые часто используются в терминологии компьютерных шахмат и без которых затруднительно конструктивное обсуждение вопросов перебора. Также рассмотрим некоторые второстепенные методы направленного перебора, которые тем не менее глубоко интегрированы в структуру поиска. И в концовке обсудим общий порядок обхода всего дерева перебора целиком.
Здравствуй, Хабр! Разработка ингибиторов мутантного онкобелка KRAS ( особенно формы G12D)- одна из главных задач современной онкофармакологии. Используя наш проприетарный матаппарат мы рассчитали несколько секвенсов под целевой карман мишени. Мы оперировали секвенсами от 7 до 21 остатка на мишенях длиной от 102 до 188 остатков, полученные при докинге результаты ipTM в AlfaFold Server варьировались от 0.58 до 0.92.
По умолчанию идея рекомендательных алгоритмов не вызывает у меня никакого энтузиазма — в соцсетях я всегда переключаюсь с алгоритимического фида на хронологический (зря я что ли на всех, кого фолловлю, подписывался?), в киносервисах меня не интересует теле-кино-слоп под вывеской «вам может понравиться» (может понравиться, а может и не понравиться — как с вероятностью встретить динозавра на улице). С музыкой, однако, ситуация иная: с тех пор, когда я впервые прочитал в 2018 году про статистику, что люди, в среднем, после 33 лет перестают слушать новую музыку — мысль об этом прочно засела в моей голове (мне было как раз 30). Почему-то идея окостенения моих музыкальных вкусов мне совершенно не понравилась. И, если я пришёл в Яндекс Музыку в 2022 из-за санкций, то остался — из-за рекомендаций: если про своё избранное в Youtube Music я могу практически про каждый трек сказать, когда и как я его услышал и добавил (в чём, конечно, тоже есть свой кайф), то в Яндекс Музыке за 4 года соотношение в избранном треков, которые я услышал где-то и добавил сам, и треков, услышанных и сохранённых из рекомендаций Яндекс Музыки сейчас практически сравнялось. Т.е. половина моего избранного в Яндекс Музыке — это заслуга «старой» Моей волны, у которой в 2026 появился новый, более мощный рекомендательный алгоритм.
