Запускаем бенчмарки всего с одним C# файлом

Если вы когда-нибудь задумывались, можно ли запустить бенчмарк, используя всего один C#-файл, то ответ: да, можно.

Начиная с .NET 10, существует возможность создавать C#-приложения в одном *.cs‑файле. Проблема в том, что BenchmarkDotNet с настройками по умолчанию не поддерживает такие бенчмарки.

В этой статье я покажу, как обойти это ограничение, используя режим in-process.

Читать на Habr.
Читать на сайте.

3 критерия для определения нейрослопа

Я на днях наткнулся на ИИ-музыку в Яндекс Музыке. Мне норм, что существуют ИИ-музыка, видео или фото. Но как пользователь сервиса, мне бы хотелось знать что из контента сделано полностью ИИ (чтобы потом отфильтровать хехе).

К сожалению, в Яндекс Музыке нет маркировки ИИ-артистов. Может они ещё не выработали критерии? Или им просто выгодно продвигать такую музыку?

Так или иначе, эта ситуация натолкнула меня на размышления о вайбкодинге и я выделил свои 3 критерия, которые помогут определить является ли проект нейрослопом или нет:

1. Способны ли вы создать проект заново, но без ИИ?
2. Если ИИ завтра исчезнет, сможете ли вы поддерживать проект (реализовывать новые фичи, исправлять баги, доставлять обновления)?
3. Понимаете ли вы и можете объяснить ключевые решения, которые были приняты во время разработки проекта?

К примеру, если ответы такие:

1. Это будет медленее, но да.
2. Да, конечно.
3. Да, поскольку решения принимал я.

То можно сказать, что проект сделан человеком. В крайнем случае, в паре с ИИ в качестве ассистента.

Иначе – это нейрослоп.

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

Изоляция на уровне процесса в BenchmarkDotNet — отличный функционал для повышения точности измерений. Правда из-за этого, вывод значения, вычисленного прямо во время выполнения бенчмарка, — задача не тривиальная.

В этой статье разберём, почему это так и рассмотрим решение на базе IInProcessDiagnoser и генераторов кода.

Читать на сайте.

Я тут случайно узнал, что мой сайт alexeyfv.xyz не всегда нормально открывается в России.

У меня просьба, откройте сайт и:
— поставьте 👍, если всё ок;
— поставьте 🤡, если не ок.

И, если не сложно, в комментариях опишите, что именно открылось не так, или скиньте скрины.

Результаты ожидаемые, но, тем не менее, разочаровывающие. Надо что-то придумать. Видимо, нужно поднимать CDN в России.

Заботливое начальство в лице РКН — спонсор того, что я стал лучше разбираться в различных аббревиатурах. Настроил родным аббревиатуры. Себе тоже настроил аббревиатуры — ведь половина сайтов в России так же не открывается из-за рубежа.

Сейчас вот ещё разберусь с CDN.

Следите за выводом консоли при использовании AI-агентов

Я не видел, чтобы кто-то писал об этом, но мне кажется, что это важно, если AI-агенты вызывают CLI утилиты за вас.

Обычно CLI утилиты выводят информацию в консоль. Например, вы внесли изменения в проект с помощью агента, и теперь просите агента выполнить команды вроде npm build или dotnet test.

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

- Предупреждения об старых (deprecated) зависимостях или предупреждения линтера. Они могут напрямую вообще не влиять на текущую задачу, но всё равно занимают место в контексте. Представьте логи сборки с 500+ строками предупреждений, и каждая из них окажется в контексте вашего агента.

- ANSI escape-символы, которые задают цвета в консоли или Unicode-символы, делающие вывод консоли красивым. Всё это раздувает контекст без добавления какой-либо пользы. Агентам всё равно на цвет текста, прогресс-бары или результаты в виде ASCII-таблиц.

Почему это плохо для LLM?

Производительность LLM не равномерна при длинных контекстах. Есть такое явление под названием "lost-in-the-middle". Его суть в том, что производительность LLM ухудшается, когда релевантная информация размещена в середине контекста. Иногда такой эффект ещё называют "гниением контекста" (context rot). Есть несколько статей на эту тему, например "Lost in the Middle: How Language Models Use Long Contexts".

Для агентов это явление часто приводит к следующим проблемам:

- Агент тратит время на "размышления" о предупреждениях и что с ними делать, вместо решения задачи.

- Длинный вывод консоли может вытеснить важную информацию из контекста, или информация может быть суммирована (summarization) таким образом, что часть важных деталей потеряется.

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

Решение

Если вы видите предупреждения компилятора или линтера, в идеале вам нужно их исправить. Однако это может занять приличное количество времени, особенно если вы работаете с каким-то легаси проектом.

Другой вариант -- отключить их. Например, в dotnet можно использовать флаг --verbosity quiet В целом, я бы не рекомендовал это делать, но иногда можно, если нужно срочно выполнить задачу.

Если вы разрабатываете CLI утилиту, подумайте над созданием флага, который настраивает вывод специально для агентов. К примеру, разработчики Microsoft Dev Proxy недавно обсуждали добавление флага --log-for human|machine для более эффективного вывода для LLM.

Заключение

Если вы работаете с AI-агентами, то вывод в консоль перестаёт быть просто логами. Это уже часть промпта. Предупреждения, прогресс-бары и вывод результатов в виде таблиц, ANSI escape-символы занимают контекст LLM. Вывод CLI должен быть минимальным и структурированным, тогда результаты при работе с AI будут более надёжными.

Читать то же самое на сайте, но с картинками (нужен VPN).

P.S. Следующий пост будет не про ИИ, обещаю.

Коллеги, чем будем пользоваться в скором времени? Продолжаем использовать Telegram, но с использованием специальных технических средств связи?

Или на примете есть что-то ещё? Вообще, я довольно продолжительное время сижу на Reddit, но формат там, конечно, совершенно другой.

Только Макс не предлагайте 😬

Поднимаем свой MTProxy

Заботливое начальство вынуждает прокачивать технические скиллы. Разберёмся, как поднять MTProxy для Telegram на VPS. Нам понадобится:

1. VPS.

Покупайте самый дешёвый сервер. Сильное железо не требуется, главное чтобы не было ограничений по трафику. Характеристики моего сервера: 1 vCPU, 1 GB RAM, 15 GB SSD.

У меня сервер иностранный. На Хабре некоторые пишут, что сервер в России, возможно, будет лучше работать, так как трафик внутри страны не проверяется. Так это или нет – не знаю.

2. Docker Engine.

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

3. Домен.

Домен нужен для Fake TLS. Наш MTProxy будет прикидываться обычным HTTPS-трафиком.

Если у вас есть домен — отлично. Просто добавляете A-запись с IP-адресом вашего сервера.

Если домена нет, то можно зарегистрироваться на FreeDNS и взять домен третьего уровня на любом понравившемся бесплатном домене. Я в своё время пользовался такими доменами для удобства доступа к своим self-hosted приложениям.

Запускаем прокси

Есть несколько Docker-образов для запуска MTProxy. Я использую nineseconds/mtg:2, так как это самый простой способ запустить прокси с Fake TLS. Запускается всё следующим образом:

1. Генерируем секрет (начинается на ee) из вашего домена

docker run --rm \
    nineseconds/mtg:2 \
    generate-secret \ 
    --hex your.domain.com

Результат будет выглядить примерно так:

ee...

2. Кладём секрет в config.toml:

secret = "ee..."
bind-to = "0.0.0.0:443"

3. Создаём Docker Compose файл с содержимым ниже и запускаем прокси командой docker compose up -d

services:
  mtg-proxy:
    image: nineseconds/mtg:2
    container_name: mtg-proxy
    restart: unless-stopped
    ports:
      - "443:443/tcp"
    volumes:
      - ./config.toml:/config.toml:ro

Проверьте логи через docker compose logs. Если логов нет, значит всё хорошо.

Теперь можно сделать ссылку в формате:

tg://proxy?server=<your.domain.com>&port=443&secret=<secret>

И поделиться ею друзьями и родными.

Telegram добавит ваш прокси при нажатии на ссылку.

---

Я хотел сделать гайд максимально простым, поэтому не стал упоминать кое-какие аспекты администрирования серверов: защита SSH, отключение root, файрвол и так далее. Если интересно, могу сделать отдельный пост.