Вы наверняка замечали, что в начале общения ИИ кажется очень толковым и понятнливым, правда почему спустя 10-20 сообщений начинает путаться, повторно совершить те же ошибки которые уже совершал или выдавать рассчеты с ошибками. Это не случайность, а следствие мироустройства. Давай разберемся почему это происходит и как именно ИИ все “помнит” и почему его память устроена иначе чем у человека.

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

Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.

Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?

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

Распознавание аудио решили делать через сервис Speech2Text, пример использования API которого я и покажу в этой статье. В черновом варианте получаем примерно следующую схему работы (нас сейчас интересует прямоугольник с подписью Speech2Text connector):

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

Современные РРС – это уже не просто альтернатива ВОЛС, это уже полноценная, хорошо масштабируемая транспортная сеть.

Всё о современных радиорелейных системах для самых маленьких.

В середине девяностых казалось, что жанр RPG уже ничем не удивит: магические мечи, драконы и эльфы давно набили оскомину, а чего-то по-настоящему революционного в этом жанре почти не выходило. Но в 1997 году Interplay выпустила Fallout — игру, которая стала глотком радиоактивного воздуха для всех уставших от фэнтезийных штампов. Здесь не было спасения мира в привычном смысле, зато была свобода действий и последствия каждого решения, здесь можно было встретить чёрный юмор и бескомпромиссную жестокость, а атмосфера Америки после ядерной войны ощущалась на удивление правдоподобной. Именно об этой игре, ставшей эталоном и началом культовой серии, сегодня и пойдёт речь.

Я отлично помню, насколько меня захватывала сама идея, что где-то за пределами знакомого нам мира лежат бескрайние радиоактивные пустыни, по которым можно бродить в поисках приключений. Да, пустошь так и манила своей свободой и непредсказуемостью, а руины городов, бродячие мутанты, убежища и старые военные базы хранили немало секретов (и, конечно же, лута =) ). Даже запустив игру сегодня, нетрудно ощутить то же любопытство и легкий трепет перед неизвестностью, даже после десятого прохождения. Как и в конце 90-х: Fallout по-прежнему умеет поражать воображение и дарить чувство подлинного открытия, благодаря чему фанаты, возвращаясь в её ламповый мир, попадают словно в родную гавань и с трепетом на сердце окунаются в столь опасный, но неимоверно манящий постъядерный мир.

Нет, речь не про кэш в памяти. Так было бы слишком просто. У нас сегодня будет препарирован ORM, который честно запрашивает данные у реляционной СУБД, маппит в объекты, подключает связи и отдаёт в логику приложения в виде объектов. И всё на порядки быстрее, чем прямой запрос из кода приложения.

Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.

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

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

Команда Spring АйО перевела и адаптировала доклад Мацея Валковяка “Performance oriented Spring Data JPA & Hibernate”, в котором на наглядных примерах рассказывается, как существенно нарастить производительность приложения, оптимизировав его взаимодействие с БД. 

Доклад будет опубликован тремя частями. В первой части было рассказано об оптимизации управления подключениями к базе данных. Во второй части мы посмотрим на то, как оптимизировать код и настройки Spring Data и Hibernate, чтобы минимизировать количество отправляемых в базу данных SQL запросов. 

Расцвет эпохи программируемых калькуляторов в нашей стране пришёлся на середину 80-х годов. Потом на смену относительно сытым и благополучным временам пришла эпоха бандитского капитализма, когда стране стало не до выпуска своей высокотехнологичной продукции бытового назначения, вот уже сменились поколения, но ностальгия по тем временам, когда мы бессонными ночами пытались сократить код программы хотя бы на пару байтов, чтобы уместить задуманную функцию, выискивали всё новые и новые недокументированные возможности, придумывая способы, как их можно использовать на практике, сочиняли целые циклы рассказов в качестве фона для наших игровых программ, не даёт забыть свой МК-61 со 105 байтами программной памяти. Поэтому хочу написать заметку о том, что собой представляли и как работали эти самые программируемые калькуляторы. Даже если эта тема сегодня периодически и поднимается, то не настолько часто, чтобы приесться уважаемому читателю, так что надеюсь поведать что-то новое.

pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.

Привет! На связи Дмитрий Руденко из команды Databases Т-Банка.

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

Один из таких аспектов  —  процесс уборки мусора, — autovacuum, вычищающий мертвые версии строк таблиц. В статье рассмотрим причины возникновения одного из самых неприятных подвидов —  autovacuum: to prevent wraparound.

Научимся превращать бизнес-требования в рабочую схему БД и документировать ключевые решения! Без недопонимания, технического долга и смс.

Привет! Недавно наткнулся на игру Cube Composer, в которой нужно расставлять функции в правильном порядке, чтобы преобразовать разноцветную фигуру, придав ей определённый цвет. Вроде простая вещь, но зацепила на пару часов. Поэтому я решил поискать другие интересные игры, связанные с IT. Так родилась эта подборка.

В этой статье мы расскажем, как создать собственного Telegram-бота, который интегрируется с amoCRM и распределяет уведомления о событиях в CRM, в зависимости от ролей пользователей. Система позволяет сотрудникам получать уведомления в том формате, который соответствует их обязанностям: отдел продаж видит сумму сделки и стадию, администраторы получают подробную информацию, а обычные пользователи – краткое сообщение о новой сделке. Такой подход способствует сокращению времени реакции на новые лиды, упрощает контроль за сделками и снижает необходимость постоянного ручного мониторинга CRM-системы.

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

Речевая аналитика в контакт-центре, или в отделе продаж — это ключевой инструмент для оценки качества обслуживания и соблюдения стандартов общения. С развитием больших языковых моделей (LLM), таких как YandexGPT, подход к анализу диалогов кардинально изменился. Теперь вместо поиска словосочетаний и настройки сложных шаблонов — достаточно передать весь диалог модели и задать ей понятные вопросы