Гайд по созданию качественных дата-продуктов от SYNQ: топ-4 советов
Принцип «тестируй все» не повышает, а разрушает качество данных. Сотни бесполезных алертов создают шум, в котором тонут действительно важные сигналы, а команда перестает на них реагировать. В Google и Monzo от этого уже отказались. Рассказываем, как перейти от тотального тестирования к точечным проверкам узлов с максимальным радиусом влияния и почему один правильный тест на источник важнее сотни проверок в витринах.
Читать: https://habr.com/ru/companies/postgrespro/articles/951048/
#ru
@big_data_analysis | Другие наши каналы
Принцип «тестируй все» не повышает, а разрушает качество данных. Сотни бесполезных алертов создают шум, в котором тонут действительно важные сигналы, а команда перестает на них реагировать. В Google и Monzo от этого уже отказались. Рассказываем, как перейти от тотального тестирования к точечным проверкам узлов с максимальным радиусом влияния и почему один правильный тест на источник важнее сотни проверок в витринах.
Читать: https://habr.com/ru/companies/postgrespro/articles/951048/
#ru
@big_data_analysis | Другие наши каналы
Собираем систему мониторинга ответов LLM на коленке
Наверняка вы сталкивались с ситуациями, когда модель начинает вести себя в проде не так, как задумывалось: например, ведётся на провокации пользователя или даёт некорректные ответы. Зачастую такие ошибки безобидны, но случаются и не очень приятные ситуации. А если речь идёт о чат-боте, который отвечает на вопросы в юридической или медицинской сфере — практически любая ошибка может быть критичной.
Итак, мы плавно подошли к тому, что нужно каким-то образом валидировать ответы LLM. Давайте разберёмся, как это делать.
Читать: https://habr.com/ru/companies/tochka/articles/949430/
#ru
@big_data_analysis | Другие наши каналы
Наверняка вы сталкивались с ситуациями, когда модель начинает вести себя в проде не так, как задумывалось: например, ведётся на провокации пользователя или даёт некорректные ответы. Зачастую такие ошибки безобидны, но случаются и не очень приятные ситуации. А если речь идёт о чат-боте, который отвечает на вопросы в юридической или медицинской сфере — практически любая ошибка может быть критичной.
Итак, мы плавно подошли к тому, что нужно каким-то образом валидировать ответы LLM. Давайте разберёмся, как это делать.
Читать: https://habr.com/ru/companies/tochka/articles/949430/
#ru
@big_data_analysis | Другие наши каналы
Трансформеры: технология, лежащая в основе больших языковых моделей | Глубокое обучение
Автор оригинала: Грант Сандерсон, адаптация текста Джастин Сан
Данная статья представляет собой подробное введение в архитектуру трансформеров — ключевой технологии, лежащей в основе современных больших языковых моделей, таких как ChatGPT.
Статья подробно описывает архитектуру трансформера, включая блоки внимания (Attention Blocks), где векторы взаимодействуют друг с другом для обновления значений на основе контекста, и многослойные распознаватели (Перцептроны) (Feed-Forward Layers), где векторы обрабатываются параллельно. Объясняется, почему глубокие нейронные сети называются «глубокими» — из-за множества чередующихся слоёв этих операций.
Материал включает практические примеры на основе GPT-3 с её 175 миллиардами параметров, распределённых по почти 28,000 матрицам. Авторы тщательно отслеживают количество параметров на каждом этапе, помогая читателю понять масштаб современных языковых моделей.
Ключевая идея статьи заключается в том, что модель, обученная предсказывать следующее слово, способна генерировать связный текст путём повторяющегося процесса предсказания и выборки. Детально рассматривается процесс токенизации входных данных, когда текст разбивается на небольшие фрагменты — токены, которые затем преобразуются в векторы с помощью матрицы вложений.
Особое внимание уделяется концепции векторных представлений слов в многомерном пространстве, где направления имеют семантическое значение. Авторы демонстрируют, как модель обучается располагать слова со схожими значениями близко друг к другу, а также как векторная арифметика может отражать смысловые отношения между словами.
Завершается статья описанием процесса "вложений" и функции "softmax", которая преобразует выходные данные модели в распределение вероятностей для предсказания следующего токена. Особое внимание уделяется понятию «температуры», которое контролирует степень случайности при генерации текста.
Читать: https://habr.com/ru/articles/951534/
#ru
@big_data_analysis | Другие наши каналы
Автор оригинала: Грант Сандерсон, адаптация текста Джастин Сан
Данная статья представляет собой подробное введение в архитектуру трансформеров — ключевой технологии, лежащей в основе современных больших языковых моделей, таких как ChatGPT.
Статья подробно описывает архитектуру трансформера, включая блоки внимания (Attention Blocks), где векторы взаимодействуют друг с другом для обновления значений на основе контекста, и многослойные распознаватели (Перцептроны) (Feed-Forward Layers), где векторы обрабатываются параллельно. Объясняется, почему глубокие нейронные сети называются «глубокими» — из-за множества чередующихся слоёв этих операций.
Материал включает практические примеры на основе GPT-3 с её 175 миллиардами параметров, распределённых по почти 28,000 матрицам. Авторы тщательно отслеживают количество параметров на каждом этапе, помогая читателю понять масштаб современных языковых моделей.
Ключевая идея статьи заключается в том, что модель, обученная предсказывать следующее слово, способна генерировать связный текст путём повторяющегося процесса предсказания и выборки. Детально рассматривается процесс токенизации входных данных, когда текст разбивается на небольшие фрагменты — токены, которые затем преобразуются в векторы с помощью матрицы вложений.
Особое внимание уделяется концепции векторных представлений слов в многомерном пространстве, где направления имеют семантическое значение. Авторы демонстрируют, как модель обучается располагать слова со схожими значениями близко друг к другу, а также как векторная арифметика может отражать смысловые отношения между словами.
Завершается статья описанием процесса "вложений" и функции "softmax", которая преобразует выходные данные модели в распределение вероятностей для предсказания следующего токена. Особое внимание уделяется понятию «температуры», которое контролирует степень случайности при генерации текста.
Читать: https://habr.com/ru/articles/951534/
#ru
@big_data_analysis | Другие наши каналы
Разбираемся в профессиях: Data Analyst, Data Engineer, Analytics Engineer и BI Engineer
Кто вы в мире данных — аналитик, BI-разработчик или Data Engineer? 🔍 Разбираем реальные роли и показываем, чем они отличаются на практике.
Читать: https://habr.com/ru/articles/951454/
#ru
@big_data_analysis | Другие наши каналы
Кто вы в мире данных — аналитик, BI-разработчик или Data Engineer? 🔍 Разбираем реальные роли и показываем, чем они отличаются на практике.
Читать: https://habr.com/ru/articles/951454/
#ru
@big_data_analysis | Другие наши каналы
Домен-специфичные LLM: как сделать ИИ реально полезным для вашего бизнеса
Универсальные модели вроде GPT хорошо справляются с широким классом задач, но буксуют в узких доменах. Они не знают специфику нишевых индустрий, их жаргон и не имеют доступа к проприетарным знаниям, которые делают ваш бизнес уникальным. Когда нужна система ИИ, которая действительно «понимает» именно вашу предметную область, стоит выбирать домен-специфичные LLM (DSLM).
Читать: https://habr.com/ru/articles/951482/
#ru
@big_data_analysis | Другие наши каналы
Универсальные модели вроде GPT хорошо справляются с широким классом задач, но буксуют в узких доменах. Они не знают специфику нишевых индустрий, их жаргон и не имеют доступа к проприетарным знаниям, которые делают ваш бизнес уникальным. Когда нужна система ИИ, которая действительно «понимает» именно вашу предметную область, стоит выбирать домен-специфичные LLM (DSLM).
Читать: https://habr.com/ru/articles/951482/
#ru
@big_data_analysis | Другие наши каналы
GitOps для Airflow: как мы перешли на лёгкий K8s-native Argo Workflows
Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS.
За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Параллельно учусь в ИТМО по направлению «Безопасность искусственного интеллекта».
В этой статье я немного покритикую Airflow и поделюсь нашей историей миграции на связку Argo Workflows и Argo CD. Spoiler alert: технические подробности и результаты в наличии.
Читать: https://habr.com/ru/companies/alfa/articles/947754/
#ru
@big_data_analysis | Другие наши каналы
Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS.
За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Параллельно учусь в ИТМО по направлению «Безопасность искусственного интеллекта».
В этой статье я немного покритикую Airflow и поделюсь нашей историей миграции на связку Argo Workflows и Argo CD. Spoiler alert: технические подробности и результаты в наличии.
Читать: https://habr.com/ru/companies/alfa/articles/947754/
#ru
@big_data_analysis | Другие наши каналы
Переход с Oracle EBS на Oracle Fusion Cloud связан с вызовами в обеспечении соответствия, сохранении данных и объединённой отчётности. В статье рассказывается о стратегиях интеграции старых и новых систем для поддержки бизнеса и принятия решений.
Читать подробнее
#en
@big_data_analysis | Другие наши каналы
Читать подробнее
#en
@big_data_analysis | Другие наши каналы
Oracle
Unlocking Legacy EBS Data for Oracle Fusion Cloud
As enterprises migrate from Oracle E-Business Suite (EBS) to Oracle Fusion Cloud, they face critical challenges around compliance, data retention,and unified reporting. Ensuring seamless access to historical EBS data while unlocking the advanced capabilities…
Опыт разработки и внедрения универсального коллектора для интеграции КХД с Kafka
Привет, Хабр!
В этой статье хочу поделиться нашим опытом интеграции с Kafka.
В Мегафоне несколько десятков сервисов являются потребителями данных, публикуемых в кластерах Kafka. Все они разрабатывались под узкоспециализированные задачи.
В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.
При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.
Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.
В итоге решение, которое мы внедрили в пром, не в полной мере устроило нас. Сложная реализация подразумевала необходимость привлекать на его дальнейшую доработку дефицитных экспертов.
Тем временем, перед нами встала задача разработки еще нескольких интеграций с Kafka.
Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).
Читать: https://habr.com/ru/companies/megafon/articles/951788/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр!
В этой статье хочу поделиться нашим опытом интеграции с Kafka.
В Мегафоне несколько десятков сервисов являются потребителями данных, публикуемых в кластерах Kafka. Все они разрабатывались под узкоспециализированные задачи.
В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.
При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.
Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.
В итоге решение, которое мы внедрили в пром, не в полной мере устроило нас. Сложная реализация подразумевала необходимость привлекать на его дальнейшую доработку дефицитных экспертов.
Тем временем, перед нами встала задача разработки еще нескольких интеграций с Kafka.
Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).
Читать: https://habr.com/ru/companies/megafon/articles/951788/
#ru
@big_data_analysis | Другие наши каналы
👍1
Business Intelligence (BI) в эпоху ИИ
ИИ заставляет нас, аналитиков, посмотреть на себя в зеркало и задаться вопросом: какова ценность создания и распространения графиков и диаграмм вручную?
Автор перевода: Snezhana Kiseleva
Читать: https://habr.com/ru/articles/951464/
#ru
@big_data_analysis | Другие наши каналы
ИИ заставляет нас, аналитиков, посмотреть на себя в зеркало и задаться вопросом: какова ценность создания и распространения графиков и диаграмм вручную?
Автор перевода: Snezhana Kiseleva
Читать: https://habr.com/ru/articles/951464/
#ru
@big_data_analysis | Другие наши каналы