2025-07-09: Конференция Saint Highload — в целом ожидаемо

(Из ленты MaksWiki — Блог:Максима Цепкова [ru])

23-24 июня прошла конференция Saint Highload в Питере. Я на ней был, чтобы заглянуть в технологическое развитие. Особых сюрпризов не было, хотя доклады по архитектуре RAG, обеспечивающим использование LLM при ответах на вопросы, касающиеся внутреннего контекста компании, были интересны.

Кстати, про LLM. На открытии я зафиксировал произошедшую смену восприятия. Олег Бунин говорит: «есть похожее в создании музыки, создании ролика, создании программ», и я тут же додумываю: «все это сейчас хорошо делает GPT». А он продолжает: «все это — создание чего-то из ничего, нужен лишь замысел» — и это тоже правда.

Еще для меня был интересен открывающий доклад о выборе технологий как обзор текущего взгляда на технологический стек в целом. А закрывающий доклад о датацентрах в космосе показал развитие ветки вычислительной техники в космосе.

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

В отличие от Teamlead, у меня не получалось прямо на конференции публиковать конспекты докладов. Возможно, потому, что технические доклады требуют от меня большего осмысления. Так что отчет я собрал только сейчас. В отчете — все доклады, которые я слушал. Кроме фейл-митапа, на нем люди рассказывают истории своих фейлов, и есть просьба не снимать материал. Впрочем, про проблемы и ошибки говорят во многих докладах, не только на фейл-митапе.

В отчете следующие доклады. Как и на Teamlead, это малая часть, на конференции восемь параллельных докладов и мастер-классов.

#Дмитрий Кривопальцев, Вадим Клеба. Как выбрать технологии для высоконагруженного проекта и не привлечь внимание санитаров — обзор текущего взгляда на технологический стек для выбора технологий.
#Наталья Макарова из CDEK. Архитектурный квиз: костыль или элегантное решение? — несколько кейсов решения архитектурных проблем, участникам предлагалось оценить, является ли выбранное решение костылем или нет.
#Александр Стерлигов. 20 лет на граблях: ошибки, отказы и выводы — ряд историй отказов сервисов, в том числе приводящих к каскадным отказам, с извлеченными уроками
#Виктор Михайлов. Как правильно готовить RabbitMQ — 8 практических кейсов — последствия родовой травмы RabbitMQ, реализующей протокол от теоретиков, сделавших стандарт, которые теперь надо учитывать всем пользователям.
#Ирина Шахтарина. Кто написал код? Об авторских правах на код, написанный с помощью AI — мое понимание из доклада: пока все мутно, и можно особо не заморачиваться, а практика — разумна.
#Алексей Ситка из Lamoda Tech. Как бизнес-требования диктуют архитектуру: эволюция сервиса уведомлений — эволюционные изменения архитектуры по мере развития сервиса с расширением функционала, с объяснением логики решений.
#Алексей Болтава из Т-Банк. Умный поиск по внутренней базе знаний с использованием LLM: от архитектуры до внедрения — КФП-архитектура, фокус доклада — на поиске, который извлечет контекст для LLM.
#Павел Корозевцев из Яндекс. Прикладной консенсус. Какая Станция должна ответить? — Все Алисы в комнате слушают реплики людей, надо определить — кому отвечать или исполнять команду, чтобы адекватно среагировать.
#Александр Токарев. Почему в космосе (пока) нет дата-центров — обзор текущего развития технологий для компьютеров в космосе.

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

Доклад — обзор вопросов, которые надо решать при выборе технологий. Но по факту на все вопросы есть общий ответ: включить мозг, а не следовать за модой. А подробнее: (1) понимайте вашу задачу, (2) потребности бизнеса и (3) возможности вашей команды. Любая технология имеет плюсы и минусы, для разных задач подходит разное. И с любой технологией потом долго жить, нужны люди, которые ей владеют. Были рассмотрены ключевые аспекты: выбор языка программирования, базы данных и стратегий кэширования, с подробным разбором частых ошибок и мифов. А теперь по содержанию детально.

Выбор языка.

В командах обоих докладчиков два языка. В Яндекс-Диске на python ядро, а на java — высокопроизводительные конкретные сервисы: python обеспечивал отказоустойчивость и масштабируемость, а java — эффективность работы с файлами и БД. В другой команде java + Go, при этом java — высокопроизводительная основа, а Go — для кусочков, которые общаются по http. В рассказе — хорошая иллюстрация к уместности языков для конкретных задач.
И надо помнить, что быстрый язык сам по себе не дает производительности, производительность обеспечивается устройством кода.
По умолчанию — используем что знаем.
Обязательно помните про команду — смогут ли разработчики изучить новый язык и легко ли нанять новых разработчиков, владеющих им.

База данных. В 9 случаях из 10 подходит PostgreSQL. А в том одном случае, когда он не подходит — выбирайте по характеристикам, понимая зачем это нужно. Но помните про сопровождения: был кейс, когда выбрали Кассандру, она подходила идеально по характеристикам, но через два года выяснилось, что поддерживать некому, и лучше бы накостылили что-то на PostgreSQL.

Кроме того, помните, что маркетинг БД часто выпячивает сильные стороны и скрывает слабые.

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

Кэширование. Его часто включают по умолчанию, чтобы разгрузить базу данных. Но есть куча историй, когда кэш просто замедляет и кушает ресурсы. Необоснованное использование кэша может привести к 99 % кеш-миссов, потерей памяти и ненужной нагрузке. Кэш несет много накладных расходов — инвалидация, устойчивость, сетевые вызовы. И даже когда важна скорость — есть альтернативные решения, например, вместо единого сервиса кэширования положить данные в файлик, который загружать в память на всех нодах — это хорошо подходит, если данные редко меняются. Примеры: кэширование стран по координатам, акции и скидки на главной странице сайта и тому подобное.

Общие Выводы:

Разберитесь в задаче: Основа успешного выбора технологий — глубокое понимание бизнес-требований и технических ограничений.
Ориентир на команду: Учитывайте компетенции команды, возможности найма и обучения. Людям не должно быть «больно».
Стройте отказоустойчивые системы, а не просто высоконагруженные: Стабильность важнее пиковых характеристик.
Не спорьте, а разбирайтесь: Избегайте догматичного выбора технологий на основе «крутизны».

Наталья Макарова из CDEK. Архитектурный квиз: костыль или элегантное решение?

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

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

Кейс-1. При перенос серверов из Новосибирска в Москву скрипты, завязанные на время сервера, начали запускаться в пик нагрузки на систему, который приходится на утро московского региона Раньше они запускались утром по Новосибирску, и это было удобно: разработчики уже на месте, а до пика нагрузки еще несколько часов. Решение: явное указание часового пояса на инфраструктурном уровне — оставление Новосибирского времени для серверов в Москве.

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

Кейс-2. Выбор реактивного подхода. Наталью тут позвали диагностировать проблему: команда никак не могла стабилизировать модуль, выдающий подсказки. Оказалось, что в выбранном реактивном подходе разбирался только один человек, при этом документации по реализации не было, поэтому когда он по какой-то причине отсутствовал, то даже простые задачи откладывались.

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

Я, кстати, добавлю, что такие заторы возникают не только при обращении к другим сервисам. Драйвер JDBC обращения к базе данных в Java принципиально работает синхронно, так что обращение к базе тоже останавливает поток.

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

Когда от технологии не стыдно отказаться:

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

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

Кейс-3. Отсутствие документации архитектурных решений (ADR — Architectural Decision Record) и самонадеянность новичков. DevOps обнаружил, что в Elastic Search создано два идентичных индекса, при этом обновляется только один. Он решил, что второй просто забыли удалить — и удалил. Поиск перестал выдавать информацию. Он понял, что он почему-то настроен на тот индекс, которые не обновляется, восстановил его и включил обновление. Поиск заработал, но все стало жутко тормозить. Оказывается, был применен шаблон RW separation: поиск работал по замороженному не обновлявшемуся индексу, а обновлялся другой, и периодически происходило переключение. Решение не было документировано.

Основные выводы:

Включать мозг: Не всегда «новое» или «элегантное» решение является лучшим.
Костыль как временное средство: Костыли допустимы для решения критических проблем, но должны быть легко удаляемыми и не мешать дальнейшему развитию.
Документация важна: Architectural Decision Records (ADR) помогают новым членам команды понимать принятые решения и их обоснования, предотвращая ошибки.
Оценка возможностей команды: Учитывайте уровень компетенций и возможность обучения команды при выборе технологий.

Александр Стерлигов. 20 лет на граблях: ошибки, отказы и выводы

Александр поделился шестью историями из своего двадцатилетнего опыта в IT, посвященными ошибкам, инцидентам и извлеченным урокам. Истории, нарастая по сложности и цепляясь друг за друга, демонстрировали различные аспекты системных сбоев, от неожиданных багов до каскадных отказов и проблем с человеческим фактором. Они показывают важность проектирования систем с учетом отказов, необходимость быстрого реагирования на инциденты, а также необходимость честных разборов ошибок без поиска виноватых. Александр давно стал руководителем, но это не мешает ему работать как дежурным SRE, и он только что сдал смену — за неделю было три инцидента.

А в начале доклада была цитата Роберта Мартина. В авариях и багах нет ничего прикольного. Мы не оправдываем ожидания пользователя, это приводит к взрыву ракет или риску для жизни. Хотя слушать такие истории прикольно, как слушать детектив — если события в нем не затрагивают нас лично и произошли давно.

Кейс-1. Старая история про сложный баг в приложении обработки видео, которое падало, если человек быстро впрыгивал в кадр снизу через 10 секунд пустого кадра. Подозрение сразу было на переполнение буфера, который давали кодеку обработки видео. Причины — неясны, в буфер помещался даже не сжатый кадр, все должно быть нормально. Однако, изучение документации показало, что это — не буфер результата, а рабочая память и она должна быть больше несжатого кадра на заданную величину. И иногда на конкретных кадрах это проявлялось. Урок: внимательно читайте документацию.

Кейс-2. Сервис поделен на пять зон доступности и мониторинг показал, что все они упали. Очевидное подозрение, что упал мониторинг, но он сам поделен на две зоны для устойчивости. Причиной оказались изменения в Firewall, которые нарушили соединения, внесенные безопасниками.

Урок: проверяйте все компоненты инфраструктуры, включая сетевые, и ведите логи обновлений. И учитывайте, что мониторинг тоже может ошибаться.

Кейс-3. Пользователи получали 50 % ошибок, хотя сервис дублирован, и ничего подозрительного не происходило. Оказалось, что балансировщик трафика распределял нагрузку поровну между двумя дата-центрами, в то время, как один из них был неработоспособен. Система была догматично спроектирована с двумя зонами, но без продумывания поведения при реальном отказе.

Урок: продумывайте, как система будет работать при реальном отказе, проводите «хаос-инжиниринг» (отключения, как в одной из компаний раз в неделю) для проверки отказоустойчивости.

Кейс-4. История про каскадные отказы. Упал основной сервис бэка, миллионы клиентов начали получать отказ. Его срочно начали поднимать, он поднялся довольно быстро и хорошо. Однако, тут начали каскадно падать те сервисы, которые стояли за основным сервисом. Оказывается, пока основной сервис не работал, нагрузки на них не было, и автоскейлинг погасил инстансы. После подъема на них пошла массовая нагрузка, скейлинг не справился. Разобрались, добавили реплики вручную. И тут начали складываться базы данных — оказалось, что пока к ним не было обращения по таймауту произошел сброс in-memory кэшей, в результате базы данных оказывались перегружены. Ручного управления прогревом кэшей не было. И тут снова начал складываться основной бэк, потому что на клиенте была настроена политика частого retry при отказах независимо от причины, да и пользователи начали активнее обращаться. В результате выкарабкались только ночью, в результате естественного снижения нагрузки. И это можно сказать, что повезло. Но побочный эффект все равно остался — кэши баз данных оказались синхронизированы — поднимались вместе, это пришлось как-то разводить.

Урок: предусмотрите механизм для отключения автосейлинга при инцидентах, делайте политику retry с учетом кода ошибки, не всегда нужны частые повторы. А еще — управляйте отключением пользователей и функций, ранжируйте их по финансовой значимости. Последний механизм — самый важный: после того, как они сделали, финансовые убытки в результате инцидентов практически исчезли, так как для значимых пользователей мощности всегда хватало. Но им повезло, что уже была метрика. на которую можно было опереться.

Кейс-5. Еще одна история про каскадные отказы. Команда базовой инфраструктуры временно отключила sudo. Через 40 минут это привело к падению всей инфраструктуры. Причиной тоже был retry без таймаута на клиентском сервисе при ошибке, при этом каждая ошибка вызывала alert на почту. И почтовый сервер при обработке этого потока забил обращениями IAM (внутренний и внешний), что привело к неработоспособности SSO, мониторинга и всей инфраструктуры. При этом попытки решить ситуацию вручную тоже оказались не удачны: был специальный способ сбросить письма в /dev/null, но он не успевал, была пакетная быстрая обработка писем, но она их реально отправляла, нагружая IAM. Так что потребовалась слаженная работа нескольких команд, ответственных за разные сервисы.

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

Кейс-6. История о том, что разбираться с инцидентами, которые вводят систему в критичное состояние по рискам падения, надо немедленно. Началось с того, что упала одна реплика базы данных из трех. Админ решил, что до утра — терпит, две-то работают. Но ночью лег дата-центр. И в результате была потеряна консистентность данных, потребовалось 8 часов для восстановлению.

Урок: Если система переживает два отказа, и один уже произошел, чините проблему быстро, не откладывайте.

Общие выводы:

При расследовании инцидентов главное — восстановление в моменте.
Проектируйте поведение системы при отказах.
Не ищите виновных, ищите, как исключить инциденты в будущем.

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

Виктор Михайлов. Как правильно готовить RabbitMQ — 8 практических кейсов

В докладе восемь практических кейсов по использованию RabbitMQ, освещая как его преимущества, так и потенциальные подводные камни. Я полагаю, что основная проблема RabbitMQ — родовая. Как сказал Виктор, RabbitMQ реализует протокол AMQP, придуманный некоторым комитетом по стандартам в 2003 году, и реализует его не полностью, а «как может». При этом RabbitMQ появился через четыре года после протокола, в 2007. Остальное, на мой взгляд, следствия: разработчики связаны этим протоколом и не могут его менять, даже в тех местах, где он не слишком разумен. В отличие от Kafka, где разработчики сами хозяева протокола.

Я тут вспомнил старую историю, которая произошла на заре развития ИТ и известна мне по книгам. В 1960 году теоретики собрались на большую конференцию и придумали первую спецификацию языка общего назначения — Algol. Она оказалась настолько сложной, что даже ограниченная реализация потребовала 8 лет, в 1968 появился Algol-68, и он был очень тяжелым. При том, что другие языки того же периода разрабатывались примерно за год-полтора: Cobol (1960), PL/1 (1964), С (1969), Pascal (1970).

Дальше — особенности, о которых говорил Виктор. Отмечу, что часть из них не специфична для RabbitMQ, а характерна для любой работы через сообщения.

Межсервисная схема с брокером. Брокер скрывает сложность, но добавляет промежуточный уровень, где могут накапливаться сообщения, увеличивая точки отказа.
Сообщения распространяются по каналам, с которыми связан Producer и Consumer, и каждый канал — один поток в Erlang.
Consumer слушает сообщения, а не вытягивает их, в отличие от Kafka. Сообщения удаляются после acknowledge, их нельзя повторно прослушать.
basic.publish не возвращает подтверждения о записи сообщения. Это может привести к потере сообщений до записи в TCP-сокет. Решение: Использовать confirm mode. Он является расширением AMQP и требует перевода канала в этот режим, зато гарантирует доставку сообщений.
Обман записи на диск: basic.publish может вернуть «ок», даже если сообщение еще не записано на диск. Если RabbitMQ упадет до записи, сообщение будет потеряно. При этом сообщения размером менее 4KB могут храниться в памяти (в индексе), а на диск попадают только большие. От этого не спасает даже persistent. Важно понимать, что сообщения могут быть потеряны при падении брокера, если их не доставили активным слушателям.
Ack от consumer может потеряться, и сообщение придет повторно. Поэтому обработка должна быть идемпотентной, повторный приход не должен приводить к ошибкам.
Сообщения читаются пачками по prefetch count. И при малой нагрузке это запросто приводит к тому. что все сообщения попадают в один consumer.
Если RabbitMQ испытывает проблемы с диском или памятью, он может заблокировать канал для публикации. Поскольку publish асинхронный, вы не узнаете об этом без специального хендлера на connection blocked/unblocked. При этом проблема может быть вызвана не вашим каналом, а «шумными соседями» — другими активными каналами.
Когда несколько каналов/consumer пишут в одну и ту же базу данных, это может привести к блокировкам или падению базы при пиковых нагрузках, даже если RabbitMQ масштабируется. Понимайте, что не все проблемы решаются скейлингом consumer.
Часто бизнес-логика пишет в базу и отправляет сообщения. Если при обработке базы данных возникает ошибка уже после отправки, то транзакции произойдет откат, а сообщение — останется. Тут полезен паттерн Outbox Table: запись в базу, а затем чтение из нее для публикации.
Infinite Retry Policy: если приложение получает сообщение из RabbitMQ, обрабатывает его и пишет во внешний сервис, и этот сервис недоступен, сообщение может бесконечно повторяться, и это может привести к очень большой очереди. Нужно добавить задержку между повторными попытками. При этом RabbitMQ не поддерживает «подъем по задаче» (как Kafka), он про стабильный connection.

Ирина Шахтарина. Кто написал код? Об авторских правах на код, написанный с помощью AI

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

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

Алексей Ситка из Lamoda Tech. Как бизнес-требования диктуют архитектуру: эволюция сервиса уведомлений

Сервисы уведомлений были размазаны по монолиту, однако в некоторый момент было принято решение сделать отдельный сервис и постепенно на него переходить. Основной запрос бизнеса — начать помимо sms использовать push-уведомления, если они доступны, потому что так сильно дешевле.

Это была первая версия, а дальше она развивалась: делали отправку через sms, если push не доставил сообщение, подключали другие транспорты, включая давно существовавшие почтовые уведомления и голосовые сообщения, обобщали шаблоны и технические механизмы, делали сложные механизмы для времени уведомлений, например, отправить за день до даты прибытия заказа на ПВЗ. И Алексей показывал, как эволюционно развивалась архитектурная схема, появлялись новые блоки и очереди между ними.

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

Технически это Go и PostgreSQL, Kafka для внешних входящих событий и RabbitMQ для внутренних очередей, Redis для буфера отложенных сообщений. Сообщение не всегда содержит полную информацию в своих параметрах, иногда требуется запрос к другим сервисам — это вынесено отдельно в ходе оптимизации, чтобы не задерживать основную очередь.

Алексей Болтава из Т-Банк. Умный поиск по внутренней базе знаний с использованием LLM: от архитектуры до внедрения

Реализованная архитектура решения RAG (Retrieval-Augmented Generation): запрос передаем в поиск, а дальше их передают в LLM как контекст для формирования ответа. Важно, чтобы помимо ответа от LLM были ссылки на найденные документы. В презентации есть архитектурная схема. Предварительного расширения запроса не делали. И повторный поиск в ходе диалога с LLM для расширения контекста не выполняется. Основной фокус рассказа был на реализацию поиска.

Одна из проблем при реализации таких решений — оценка качества ответа, тут нужны какие-то метрики и тестовые сценарии, которые покажут, что предлагаемые изменения не ухудшат ответы на вопросы, иначе могут быть вечные качели. при которых улучшая одно мы ухудшаем другое. Поэтому, помимо экспертных оценок и метрик реакции пользователей (лайки, клики, конверсия в «решение проблемы») надо формировать dataset вопрос-ответ с разметкой для проверки, который сложно собрать вручную. Для этого была применена синтетическая генерация вопросов LLM на основе реальных документов и их последующая валидация экспертами.

Первым подходом была нарезка документов на фиксированные куски с перекрытием. Она дала 50-60 % релевантности. Попытки улучшить за счет очистки от кода или summary документов улучшил результат не сильно. А вот опора на структуру markdown с сохранением в каждом фрагменте всей иерархии заголовков, к которой относится фрагмент сильно улучшило и релевантность поиска, и последующую обработку LLM — ей по заголовкам стало понятнее содержание фрагмента. Еще помогла комбинация поиска по representation с традиционным текстовым поиском и гибридное ранжирование результатов.

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

В рассказе было несколько конкретных проблем.

Доменный сленг: LLM не понимает внутренние аббревиатуры и сокращения. Это решили, собрав и подключив отдельный словарь.
Запросы с контекстом пользователя, типа «а что было на последнем ретро»: для ответа надо знать команду пользователя и найти соответствующий протокол. Это не решено.
Настраивали поиск ответов на конкретные вопросы, а после запуска пользователи начали использовать как бот поддержки: кидать большие фрагменты с описанием проблемной ситуации и пачкой вопросов.
Права доступа сейчас не обрабатывают, ищут по общедоступным документам. Хотя, я думаю, что нет проблемы поставить фильтр по результатам поиска с учетом прав доступа того, кто спрашивает, и отгружать в LLM такой результат.

Павел Корозевцев из Яндекс. Прикладной консенсус. Какая Станция должна ответить?

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

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

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

Александр Токарев. Почему в космосе (пока) нет дата-центров

Основной тезис доклада: датацентры в космосе, которые будут дешевле, чем датацентры на земле на данном этапе технически не реалистичны. При этом в инфополе есть много проектов о том, что вот-вот все взлетит. Помимо понятных проблем с задержкой связи между землей и орбитой есть проблемы с питанием, охлаждением, защитой от радиации и обслуживанием — датацентр должен работать надежно. Например, ряд проектов по питанию не учитывает проблемы с охлаждением. Технологии охлаждения есть, например, на расплавленном металле, но они дорогие и экономика для датацентра не сойдется, на земле будет дешевле. Ну и преувеличение достижений рулит, есть российский (и не только) проекты, громко заявляющие о перспективах. при том, что реально на орбите работает Raspberry PI или что-то аналогичное.

Однако, при этом на орбите на спутниках и космических станциях обработка информации идет. Но она ориентирована на решение внутренних проблем космических систем. Например, реализована связь между спутниками одной группировки для обмена информацией точка-точка по лазерному каналу, при этом оказывается, что поддерживать постоянный канал эффективнее, чем наводиться при необходимости. Starlink ежедневно перегоняет 45 петабайт данных внутри своей сети. Потенциально интересная задача — обработка спутниковых снимков еще на орбите, чтобы экономить канал до земли — там есть ограничения по доступности, а объемы информации у детальных снимков большие.

Источник