Вредные советы о лидерстве, которые превращают сильную команду в хаос — и о том, что на самом деле помогает лидам развивать людей, доверие и устойчивые процессы.
С иронией о типичных ловушках: от микроменеджмента и героизма до игнорирования обратной связи.
Rust все популярней, а вместе c этим создается много библиотек для Python на Rust.
В данной статье узнаем, как создать простенькую библиотеку для Python на Rust на примере кодирования данных в Base 64.
Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее.
Что мы сделали:
• Стали брать реальные данные с прода, которые выбиваются за стандартные представления.
• Обезличивать их.
• Использовать ML-модель для генерации сценариев, где эти данные увязываются с остальными в системе. Это типа генерации новых данных с усилением трендов и их пересечением.
То есть фактически по модели швейцарского сыра — мы имеем один статичный срез, а затем начинаем ходить в прод и искать новые дырки. Потом соединяем несколько дырок в новом слое и накладываем слои друг на друга, чтобы посмотреть, не будет ли сквозного отверстия.
Цель — не просто нагрузить систему, а протестировать жизнеспособность архитектуры в похожих на реальные условиях.
Очень упрощая, наши наборы тестов учатся нестандартным ситуациям с прода и включают их и в тестовые выборки данных, и в юнит-тесты, и такие ситуации не только покрываются как частные случаи, но и включаются в сложные сценарии, где 3 малозначимых отказа могут привести к аварии.
Я думаю, что это будущее тестирования сложных систем, и мы с командой уже затащили это в автоматический пайплайн.
Мы, стоматологи, знаем в этом толк. Нас боятся больше всего.
Поскольку мы строим стоматологию, руководствуясь прикладной наукой (и сами её часто двигаем), то когда открывали первое детское отделение, разобрались с тем, как сделать так, чтобы ребёнка не пугать.
Оказалось, почти нет проверенных исследований, как не пугать. Зато очень хорошо исследован вопрос, что может напугать. То есть можно рассчитать идеально пугающий путь, но все безопасные и спокойные подходы придётся исследовать самим.
Сейчас расскажу про то, что мы нашли, а потом про то, что наука говорит про то, как вырастить ребёнка, который будет бояться стоматологов и заодно всех других врачей.
Это просто!
— можно было бы сказать, про всё, что будет дальше, так как зачастую в науке и технике возникает потребность узнать состав объекта, не нанося ему повреждений.
И, для этого, есть интересные способы!
Однажды в Петербурге середины XIX века один нищий студент решил быстро поправить своё финансовое положение. Он взял топор и пошёл к старухе-процентщице.
Если бы этот случай был описан в учебнике классической экономики, то мы бы узнали, что наш студент провёл анализ рисков, оценил ликвидность и возможную прибыль.
Короче говоря, действовал бы рационально.
Но Достоевский предложил куда более интересный сюжет: Раскольников действовал не столько как экономический субъект, сколько как герой собственной трагедии, заражённый идеями Ницше и социал-дарвинизма.
Или другой пример — путь Дейнерис Таргариен к Железному трону. Экономика объяснила бы это как типичную стратегию по захвату ресурсов, но мы-то знаем, что двигал Матерью драконов сложный нарратив о восстановлении утраченного права и предназначении.
В общем, экономисты наконец осознали то, что давно знали психологи: люди существа эмоциональные, а не рациональные. И именно это легло в основу концепции нарративной экономики, которая, как оказалось, способна прогнозировать поведение рынков.
Но как?
Почему одни проекты мы бросаем, а другие — тащим годами?
В этой статье я разобрал, как мои прошлые проекты — от пиксельной игры до логического симулятора — помогли мне НИКОГДА не выгорать. Делюсь принципами, спасающие мои идеи от забвения.
Привет, Хабр! Меня зовут Станислав Якуш, я директор по развитию информационных технологий в «Группе Лента» (Lenta tech). Меня часто спрашивают: зачем крупному ритейлеру лезть на конкурентный IT‑рынок? Ведь своя‑то обойма задач всегда есть. Ответ прост: сегодня ИТ — это уже не просто затратный центр, а потенциальный драйвер роста и источник прибыли. В Lenta tech мы решились на этот поворот и сейчас активно его проживаем — без глянца, зато с реальными кейсами, ошибками и первыми результатами.
Привет! Меня зовут Владислав Миронов. Я отвечаю за внедрение LLM в процессы QA Яндекса и в этой статье расскажу, каких результатов мы достигли — от генерации тест‑кейсов и автотестов до помощи в ручном тестировании. Поделюсь не только успехами, но и тем, какие компромиссы и организационные решения понадобились, чтобы всё это заработало.
В статье покажу, как мы разрешаем противоречия между командами, уходим от «зоопарка» инструментов и строим централизованную экосистему, где качество остаётся под контролем: реальные схемы, примеры и цифры, без магии и маркетинга.
Спойлер: рассчитывать можно на многое, но и вложиться придётся основательно. Парой промптов тут, к сожалению, не обойтись.
LLM Judge для валидации образовательного контента: архитектура кросс‑модельной оценки с бюджетом $0.014 за курс
Как мы решили проблему «стохастической дивергенции» при генерации уроков и снизили затраты на валидацию в 17,000 раз по сравнению с ручной проверкой.
Является ли число 170 141 183 460 469 231 731 687 303 715 884 105 727 простым? Прежде чем искать ответ в Интернете, подумайте, как вы могли бы ответить на этот вопрос без компьютера или даже цифрового калькулятора?
В 1800-х годах французский математик Эдуард Лукас потратил годы на то, чтобы доказать, что это 39-значное число действительно простое. Как он это сделал? Лукас, который, кстати, также придумал увлекательную игру «Ханойская башня», разработал метод, который по-прежнему полезен и сегодня, более чем столетие спустя.
Заключительная (но ещё не последняя) статья из цикла про диффузные модели, где мы наконец отбросим примитивную модель из полносвязных слоёв и напишем работающий генератор изображений c архитектурой Diffusion Transformer (DiT). Разберёмся зачем нарезать изображения на квадратики и увидим, что произойдёт с вашей генерацией, если проигнорировать главную "слабость" трансформеров - неспособность понимать порядок.
В этой статье я поделюсь сверхбыстрым руководством, которое покажет, как использовать графы для автоматизации знаний, заложенных в промпты, чтобы создать мощного чат-бота-агента для вашего бизнеса или личного пользования.
Сколько бы раз я ни спрашивал ChatGPT, я не могу получить хороший ответ - нужные мне предложения так и не появляются.
Кажется, что время просто уходит в никуда, и я знаю, что вы сталкивались с такой же проблемой. Дело не в том, что промпт плохо написан, а в том, что ИИ задают плохо структурированный вопрос.
Когда бизнес-логика обработчика запроса выходит за рамки одной транзакции, код быстро обрастает ручными откатами и сложной оркестрацией. Большие системы вроде Temporal решают эту проблему, но требуют собственной инфраструктуры и сложного деплоя — не всегда возможного, особенно в коробочных решениях. Floxy предлагает другой путь: лёгкий встраиваемый Saga-движок на Go, реализующий оркестрацию и компенсации без внешних сервисов, брокеров и YAML DSL для вашего приложения — только чистый Go и PostgreSQL.
Привет, Хабр! В этой статье поговорим о том, как принципы GitOps можно применить к разработке конфигураций 1С:Предприятия.
Часть 2. Путь от простого поисковика по своей базе до инструмента, с помощью которого можно облегчить себе жизнь при работе с конкурентами/поставщиками, да и в общем отслеживать свою товарную нишу.
Меня зовут Евгений. Если вы читали мою первую статью, то знаете, как я, не написав ни строчки профессионального кода, создал с помощью Gemini ИИ-поисковик для нашего сложного ассортимента спецодежды. Это был первый опыт внедрения ИИ в реальные бизнес-процессы. Инструмент заработал, и я мог бы на этом остановиться. Но пытливый ум вел меня дальше. Хотя, в данном случае даже не пытливый ум, а скорее анализ «хотелок» в компании. Вот об этих хотелках и о том, что из этого вышло, я и расскажу.
Эта статья — не о решении проблемы, а о расширении возможностей моего инструмента. Это рассказ о том, как мой внутренний инструмент планомерно эволюционировал в мини-платформу Market Intelligence (это название я узнал уже по факту реализации от того же Gemini). В моем случае это связка «Парсер + Подбор по сторонним данным + Анализ цен». Я хочу не просто поделиться историей, но и на пальцах разобрать логику каждого модуля. Про код рассказывать не буду, так как я не программист, и это в моем случае неуместно. Моя цель — показать, как устроен инструмент, какие бизнес-задачи он решает, и как вы можете применить его в своей нише. В общем, это история о том, как не-программист, вооруженный современным ИИ, может реализовать нужный инструмент.
Первая версия моего приложения эффективно решала задачу внутреннего поиска. Она позволяла быстро находить товары по сложным запросам (а иногда и по запросам, рожденным больной фантазией сотрудников), что значительно ускорило работу менеджеров и адаптацию новичков. Есть данные, есть каша в голове неопытного менеджера, нужен результат. Мой инструмент как раз и помогал с этим, работая как замкнутый контур исключительно с нашими внутренними данными.
Первая часть - https://habr.com/ru/articles/970614/
Но это отдельная история. Когда ты пытаешься решить сложную задачу, ты придумываешь, как языковая модель становится из самой цели сделать модель побольше, становится инструментом для создания мультиагентной системы. И на самом деле тут много новых инструментов появляется, как раз связанных с тем, что необходимо действительно писать достаточно сложный код. И в мае этого года вышла статья Alpha Evolve от компании DeepMind, которая показала, что большая языковая модель может на самом деле сама писать код и решать задачи, если ты можешь проверить решение этой задачи.
То есть много задач, ты можешь проверить, что решение правильное, например, решить какое-нибудь уравнение, но найти само решение сложно.
Или, например, ты хочешь построить, даже в самом простейшем случае, написать какой-то промп, который хорошо помогает решить тебе конкретную задачу. Ты можешь, написав этот промп, запустить систему, получить ответ и проверить, получить метрику на бенчмарке, но как написать сам промп, непонятно. И, собственно, вот эти эволюционные алгоритмы – это для очень ленивых людей, таких как я. Ты просто даешь ей постановку задачи, просишь написать решение, она пишет какое-то решение, ты проверяешь это решение и просишь переписать это решение еще раз.
Дальше применяешь достаточно хитрые подходы, связанные с эволюционными алгоритмами, где фактически в качестве оператора мутации выступает большая языковая модель. У нее есть опыт предыдущий, память. в виде программы результатов, есть некоторые инсайты, что она придумала, и ее задача состоит в том, чтобы эти инсайты, соответственно, объединять в новые программы. Собственно, первый автор статьи «Альфа Эволф» Саша Новиков – это мой аспирант, который уехал довольно давно, но тем не менее очень много не менее талантливых людей работают в институте.
Некоторое время назад я опубликовал на Хабре пост "Гений Пифагора: почему в рекурсивно-вычисляемом клеточном автомате Вселенной наше сознание бессмертно?". В комментариях к тому посту у меня с одним из комментаторов разгорелась жаркая дискуссия о сознании в компьютерной симуляции и существовании души. Мой оппонент приводил аргументы, которые неявно подразумевали существование души, но в явном виде он это утверждение признавать не хотел. Наоборот, он приписывал защиту существования души мне, хотя я отстаивал прямо противоположную позицию. В сегодняшнем посте мы в деталях разберем этот спор и позиции сторон, а также посмотрим, почему при отказе от веры в существование души становится логически неизбежным признание реальности реинкарнации и бессмертия сознания. Но сразу скажу, что для понимания написанного здесь очень желательно прочитать оригинальный пост, из-за которого и возник этот спор.
Я иногда пишу на Хабр и для меня важно понимать, насколько живую тему я выбрал, удалось ли мне ее раскрыть, хорош ли мой текст. Увидеть все это мне помогают внутрихабровские инструменты статистики. Особенно меня порадовало, когда разработчики добавили возможность отслеживать, какая часть читателей добирается до четверти, середины и конца статьи. Но не все нововведения одинаково полезны.
Один из ключевых параметров, за которым я и другие авторы внимательно следят — это число просмотров. Раньше оно считалась как число раз, которое с уникальных браузеров или уникальных аккаунтов открыли твою статью. Полезная штука, позволяет понять, насколько ясно, хорошо и привлекательно ты написал заголовок и вводную часть. На днях я зашел в свой аккаунт и с удивлением обнаружил, что число просмотров двух моих последних статей за сутки выросло в 2 раза, хотя они обе были опубликованы давно. Попытался разобраться, почему. Выяснилось, что теперь по‑новому считаются показы: теперь к числу раз, когда открывали твою статью добавляется число раз, когда ее кому‑то показывали в ленте.
Господа разработчики и уважаемая администрация Хабра. Я конечно понимаю, что на носу Новый год, поэтому вам и вашим корпоративным клиентам нужно закрывать KPI, но не кажется ли вам, что «показ» и «просмотр» — это все‑таки разные вещи. Теперь для меня статистика «число просмотров», которая на самом деле есть «число показов» стала абсолютно бесполезной графой.
Хочу все обратно!
Физики из МФТИ и Национального исследовательского центра «Курчатовский институт» разработали новую теоретическую модель, которая разрешает многолетние противоречия в описании одной из самых опасных неустойчивостей плазмы в установках термоядерного синтеза. Предложенный подход позволяет точнее предсказывать поведение плазменного шнура и открывает путь к созданию более надежных систем управления для будущих термоядерных реакторов, включая международный проект ITER. Результаты исследования опубликованы в журнале Physics of Plasmas.
