1. OpenAI может работать с вашей базой, например, вики техподдержки, но её надо векторизовать. Получится, что модель только ищет по ней и может отвечать фрагментом исходника, но может его обрабатывать как текст (то есть сравнивать, анализировать и тому подобное).
2. Дальше можно использовать подход QA Retrieval Chain для работы с векторной базой. Работает это так: задаём вопрос, LLM формируют запрос к векторной базе, мы вынимаем из неё данные, подкладываем их в вопрос как контекст и передаём в LLM, а они формируют ответ.

1. Какого размера промпты могут быть, сколько, какие лимиты, как их частично обходить.
2. Как подключается база, как закидывать реально большие документы, как эмбеддится вектор, на каких языках это происходит и тому подобное.
3. Разные API.
4. Агентная модель GPT Engineer и АutoGPT.
5. Фреймворк лангчейн (построение цепочек запросов и разбиение макрозапроса на сотни).

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

Сегодня расскажем о том, как в мобильной версии Squadus реализовали востребованную функцию — «прыжок к сообщению» в чате (jump to message).

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

О технических аспектах реализации «прыжка к сообщению» читайте под катом.

В декабре 2021 года под новогодние праздники в приложении Кинопоиска для SmartTV появился раздел с Яндекс Музыкой. Он позволил пользователям на телевизорах открывать новые для себя треки в Моей волне, включать популярные подборки и слушать собственную коллекцию на телевизорах.

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

Меня зовут Лена и я фронтенд-разработчик Яндекс Музыки. В этой статье я расскажу про особенности работы SmartTV и разработки под них на примере свежей фичи, которую мы назвали Время клипов. Теперь в приложении вы можете посмотреть клипы любимых артистов и открывать для себя новых исполнителей, которые подходят вам по настроению.

Под катом обсудим ключевые отличия работы фронтенда над вебом и SmartTV, поговорим про оптимизацию и вёрстку и посмотрим на фотографии множества пультов (без пакетиков).

То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).

Сейчас модно писать, что ML пришел туда и все стало отлично, DL пришел сюда и все стало замечательно. А к кому-то пришел сам AI, и там все стало просто сказочно! Возможна ли ситуация, когда к нам пришел волшебный ML/DL и все стало сложнее, тяжелее и на порядок запутаннее? Безусловно! Разберем такой пример.

Десятки лет при сравнении кодеков и алгоритмов обработки видео исследователи использовали старые добрые метрики PSNR и SSIM с довольно простыми формулами и были счастливы. Но прогресс невозможно остановить! На их место пришли новые метрики и… тут выяснилось, что они взламываются.

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

В этот момент собеседники обычно дружно спрашивают, кому это надо? О, поверьте, есть люди, которым не просто надо, а сильно надо! Представьте себе, что вы руководитель подразделения и у вас жесткие KPI (маркетинг требует обогнать конкурентов, от этого зависят нехилые годовые бонусы у всех сотрудников и особенно у вас). Чтобы улучшить видеокодек на условные 4%, требуются десятки человеко-месяцев труда весьма высокооплачиваемых инженеров, причем, бывает, получается, а бывает, не очень. И тут выясняется, что можно за пару недель работы одного зеленого стажера подшаманить метрику на 7%. Ваши действия? Вспоминается жизненный анекдот «тут-то мне карта и поперла»…

Далее мы популярно затронем взлом методом черного ящика, белого ящика, взлом недифференцируемых метрик (привет дистилляция!) и цирк с дифференцируемыми.

Впрочем обо всем по порядку…

Кому интересен цирк с конями взлом метрик — го под кат.

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

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

Введение

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

Напоминаем, что Centrifugo – это сервер сообщений в реальном времени (real-time). Сервер держит постоянные соединения от пользователей приложения и предоставляет API для моментальной рассылки какого-либо уведомления активным пользователям, подписанным на канал уведомления. Можно использовать для создания чатов, "живых" комментариев, multiplayer игр, стримить данные и метрики (например, быстро меняющиеся курсы валют).

Новая Центрифуга v3 нацелена упростить использование сервера в простых real-time приложениях. Улучшена производительность сервера, существующие фичи обросли новой функциональностью. Centrifugo v3 поддерживает однонаправленные (unidirectional) real-time транспорты, клиентский JSON протокол значительно ускорен. Появилась экспериментальная поддержка высокопроизводительного движка на основе Tarantool. Помимо HTTP теперь есть возможность проксировать клиентские события используя GRPC протокол. Добавлены новые методы и поля серверного API, а также анонсирована PRO версия сервера, нацеленная на бизнес-пользователей.

Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.

Программисты любят хорошие истории, поэтому надеюсь что пятилетний путь к композитному API с помощью GraphQL в боевой среде (на пике выдающей 110 запросов в секунду при 100мс задержке) будет интересен.

[Если вы спешите, проскрольте ниже к урокам и гляньте на открытый код graphql-schema-registry]

На сегодняшний день существуют готовые (проприетарные) решения для мониторинга IP(TS)-потоков, например VB и iQ, они обладают достаточно богатым набором функций и обычно подобные решения имеются у крупных операторов, имеющих дело с ТВ-сервисами. В этой статье описывается решение на базе open source проекта TSDuck, предназначенное для минимального контроля IP(TS)-потоков по счётчику CC(continuity counter) и битрейту. Возможный вариант применения — контроль потери пакетов или потока целиком через арендованный L2-канал (который нет возможности нормально мониторить, например путём считывания счётчиков потерь в очередях).

Очень кратко о TSDuck

TSDuck это open source (лицензия 2-Clause BSD) ПО (набор консольных утилит и библиотека для разработки своих утилит или плагинов) для манипуляций с TS-потоками. В качестве входа умеет работать с IP (multicast/unicast), http, hls, dvb-тюнерами, dektec dvb-asi демодулятором, имеется внутренний генератор TS-потока и чтение из файлов. В качестве выхода может быть запись в файл, IP (multicast/unicast), hls, dektec dvb-asi и HiDes модуляторы, плееры (mplayer, vlc, xine) и drop. Между входом и выходом можно включить различные процессоры трафика, например перемаппинг PID-ов, делать скремблирование/дескремблирование, анализ CC-счётчиков, подсчёт битрейта и прочие типовые для TS-потоков операции.