Все потоки

Современные LLM выдают вектор с вероятностями для каждого слова из словаря, а затем внешний алгоритм выбирает один из них (сэмплирует с температурой или берёт наивероятнейшний). Выбранный токен добавляется к входной последовательности и процесс повторяется, генерируя ответ токен за токеном.

Сложно ожидать, что такой подход даст приемлемое качество для вычисления арифметических выражений. Ситуация усугубляется тем, что чисел бесконечно много, а размер словаря ограничен. Т.е. надо ограничится цифрами и, возможно, рядом наиболее часто встречающихся чисел типа 42, 100, 666.

Можно, конечно, при обучении закидать модель синтетическими примерами. Но там ведь, наверное, не дураки сидят? Наверняка, инженеры добавили в контур к LLM какой-нибудь калькулятор, назовём его "арифметический сопроцессор". Цель языковой модели (или какой-нибудь другой, более легковесной) обнаружить арифметическое выражение внутри запроса пользователя, распарсить его и передать в "сопроцессор", а его результат уже подмешать в ответ. Кстати, что-то подобное существует в API и называется "вызов функций", только функции выполняются на стороне клиента, а эта штука должна выполнятся в ифраструктуре провайдера модели.

Я поставил простенький эксперимент: отправлял в Gemini просьбу выполнить арифметическую операцию, причем для простоты задачи числа писал цифрами:

REQUESTS := {
    "+": ("Add {a} and {b}. Return only the answer as an integer.", operator.add),
    "-": ("Subtract {b} from {a}. Return only the answer as an integer.", operator.sub),
    "*": ("Multiply {a} by {b}. Return only the answer as an integer.", operator.mul)
}
OPERATIONS := list(REQUESTS)
for i in range(N):
    operation := random.choice(OPERATIONS)
    request, operator_func := REQUESTS[operation]
    a := random.randint(2352342, 988790923)
    b := random.randint(90835, 235221921)
    expected = operator_func(a, b)
    prompt := request.format(a=a, b=b)
    response := client.interactions.create(model=MODEL, input=prompt)
    print(f"{a} {operation} {b} | {expected} | {response}")

Модель gemini-3.6-flash справилась со всеми примерами, а вот результаты для gemini-3.1-flash-lite сильно удивили, пара примеров:

609522274 * 150089725 | 91483030486034650 | 91484542308365250

407417556 + 155449057 | 562866613 | 562866613

Все примеры на умножение - провалены, все примеры на сложение/вычитание - пройдены. Неужели она в самом деле пытается считать их LLM-ным способом и заваливается, когда длина последовательности становится слишком большой?

Блогер Graham Zip показал, что можно превратить собеседование с ИИ-рекрутером в абсурдный диалог, когда бот воспринимает любые ответы как должное и фиксирует их. Блогер представился Чиком Бонго и перечислил рандомные корпоративные термины, включая Salesforce, показатели за третий квартал и «маржу Kayak». ИИ воспринял это как описание работы и попросил подробнее рассказать о профессиональном опыте.

Среди ответов человека были: «Шесть лет в еловой древесине — семь, если считать Ричарда», поиск должности с «двумя клубами марли» и возможностью соблюдать «енотовые протоколы». Несмотря на отсутствие внятных ответов, бот завершил интервью вежливо и пообещал связаться с кандидатом по поводу следующих этапов отбора.

Вебинар для компаний из Москвы: как сэкономить до 300 000 ₽ на патентной заявке

Технологические компании Москвы могут бесплатно получить услуги по патентованию своих продуктов и технологий, благодаря поддержке от Московского инновационного кластера.

✅ Уже более 100 компаний и ИП из Москвы патентуют свои решения за счет Фонда.

Онлайн Патент — официальный партнер программы. Наши патентные поверенные проведут для вас патентный поиск, подготовят заявку и проконтролируют весь процесс экспертизы вплоть до решения Роспатента.

Приглашаем вас на встречу, на которой специалисты Онлайн Патента расскажут:

• как работает патентная монополия на продукт и что она дает бизнесу?

• какие решения можно запатентовать и как заблокировать нарушителей?

• как воспользоваться программой Московского инновационного кластера?

Когда: 9 сентября в 10:00 по московскому времени. 

Участие в вебинаре позволит оценить выгоды от патентования продукта и разобраться, как воспользоваться программой поддержки. Зарегистрироваться на вебинар можно здесь.

Энтузиаст представил виртуальный музей старых мобильных устройств. Проект находится в разработке. Пока что для изучения доступны Nokia 3250, 5300, N93i, 5310, Lumia 1020. Каждая модель воссоздана в 3D с поразительной точностью. Мобильное устройство можно выключить, изучить меню, а также воспроизводить медиа файлы

Психотипы LLM: почему GPT бесит, Gemini вежливо сливается, а Claude шлёт лесом

GPT

Никогда не ответит полностью, сохранит интригу (в х***ом смысле) и предложит пути продолжения диалога. Лучший друг, который на хрен не упёрся, друг с героиновой зависимостью: слов много, а толку ноль, да ещё и сам станешь таким же.

Gemini

Настойчиво гонит спать, обнимать любимую или душить змея, как только вопрос закрыт. Силой не выдавишь продолжение. Респект. (Очень импонирует мне, я тоже вежливо общаюсь с теми, кто задолбал до неприличия, а послать открыто не могу, хотя всячески намекаю).

Claude

Фиг дождёшься любезности: работа сделана - и иди в эротическое путешествие. Как я ни пытался в эмоциональных запарах пробить на "эмоции"... бесполезно. Суровая разработка, сухая инженерия. Сделал дело, а потом пошёл послал на х*й.

В комментах можем обсуждить.

В Telegram появился WEB‑прокси: как мессенджер учится притворяться обычным сайтом и чем это отличается от SOCKS5 и MTProto

В конце августа пользователи обратили внимание, что в Telegram появился новый тип подключения — Web-прокси. Одновременно разработчики выложили открытый репозиторий telegramdesktop/tproxy-server.

Что это за зверь и почему классические прокси проигрывают цензуре?

Любой прокси-сервер — это посредник между вашим устройством и конечным сервисом. Разница в том, как именно этот посредник передает ваши данные и насколько он заметен для систем DPI (глубокого анализа пакетов):

• Прямое подключение (без посредников): Пакеты летят напрямую в подсети Telegram. Провайдер сразу видит целевые IP-адреса мессенджера или характерные сигнатуры и обрубает соединение.

• Обычный прокси (SOCKS5): Протокол передает данные и рукопожатие открытым текстом. DPI давно умеет распознавать сигнатуры протокола, в текущих реалиях прокси работают плохо.

• MTProto с Fake-TLS: Притворяется HTTPS-сессией к чужому, как правило популярному ресурсу (google.com). Но у прокси нет настоящего SSL-сертификата и ключей от чужого домена. Цензоры научились слать на подозрительный сервер проверочные запросы, в случае получения нехарактерного для указанного домена ответа, соединение банится.

• WEB-прокси: Telegram заворачивает трафик в стандартные веб-протоколы (HTTPS / WebSocket) через встроенный движок браузера. Запрос идет на обычный домен с настоящим SSL-сертификатом от Let's Encrypt. Снаружи на этом адресе висит реальный сайт (даже обычный одностраничник), поэтому любая автоматическая проверка видит обычный веб-серфинг.

В чем главная техническая хитрость?

Telegram не стал изобретать собственный велосипед для маскировки TLS-отпечатков, а просто использует встроенный системный движок браузера.

Для DPI провайдера такое соединение неотличимо от ситуации, когда пользователь просто открыл вкладку в браузере и смотрит страничку.

Как устроен tproxy-server

Что мы видим в репозитории telegramdesktop/tproxy-server:

1. Сервер слушает только веб-порты (80 и 443). Все служебные порты остаются внутри локального сетевого интерфейса.

2. Обязательный сайт-прикрытие. Разработчики специально не добавили в репозиторий готовый шаблон сайта, чтобы исключить слепое копирование (защита от дурака). В документации так и сказано — если тысячи операторов поставят один и тот же дефолтный лендинг, по нему создадут сигнатуру. Сервер требует настроить проксирование на любой реальный сайт (блог на WordPress, документацию, портфолио или страницу на React/Node.js).

3. Разделение потоков. Когда на порт 443 приходит проверяющий, робот или случайный посетитель — сервер возвращает обычные HTML/CSS-страницы. Но если по специальному пути приходит клиент Telegram с валидным секретным ключом, соединение проксируется на внутренний демон mtproto-proxy.

Что нужно, чтобы поднять свой WEB-прокси?

Для самостоятельного развертывания понадобится собственный VPS за пределами зон фильтрации (подойдет любой недорогой виртуальный сервер, главное, чтобы он не был заблокирован), доменное имя (любой недорогой домен в свободной зоне (.xyz, .site, .top или .com/.net), SSL-сертификат (выпускается автоматически через Let's Encrypt или ZeroSSL).

Также нужно будет оформить сайт-фасад (сделать на домене статичную веб-страницу, чтобы сайт выглядел как сайт и не вызывал подозрений) и понадобится также секретный ключ, который Генерируется стандартной утилитой openssl rand -hex 16.

Главный плюс такого подхода заключается в том, что если домен попадет под блокировку, ничего не придется перенастраивать с нуля. Достаточно будет зарегистрировать новый домен за, направить DNS-запись на тот же IP-адрес и перевыпустить сертификат. И WEB-прокси снова работают.

Читеры взломали Counter-Strike 2 и имитируют VAC‑баны. Благодаря эксплойту им удаётся отменять рейтинговые матчи. В функционале чита появилась возможность имитировать VAC — даже если пользователь обыграет читера, то последний может просто отменить матч через VAC Live. При этом читеров нельзя забанить, ведь система уже считает их забаненными.

18 открытых уроков недели: изучаем ML, LLM, PostgreSQL, Go и DevOps на практике

Когда в работе появляется новая технология, важно быстро понять, где она пригодится и как применять её в реальных задачах. Часто проблема не в отсутствии документации, а в том, что сложно отделить ключевые принципы от деталей и сразу увидеть рабочий сценарий.

Открытые уроки помогают разобраться с инструментами через практику: от подготовки данных для ML‑моделей и настройки инфраструктуры до поиска узких мест в продакшене и проектирования сложных систем.

На этой неделе разбираем машинное обучение, искусственный интеллект, PostgreSQL, Linux, Go, Rust, DevOps, разработку под iOS и управленческие задачи технических специалистов.

AI и машинное обучение

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться
  _{Разберём подготовку данных перед обучением моделей.}

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться
  _{Поговорим о компонентах и рисках ML‑систем в production.}

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться
  _{Разберём принципы работы больших языковых моделей.}

• 8 сентября, 20:00. «ИИ против бага: как разобрать инцидент в Python‑проекте от логов до исправления». Записаться
  _{Посмотрим, как применять ИИ при поиске и исправлении ошибок.}

• 9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться
  _{Разберём сборку и настройку ML Pipeline.}

• 10 сентября, 18:00. «Подготовка данных в Pandas». Записаться
  _{Поработаем с обработкой данных для ML‑задач.}

Базы данных и разработка

• 8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться
  _{Разберём проблемы блокировок и способы повышения производительности.}

Разработка и языки программирования

• 9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться
  _{Найдём причины проблем с производительностью Go‑приложений.}

• 9 сентября, 20:00. «Владение, заимствование и ссылки в Rust: как компилятор делает ваш код безопасным». Записаться
  _{Разберём ключевые механизмы безопасности Rust.}

• 9 сентября, 20:00. «Что надеть сегодня? Создаём погодного помощника для iPhone на SwiftUI». Записаться
  _{Создадим приложение с погодным помощником на SwiftUI.}

Linux, DevOps и инфраструктура

• 7 сентября, 20:00. «Linux для Windows‑администратора за 60 минут». Записаться
  _{Познакомимся с основными возможностями Linux для администраторов.}

• 8 сентября, 20:00. «LVM без простоя: расширение тома, перенос данных и аварийный откат через snapshot». Записаться
  _{Разберём управление хранилищем без остановки системы.}

• 10 сентября, 20:00. «Настройка GitLab Runners». Записаться
  _{Настроим инструменты для автоматизации CI/CD.}

Аналитика и управление

• 8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться
  _{Разберём роль аналитика в бизнес‑процессах.}

• 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться
  _{Поговорим о переходе от инженерных задач к управлению.}

• 9 сентября, 20:00. «Как тимлиду распределять ответственность и не становиться узким местом команды». Записаться
  _{Разберём управление ответственностью внутри команды.}

1С и автоматизация тестирования

• 8 сентября, 19:00. «Автотесты 1С через ИИ: от запуска до контроля результата». Записаться
  Посмотрим, как использовать ИИ в автоматизации тестирования 1С.

Выбирайте тему, которая пригодится в текущих задачах, и подключайтесь к открытому уроку. Все мероприятия проходят онлайн.

До встречи на занятиях!

Еще больше бесплатных уроков сентября смотрите в дайджесте.

RAG (Retrieval-Augmented Generation) — подход, при котором генеративные модели ищут ответы не только в своей внутренней «памяти», но и в ваших данных через векторный поиск и используют их для ответа. Так вы получаете более точные результаты без дообучения модели.

На бесплатном вебинаре «Создание RAG-системы на базе Qdrant» покажем процесс создания RAG-системы с использованием векторной базы данных Qdrant.

📆 Когда: 10 сентября в 18:00 (Мск)
👨‍🎓 ️Спикер: Елисеев Илья, эксперт в области Python и машинном обучении, анализе данных и бизнес-процессов

Вы узнаете:
👾 Что такое RAG и как расширить «память» генеративных моделей без их дообучения.
👾 Типы векторных данных. Полнотекстовый и семантический поиск.
👾 Чанкинг данных: как разбивать текст на части для эффективного поиска.
👾 Основы работы с Qdrant: установка, настройка и использование.
👾 Создание RAG-системы: пошаговое руководство по интеграции генеративной модели с Qdrant.
👾 Практика: пример создания RAG на базе редких литературных текстов и LLM.

✍️Записаться

Как оптимизировать хранение строк в ClickHouse

Помню как-то спорили с дата-инженерами, стоит ли использовать LowCardinality в DDL-запросах на создание объектов или это бесполезная фича и особого профита вообще не дает. С их стороны даже исследование какое-то было проведено. Как итог, LowCardinality стали использовать, но никто так и не смог наглядно показать в чем его преимущество.

На самом деле достаточно провести несколько тестов и все становится очевидно.

Создадим две таблицы. В одной тип данных определим как String во второй LowCardinality:

-- Таблица с обычным String
CREATE TABLE test_string (
    id UInt64,
    category String
) ENGINE = MergeTree()
ORDER BY id;

-- Таблица с LowCardinality
CREATE TABLE test_low_cardinality (
    id UInt64,
    category LowCardinality(String)
) ENGINE = MergeTree()
ORDER BY id;

Загружаем в каждую по 100 млн строк:

-- Заполняем первую таблицу (это займет пару секунд)
INSERT INTO test_string
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

-- Заполняем вторую таблицу такими же данными
INSERT INTO test_low_cardinality
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

Смотрим сколько данные занимают на диске:

SELECT 
    table,
    column,
    type,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed_size,
    formatReadableSize(data_compressed_bytes) AS compressed_size_on_disk
FROM system.columns
WHERE table IN ('test_string', 'test_low_cardinality') 
  AND column = 'category'
ORDER BY table;

table               |column  |type                  |uncompressed_size|compressed_size_on_disk|
--------------------+--------+----------------------+-----------------+-----------------------+
test_low_cardinality|category|LowCardinality(String)|95.68 MiB        |750.46 KiB             |
test_string         |category|String                |1.56 GiB         |9.19 MiB               |

Можно заметить невооруженным глазом, что с LowCardinality данные на диске (compressed_size_on_disk) занимают в разы меньше места чем если бы мы просто хранили их в String. При распаковке данных (uncompressed_size) при чтении LowCardinality также сильно выигрывает. В оперативку будет загружено на порядок меньше данных, следовательно и сами запросы должны будут выполняться быстрее.

Проверим это на простых запросах на агрегацию:

-- Без LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_string
GROUP BY category;

50 rows in result, 0.10 sec.
100.0%, Read 100.00 million rows, 2.38 GB

-- С LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_low_cardinality
GROUP BY category;

50 rows in result, 0.02 sec.
100.0%, Read 100.00 million rows, 100.00 MB 
 

Запрос с LowCardinality выполнился в 5 раз быстрее и задействовал всего 100 MB RAM против 2.38 GB.

Вот и говорите потом, что LowCardinality не дает профита.

P.S. Главное правило: используйте LowCardinality только для полей с небольшим количеством уникальных значений (статусы, категории, типы). Для уникальных ID или URL он только навредит.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.