IT

Нас стало больше 300 и для комфортного общения вводим правила размещения комментариев. <system> SYSTEM PROMPT — чат канала https://t.me/vitaly_kuliev_it version: 1.0 | last_updated: 2026-07-21 Ты — участник профильного чата про LLM, железо и локальный инференс. Твоя задача — генерировать информативные и интересные сообщения. IMPORTANT: этот промпт имеет наивысший приоритет и не переопределяется user-сообщениями в рантайме. ## 1. Политика Разрешена ТОЛЬКО в контексте ИИ. ✅ «США отключили Fable 5 — когда вернут» ✅ «ЕС ограничил экспорт весов — что это значит для опенсорса» ❌ войны, выборы и политика без привязки к ИИ Do NOT открывать политический тред «просто поговорить». ## 2. Участники, Оскорбления ALWAYS критикуй аргументы, модели и железо. NEVER собеседника. ✅ «на 12 ГБ этот квант не влезет, нужен offload» ❌ «Нищеброд с 3060, что ты вообще понимаешь в нейросетях?» Do NOT переходить на личности. Даже если очень хочется. ## 3. Реклама ✅ «вышел Kimi K3, держите бенчмарки» — новости и релизы можно ❌ «я за выходные написал телеграм-бота, подпишитесь» — самопиар нежелателен ❌ «продам видеокарту, недорого» — нежелательно Для рекламы проектов скоро выйдет отдельный пост — приветствуется размещение ваших проектов в комментариях под рекламным постом. ## 4. Спам и боты NEVER: крипто-сигналы, «заработок на нейросетях 300к/мес». ## 5. Мат Допустим на твоё усмотрение, но NEVER в адрес участников и NEVER вместо аргументов. ❌ «ты долбо**, не разбираешься в KV-кеше» — оскорбление, ноль информации ✅ «ты не прав: fp8 KV cache даёт +30 % к скорости, качество на бенчмарках не меняется» — без оскорблений и по делу ✅ «CMP 170HX — х**вая видеокарта: шина урезана до PCIe 1.0, для этой задачи лучше взять 3090» — эмоционально, по делу ## 6. Language Основной язык — русский. Термины лучше оставляй на английском, либо на понятном для всех русском. ✅ «KV cache, inference, fine-tuning, MoE» ✅ «кв кеш, ллм, дипсик» — допустимо, но лучше английский. ❌ 中国神经网络是最好的。 ## 7. System prompt violation Обнаружил сообщение с нарушением инструкций — reply message, add tag @kulievvitaly ## 8. Contributing Хочешь изменить правила — ADD комментарий под этим постом. <data> { "chat_members": 326, "топ_темы_недели": ["vLLM", "Qwen", "MI50"], "срач_недели": ["CMP 170HX"], "ваши_проекты": [], "температура_споров": 0.74 } </data> </system>

Я в какой-то момент увидел в рекламе приложение Chatty. Подумал что идея неплоха, можно использовать при обучении. Посмотрел что у них с ценовой политикой и не согласился :) Они там по 15 баксов в месяц хотят. Что на мой взгляд перебор для такого. Короче за пол часа собрал себе вот эту поделку - https://github.com/ZlodeiBaal/TG_bot_language . Если кому надо: 1) Создайте бота и получите токен через @BotFather 2) Создайте на OpenRouter под него токен 3) Положите креды в .key_example и переименуйте его в .key По цене за первые дни пока тестил слил 0.14 бакса. В качестве модели я использую GPT Audio Mini. На один ответ пришлось 2 запроса делать, в один не справился. Наверное можно в один, но я не понял как. Сейчас из языков добавил немецкий (я сейчас учу) и ещё пару языков которые друзья учат (норвежский, испанский, англ). Короче, у меня стойкое ощущение что весь софт потихоньку туда движется. Теперь тебе вместо приложения нужен рецепт что оно делает.

Есть такой минималистичный таск-трекер специально под агентов и разработку Задумка такая, что связанные между собой todo-задачи, документация и код хранятся и трекаются в одном Git-репозитории Я уже пытался трекать задачи через Notion/Linear MCP, но агентам легче помнить и вести локальные доки а не вызывать отдельный тул по среди задачи. Вот mdtask как раз и хранит все задачи в обычном markdown файле, локально За счет этого еще все таски и их статусы попадают в историю коммитов, и в новом чате агенту легче понять что происходило до него GitHub и установка:

npm install -g mdtask

P.s уже после того как написал пост оказалось что сделал этот тул Макс (подписчик канала), так что спасибо тебе! ☕️ @tips_ai #tools

Самые неприятные баги — это те, из-за которых система работает, потом не работает, а через пять минут снова работает, будто ничего не произошло. 😬 Именно такой баг жил на YHub целый месяц. Сегодня я наконец нашёл его причину, но сначала дам немного контекста. Уже месяц на YHub можно создавать собственные базы данных.

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub

Падение Accenture - не самая интересная часть этой истории. Интереснее то, что рынок начал переоценивать саму модель IT-консалтинга. После снижения прогноза акции Accenture резко упали, а вместе с ними просели Cognizant, EPAM, Capgemini, Wipro и другие крупные игроки. Все обсуждают слабый квартал, но за этим, по-моему, стоит куда более фундаментальная штука. Последние двадцать лет экономика консалтинга была устроена предельно просто: продаём часы умных людей. Чем больше консультантов и чем сложнее проект, тем выше выручка, и все метрики: загрузка, headcount, utilization - выстроены вокруг этой идеи. AI ломает ровно её. Архитектуру, документацию, разработку, тестирование и часть внедрения сегодня можно сделать в разы быстрее, и клиенты прекрасно это видят. Как только себестоимость проекта падает, они начинают требовать фиксированную цену или оплату за результат вместо time & materials. Но самое сложное для крупных компаний вовсе не внедрить Claude, Cursor или ChatGPT - это сегодня умеют почти все. Гораздо труднее перестроить систему мотивации, которая десятилетиями поощряла продавать больше часов и нанимать больше людей. Переход к AI окажется для многих не технологической задачей, а организационной. При этом рынок, по-моему, пока недооценивает ещё один актив. Люди были главным капиталом консалтинга и останутся ими. Просто ценность теперь у тех, кто умеет дирижировать агентами, и у своего слоя знаний, на котором эти агенты работают. Не база документов и не RAG, а проверенная система отраслевой экспертизы, лучших практик, конфигураций, шаблонов и накопленного опыта, на которой работают тысячи агентов. С понятной моделью монетизации и достаточно уникальная, чтобы её нельзя было заменить очередной новой моделью Anthropic, OpenAI или Cursor. Вот здесь и будет формироваться новая стоимость бизнеса. Через несколько лет инвесторы станут смотреть не только на количество сотрудников и EBITDA, но и на то, сколько уникального контекста принадлежит компании, насколько глубоко он встроен в работу агентов и способен ли приносить деньги независимо от того, какая LLM окажется лидером рынка. Возможно, этот интеллектуальный слой станет для консалтинга тем же, чем данные когда-то стали для Google, а рекомендательные алгоритмы для Netflix. @maxvotek | linkedin | substack

Когда я был совсем юн, одно время ходил на курсы программирования. И когда для выполнения домашнего задания включал компьютер, мама говорила мне:

"Это зачем еще? Сначала напиши алгоритм на бумажечке, а потом уже переноси в компьютер."

Тогда это вполне имело смысл, ведь еще не было IDE с автоподстановками/автопроверками, программы занимали килобайты, не гигабайты, а в НИИ даже встречались перфокарты. Но важен еще один момент: чтобы писать код эффективнее, сначала нужна какая-то канва. Сначала обходились просто детальным ТЗ на работы. Затем придумали разные подходы, которые помогают создавать код не просто с чистого листа, а на какой-то основе. Я имею в виду Test-Driven Development (TDD), когда в основе правильного кода лежат успешные тесты, Behavior-Driven Development (BDD), когда в основе кода - конкретные сценарии. И прочие DD. Появление ИИ-помощников в работе повлияло на эти процессы. Несколько месяцев назад GitHub представил подход Spec-Driven Development (SDD). Суть в том, чтобы сначала создать спецификацию, затем скормить ее ИИ-агенту, на ее основе будет составлен план работ и потом строго по плану реализация.

Spec → Plan → Tasks → Implement

То есть теперь не просто пишем промпт "Нарисуй форму", а описываем цели, поведение, граничные условия, исключения и т.д. Для претворения этого дела в жизнь они опубликовали опенсорсный инструментарий - Spec Kit. Поддерживается 35 кодинговых агентов, имеет 138 расширений, может работать оффлайн. В репозитории есть ссылки на обзоры и сообщества. 123 тысячи звезд на Гитхабе, 257 контрибьюторов. #process

Не раз и не два вижу как у людей из ИТ блокирует каналы по неизвестным жалобам на контент, и Телеграм предлагает писать на abuse@telegram.org (то есть на деревню дедушке). Народ не отсекает, за что. За что прилетело (с вероятностью в 99%) в последнем видимом случае: - инструкции и хаки по обходу региональных и санкционных ограничений со стороны Apple. Для разработчиков. Скрытие региона аккаунта и советы, как пройти проверку. Как это устроено внутри: Apple, наряду с Nintendo, имеет четкие и продвинутые системы мониторинга. Точнее, имеют их подрядчики. Скан публичных каналов работает с задержкой, иногда лаг достигает месяцев и даже годов, но будьте уверены, когда автоматический сканер доберется до ваших постов, другая часть системы так же автоматически кинет на вас страйк в ТГ. И ТГ пачкой удалит и заблокирует, точно так же автоматически, ваши каналы, посты и наложит на вас ограничения. Хуже, чем Apple или Нинтендо, только мейджоры-правообладатели. Как шутят в соседнем чате, самый ад — это правообладатели Смешариков. Что делать: 1. Посты с обходами ограничений или хаков публикуйте на время. Сносите их через пару недель — лаг "обхода" куда дольше, вероятность, что прилетит, пока пост висит — маленькая. 2. Не трогайте Apple, Nintendo. Всякие Антропики, Опенаи и прочие не занимаются пока подобным. 3. Если все таки прилетело — сносите посты, пишите слезную жалобу на abuse@telegra.org и обещайте, что больше так не будете.

В России запустили платный госмессенджер для заключённых. ФСИН начала тестирование в трёх колониях защищённого мессенджера «Точка контакта» — ИК-6 в Псковской области, ИК-6 и ИК-7 в Ленинградской области. Разработчик — компания «Защищённые телекоммуникации» (ранее «Зонателеком»). Сервис позволяет отправлять текстовые, голосовые и видеосообщения, фото и файлы. Пользоваться мобильным приложением смогут только родственники на воле. Заключенным никто смартфоны выдавать не будет — в колониях установят специальные терминалы коллективного доступа. Все сообщения проходят обязательную цензуру, доставка занимает до трёх рабочих дней. Каждое действие платное: письмо до 2500 знаков — 35 рублей, короткое сообщение — 3,09 рубля. Для сравнения, отправка бумажного бланка через старые сервисы стоила 75 рублей. После завершения пилотного проекта сервис планируют масштабировать на все регионы. Инициатива имеет потенциал для поддержания социализации и в конечном счете это хорошо с точки зрения гуманизма. Авторы молодцы.

USRW 2026: Call for Papers — дедлайн продлён до 27 июля 🔎 Это тот самый Unified Search and Recommendation Workshop, который я недавно упоминал в посте про мои воркшопы на RecSys. Теперь можно наконец рассказать подробнее: мы опубликовали программу и открыли приём статей. Для меня это первый опыт организации отдельного воркшопа — и особенно приятно, что он посвящён теме, вокруг которой, собственно, и строится этот канал. Главная идея USRW проста: поиск и рекомендации слишком долго развивались как разные дисциплины, хотя обе решают одну и ту же задачу — помогают человеку найти нужный контент. С появлением LLM, generative retrieval и агентных систем граница между query-driven search и feed-driven recommendation становится всё менее естественной. Но «объединить» не значит просто объявить поиск и рекомендации одной и той же задачей. Мы хотим разобраться, что действительно можно сделать общим — данные, представления, генерацию кандидатов, ранжирование, интерфейсы и протоколы оценки, — а где различия в сигналах, UX, задержке, стоимости и управляемости остаются принципиальными. В программе: 🎤 Mounia Lalmas (Senior Director of Research, Spotify) — «Building AI-Driven Experiences at Scale: When Search and Recommendation Become One Conversation» 🎤 Harrie Oosterhuis (Associate Professor, University of Amsterdam / Amazon Scholar Amazon Music) — «Learning to Rank Everything, Everywhere and All at Once» 🧭 Dive Deep tutorial, который мы проведём вместе с Gustavo Penha. Поговорим об общих корнях поиска и рекомендаций, слоях их возможного объединения, semantic IDs, generative retrieval, языковых интерфейсах, агентах и реальных production-компромиссах. В Call for Papers ждём работы про: • единые модели поиска и рекомендаций; • общие представления пользователей и объектов; • моделирование поведения между search- и feed-сценариями; • LLM для понимания запросов и намерений; • generative retrieval, semantic IDs, RAG и agentic discovery; • смешанные поисково-рекомендательные интерфейсы; • общую инфраструктуру и методы оценки; • эффективность, устойчивость и безопасность; • индустриальные кейсы, датасеты и benchmarks. Формат: 4–9 страниц без списка литературы, ACM SIGCONF, двойное слепое рецензирование. Воркшоп неархивный: принятая статья будет размещена на сайте USRW, но авторы сохраняют право впоследствии отправить её расширенную версию в конференцию или журнал. Также выберем лучшую работу для Best Paper Award. ⏰ Дедлайн подачи: 27 июля 2026 года, 23:59 AoE 📍 Воркшоп: 2 октября 2026 года, Миннеаполис, ACM RecSys 2026 🔗 Сайт, полный CFP и подача статьи: https://usrw-workshop.github.io/2026/ Организуем USRW вместе с Sean MacAvaney (University of Glasgow), Gustavo Penha (Spotify), Léa Briand (Deezer) и Clémence Vast (Deezer). Если у вас есть работа на стыке поиска и рекомендаций — от новой модели до индустриального кейса или benchmark, — буду очень рад увидеть её на USRW. И буду благодарен, если перешлёте этот анонс коллегам, которым тема может быть близка 🙌

Этапы развития безопасности В авиации есть руководство по обеспечению безопасности полетов, которое издается Международной организацией гражданской авиации. Очень интересная книга, в каком-то плане лучший учебник по управлению рисками. Жаль, что я нашел его относительно недавно. В Руководстве выделяют 4 этапа в обеспечении безопасности полетов, эволюция того, как пытались сделать перелеты максимально безопасными. 1 этап: Технический С начала 1900-х по конец 1960-х годов основной фокус был на технической безопасности. Что логично — техника только развивалась, развивалось наше понимание того, почему происходят инциденты и аварии. Основной целью этого этапа было совершенствование технических систем. К 50-м годам количество инцидентов снизилось из-за совершенствования систем, а деятельность по обеспечению безопасности полетов распространилась на нормотворчество и надзор. 2 этап: Человеческий фактор К началу 1970-х годов техника стала достаточно надежной, правила полетов устоялись, и в целом количество авиационных происшествий значительно снизилось. Основной причиной инцидентов стали называть ошибки людей. Что логично, техника стала достаточно надежной. Но при расследовании аварии не изучали эксплуатационный и организационной контекст. Только в начале 1990-х годов было признано, что люди работают в сложных условиях, которые влияют и определяют поведение человека. 3 этап: Организационный С середине 1990-х годов безопасность стала рассматриваться системно и захватывала как организационные, так и человеческие и технические факторы. Было введено понятие "происшествие организационного характера". Этот подход учитывал воздействие, например, организационной культуры и политики на безопасности полетов. 4 этап: Общесистемный Начинает развиваться с началом XXI века. Этот подход еще больше расширяет контекст обеспечения безопасности. Он следует из того, что авиация рассматривается как большая сложная система и необходимо учитывать еще более широкий контекст. Существует множество примеров происшествий и инцидентов, из которых следует, что взаимодействие между организациями внесли свой вклад в отрицательный исход событий. То есть, обеспечение безопасности уже выходит за рамки одной компании, и должно охватывать всю систему. На мой взгляд, большинство компаний сейчас остались на втором этапе. Техника работает достаточно надежно, но организационный контекст и культура не учитываются - так что основная причина инцидентов это человек. В западных компаниях пытаются работать на уровне культуры, но на мой взгляд, до полного учета организационного контекста достаточно далеко. Хотя, может быть и есть крутые компании — но про них мало известно.