Современные языковые модели, такие как ChatGPT, Claude, Gemini, Grok и так далее, способны генерировать тексты, которые часто кажутся уверенными, логичными и достойными доверия. Однако за этим часто скрывается одна из главных проблем нейросетей — галлюцинации. Галлюцинации — это уверенные, но ложные утверждения, которые модель выдает как факты. Они могут проявляться в виде несуществующих цитат, выдуманных терминов, неверных интерпретаций, ошибочных чисел или ссылок на несуществующие источники. Например: при запросе о биографии известного ученого модель может уверенно сообщить о его работе в MTI и сослаться на несуществующую публикацию в Nature с точной датой и названием. Другой распространенный случай — цитирование выдуманных законодательных актов с номерами и датами принятия, которые выглядят достоверно, но фактически не существуют. Подробное и обоснованное описание создает иллюзию достоверности, делая галлюцинации особенно критичными при использовании ИИ в науке, образовании или, например, в медицине.

Привет!
Задумывались, какую версию квантованной LLM выбрать: Q4_K_M, Q6_K или Q8_0? Насколько Q6_K хуже справляется с задачами по сравнению с Q8_0? И что вообще означают все эти буквы в суффиксах?

Примечание: это адаптированный перевод моей статьи на Medium. Перевод был сделан при помощи мозга, а не нейросетей или Google Translate.

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

Всем привет!

В последнее время мои знакомые стали меня часто спрашивать, как вкатиться в разработку на Go, и каждому я отвечал +- одно и то же, скидывал +- одни и те же материалы, которыми пользовался когда-то сам. И чтобы постоянно не повторяться, я решил составить простой и понятный алгоритм действий: «Учишь это шаг за шагом и становишься Go-разработчиком».

Привет! Меня зовут Александр Плошкин, я руковожу группой развития качества персонализации в Яндексе. Сегодня мы открываем доступ к одному из крупнейших рекомендательных датасетов — Yambda. Он содержит 4,79 миллиардов обезличенных пользовательских действий, собранных за 10 месяцев использования сервиса Яндекс Музыка.

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

Рекомендательные алгоритмы помогают людям находить нужные товары, фильмы, музыку и многое другое — именно они лежат в основе сервисов: от интернет‑магазинов до онлайн‑кинотеатров. Развитие этих алгоритмов напрямую зависит от научных исследований, для которых нужны качественные и объёмные датасеты. При этом опенсорс‑датасеты чаще всего невелики по размеру или уже устарели, так как коммерческие компании, которые накапливают терабайты данных, редко их публикуют.

Публикация больших открытых датасетов наподобие Yambda помогает решить эту проблему. Доступ к качественным большим данным открывает новые возможности для научных исследований и привлекает к области внимание молодых учёных, заинтересованных в применении машинного обучения для решения актуальных задач.

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

Собеседования - всегда стресс. Я замечал, что после каждого интервью трудно вспомнить детали: какие вопросы задавали, как именно я отвечал, где были ошибки или неточности. А переслушивать запись, которая может длиться от часа и выше это долго и неэффективно.

Задумался: а что если использовать что-то, что автоматически превратит аудиозапись интервью в текст? Так я открыл для себя Whisper от OpenAI. Под катом подробности о его применении.

Привет, Хабр.

Мне всегда нравились красивые и удобные интерфейсы. Желая сделать лучше для пользователя, я потратил не один день. Так я начал коллекционировать HTML и CSS лайфхаки, которые улучшают впечатление пользователя от интерфейса. В итоге у меня получился внушительный список.

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

Давайте посмотрим, что я вам подготовил.

Генеративные нейросети уже изменили мир цифрового искусства, но настоящая магия начинается, когда ты сам берешь их под контроль. Сегодня расскажу о своем эксперименте по обучению LoRA на стиле South Park — от сбора датасета до финальной модели. Поделюсь реальным опытом, техническими нюансами и самое главное — что конкретно сработало, а что оказалось пустой тратой времени.

Меня зовут Илья, я основатель онлайн-нейросети для создания изображений ArtGeneration.me, техноблогер и нейро-евангелист.

Идея обучить LoRA на стиле мультсериала пришла ко мне случайно. На глаза попался новый анимационный сериал "Ваш дружелюбный сосед Человек-паук", и я подумал: "Было бы классно обучить LoRA именно на этом стиле!" Я уже обучал LoRA на отдельных персонажах и простых стилях, но на таких сложных и комплексных особо ещё не тренировал.

Но стиль человека-паука показался мне слишком сложным для первого эксперимента такого рода. Решил сначала потренироваться на чем-то попроще. И тут удачно подвернулась спешл-серия South Park! Стиль South Park простой, узнаваемый, многие его любят (включая меня). На Civitai уже была одна LoRA South Park, так что я подумал — если смог кто-то другой, то и я смогу!

Спойлер: всё оказалось гораздо сложнее, чем я думал. Но обо всём по порядку.

Летом 2020 года GitHub позволила пользователям создавать персональные README-файлы и с их помощью кастомизировать свои профили. Сама платформа при создании подобного файла предлагает уже готовый шаблон, в который можно вписать свои данные. Но о какой кастомизации может идти речь, если у всех будут одинаково оформленные профили? За почти два года сообщество придумало множество различных способов выделиться и особенно оформить свою страницу на GitHub.

Жизнь в ИТ не простая, работа, таски, дедлайны, мониторинг серверов, случайные падения кластера среди ночи... и где-то в этом хаосе есть ещё и личная жизнь. Проблема в том, что если в проде у тебя всегда есть система мониторинга, то в отношениях её нет. Или есть, то только в виде пассивно-агрессивного вопроса перед сном "Тебе не кажется, что ты мало времени уделяешь семье?".

Поэтому, сейчас мы разберёмся как можно сделать Kanban-доску в Taiga и попробуем сделать из хаоса порядок. Ведь мы можем поддерживать 99.99% аптайма в проде, почему бы не попытаться добиться хотя бы 80% в личной жизни?

Казалось бы, упаковать PHP в контейнер и настроить GitHub Actions - дело пяти минут. Но как часто бывает, реальность оказалась сложнее. Это история о том, как я вернулся к разработке на PHP и решал накопившиеся проблемы с деплоем Laravel-проекта. О том, как готовил Docker-образ, несколько раз переписывал процесс деплоя, находил компромиссы там, где это было возможно, и полностью перестраивал архитектуру там, где компромиссы были неприемлемы.

Вступление

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

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

Знакомая ситуация?

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

И чтобы решить эту проблему раз и навсегда и окончательно понять KAN, нам необходимо переосмыслив всё с нуля и постепенно двигаясь от базовых принципов линейной алгебры через нейронные сети, завершив, обобщая всё с помощью множеств. В процессе мы также рассмотрим некоторые довольно уникальные и новые идеи!

Всем привет! Давно планировали рассказать пару сценариев использования нашего веб-сервера с открытым кодом Angie. Сегодня речь пойдет о том, как Angie используется в инфраструктуре такого большого проекта, как RUTUBE.