Что сегодня обсудим?
1. Разметка и дообучение GigaChat в блоке КИБ
2. Подготовка бенчмарков
3. Поставка данных для AI-инициатив
4. Реализация бизнес навыков AI хаба КИБ
5. R&D в КИБ

Youtube: https://www.youtube.com/watch?v=0aOsvYXSALI
Rutube: https://rutube.ru/video/d84d718d41604eb575b3bf1035b26cac/
VK Видео: https://vk.com/video-214877772_456239073

Презентацию можно скачать здесь: https://t.me/rcppe/83?comment=110

Содержание

00:00 Введение

00:28 Цели доклада

01:24 План доклада

02:35 Структура корпоративного блока

03:29 Введение и задачи в банке

04:16 Разработка и использование GigaChat

05:15 Уровни знаний и обучение

07:47 Бизнес-заказчики и таксономия

08:36 Бенчмарки и их усложнение

11:46 Специфические задачи и статьи

14:26 Анализ таблиц

14:59 Создание бенчмарков

16:46 Международные бенчмарки

17:33 Тестовые наборы для анализа таблиц

18:31 Модели с резонингом

19:30 Разметка и обучение моделей

20:18 Поставка внешних данных

21:13 Расширение источников данных

22:10 Анализ новостей

23:50 Тендерный сканер

25:24 Факт-чекинг новостей

26:36 Тендерная документация и стратегические диалоги

28:14 Подготовка к стратегическим диалогам

29:24 Инвестиционный лидогенератор

31:30 Бизнес-навыки и платформа AI Gateway

32:21 Гигапротокол

36:03 Агент для оформления кредитной заявки

37:48 Отраслевая экспертиза и парсинг

38:41 R&D

40:16 Общебанковское подразделение и его задачи

41:16 Взаимодействие с университетами

42:08 Научный трек и агенты

43:02 Бизнес-трек и направления работы

44:29 Развитие больших языковых моделей

45:50 Применение в вузах

46:25 Прогнозы и тенденции

47:41 Риски и ограничения ИИ

50:07 Классические модели и их актуальность

51:34 Приложения для определения психотипа

53:31 Использование ИИ в дизайне

55:16 Применение ИИ в спорте

56:00 Промышленные применения ИИ

56:39 Инструменты на базе больших языковых моделей

58:20 Задачи больших языковых моделей

01:00:20 Проблемы обучения больших языковых моделей

01:01:08 Технология RAG

01:03:10 Разработка RAG-помощника

01:04:32 Инструмент Giga Code

01:05:11 Приложения на основе больших языковых моделей

01:06:04 Влияние ИИ на креативные индустрии

01:07:03 Мифы и реальность об ИИ

01:08:32 Стоимость и доступность ИИ

01:09:30 Примеры использования ИИ в СМИ

01:11:24 Обсуждение использования ИИ в образовании

01:12:59 Ошибки в работе нейросетей

01:15:03 Антиплагиат и нейросети

01:16:34 Скорость и стоимость ответов Гига Чата

01:17:26 Курсы по написанию промтов

01:18:23 Голосовой диалог с ГигаЧатом

01:20:37 Использование нейросетей в программировании

01:21:51 Бесплатные курсы и тарифы

01:24:01 Завершение вебинара

И так, какие же кейсы есть с применением LIMIT

1. LIMIT + OFFSET

   Многие помнят про LIMIT, но забывают про то, что можно еще применять сдвиг.

   SELECT *
   FROM users
   ORDER BY id
   LIMIT 10 OFFSET 20;

   Этот запрос вернёт 10 строк, начиная с 21-й.

   Такой прием применяется, например, в постраничной выдаче результатов запроса.
   
   Но этот кейс имеет и минусы: OFFSET все равно просматривает первые 20 строк, чтобы добраться до нужных. При больших объемах OFFSET работает медленно.
   

2. LIMIT в UPDATE и DELETE

   Да, да - в этих операторах тоже можно использовать LIMIT, не только в SELECT

   DELETE FROM logs ORDER BY created_at ASC LIMIT 1000;

   Так чистят таблицу порциями, чтобы не завалить базу огромным удалением.
   

3. LIMIT в подзапросах

   Об этом часто помнят, т.к. подзапрос является запросом, а в запросах использование LIMIT - вполне привычное дело.

   
   Найдем самый дорогой заказ:

   SELECT *

   FROM orders

   WHERE id = (SELECT id FROM orders ORDER BY price DESC LIMIT 1);

   Это иногда проще, чем возиться с MAX() и джойнами.
   

4. LIMIT vs FETCH … WITH TIES

   В некоторых СУБД (например, SQL Server, Oracle) есть фича:

   SELECT *

   FROM products

   ORDER BY price DESC

   FETCH FIRST 3 ROWS WITH TIES;

   Такой запрос вернёт не просто 3 строки, а все строки, у которых цена такая же, как у третьей записи.
   (например, если на третьем месте несколько товаров с одинаковой ценой).

   
   LIMIT показывает первые N строк после сортировки
   А вот WITH TIES говорит: «Выдай все строки, которые наравне с последней по значению сортировки».

   
   В других СУБД такой синтаксис можно реализовать через LIMIT + подзапрос с оконной функцией RANK()
   

5. LIMIT 0

   Очень полезный трюк.

   SELECT * FROM users LIMIT 0;

   Вернёт пустую таблицу, но со всеми названиями и типами столбцов.
   Это часто используют для генерации схемы в BI-инструментах или в тестах
   

6. LIMIT в CTE (PostgreSQL)

   Можно ограничивать данные прямо на уровне общего табличного выражения (CTE), чтобы уменьшить нагрузку:

   WITH top_orders AS (

   SELECT * FROM orders ORDER BY price DESC LIMIT 100

   )

   SELECT * FROM top_orders WHERE customer_id = 42;

Так мы сначала берём только 100 дорогих заказов, а потом фильтруем по клиенту.

В итоге LIMIT — это не просто «дай 10 строк», а инструмент для оптимизации, постраничной навигации, аккуратных обновлений и даже для защиты от перегруза.

Подписывайся на мой ТГ канал На связи: SQL, чтобы узнавать/вспоминать еще больше нюансов SQL запросов.

1. Блок с ORDER BY предназначен для сортировки результата выборки.
   По умолчанию сортировка ASC (по возрастанию). Можно явно писать:

ORDER BY age ASC -- от младших к старшим
ORDER BY age DESC -- от старших к младшим

2. Можно сортировать сразу по нескольким столбцам:

ORDER BY country, city

Сначала сортируются страны, внутри них — города.

3. Можно писать не имя, а номер колонки в SELECT:

SELECT name, age
FROM users
ORDER BY 2 DESC; -- сортируем по age

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

4. NULL в ORDER BY требует особого внимание.
NULL в разных БД обрабатывается по-разному.

В PostgreSQL:

• ASC → NULL идут в конце

• DESC → NULL идут в начале

можно явно писать:

ORDER BY age ASC NULLS FIRST;
ORDER BY age DESC NULLS LAST;

В MySQL и SQL Server правила отличаются:

• в MySQL NULL всегда считаются «меньше всего» (т.е. идут первыми в ASC).

• в SQL Server можно управлять через ISNULL()/COALESCE().

В MySQL и SQL Server нельзя использовать NULLS FIRST или NULLS LAST при сортировке,

Для SQL Server используем:

ORDER BY ISNULL(age, 9999) ASC;
ORDER BY COALESCE(age, 9999) ASC;

Здесь NULL мы заменяем на большое число (9999), и оно уходит в конец сортировки по возрастанию.
А если хотим NULL в начало — ставим что-то маленькое, например -1.

Для MySQL есть поведение по умолчанию:

• При ASC → NULL идут первые

• При DESC → NULL идут последние

А если нужно наоборот, то делаем хитрость с IS NULL:

ORDER BY age IS NULL, age ASC;

Здесь age IS NULL вернёт 1 для NULL и 0 для обычных значений.
SQL сначала отсортирует по этому условию (0 → 1), а потом уже по age.

5. Можно сортировать не только по полям, но и по функциям.

ORDER BY LENGTH(name) DESC;
ORDER BY purchase_amount * discount;

6. Случайная сортировка - имеет место быть. Но очень "дорога" в использовании на больших объемах.

-- PostgreSQL / SQLite
ORDER BY RANDOM()

-- MySQL
ORDER BY RAND()

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

7. Есть еще такое понятие как COLLATION (сравнение строк).

ORDER BY учитывает локаль (collation). Поэтому, например, русские буквы могут сортироваться по-разному в разных СУБД:

• А может идти перед а, или наоборот.

• Можно явно указать сортировку:

ORDER BY name COLLATE "C" -- по байтовому значению
ORDER BY name COLLATE "ru_RU" -- по русскому алфавиту

Представь, что у тебя есть список имён:
['Елена', 'елена', 'Жанна', 'Анна']

Когда ты пишешь в SQL:

SELECT * FROM users ORDER BY name;

база должна решить:

• считать ли «Елена» и «елена» одинаковыми?

• что идёт раньше: «Ж» или «А»?

• как сравнивать буквы с диакритикой: «é» vs «e»?

Вот именно на эти вопросы отвечает collation.

То есть COLLATION — это как правило сортировки в библиотеке: от него зависит, где именно окажется твоя книга.

То есть, ORDER BY — это не просто «отсортировать», а ещё и про то:

• куда денутся NULL

• как сортируются строки (с учётом локали)

• можно ли сортировать по выражениям или случайно

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

И для формирования таблиц в БД есть свои требования, нюансы и особенности.

Очень часто аналитики сталкиваются со следующими проблемами при работе с данными:

Слишком много столбцов

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

В этом случае необходимо прибегать к нормализации данных — разносить данные по отдельным связанным таблицам.

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

Дублирование данных

В таблице могут храниться одни и те же данные по 100 раз (например, имя клиента в каждом заказе).

Это приводит к сложности обновления — изменил телефон в одном месте, а в другом он остался старым; объем БД растет, что требует увеличения ресурсов для работы с данными.

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

И это тоже про нормализацию данных.

Пустые ячейки (NULL)

Есть поле, но оно ничем не заполнено. И тогда аналитик задается вопросом: что это значит? Что данных просто нет (их никто не вносит), данные вносят, но они потерялись при загрузке в таблицу, либо эти данные необходимо воспринимать как равные нулю...

В этом случае необходимо сначала посмотреть требования к источнику данных, есть ли там обязательность их заполнения. Если данные обязательны к заполнению, то стоит рассмотреть ETL (Extract Transform Load - извлечение, преобразование и загрузка) процесс данных.

И от полученных результатов принимать решение как расценивать NULL данные.

Неправильный тип данных

Телефон хранят как INT, даты — как текст, деньги — как FLOAT.
Такой подход приводит к тому, что в телефоне «съедается» +7, даты не сортируются, а деньги теряют копейки.

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

В этом случае: только правильное использование типов данных.

Нет ключей и индексов

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

Есть первичный ключ (Primary Key) и внешний ключ (Foreign Key)
Первичный ключ - это уникальный идентификатор. Например есть два Ивановых Ивана Ивановича, но у них будут разные ID. Этот ID будет однозначно идентифицировать каждого из них.
Внешний ключ - это ссылка на другую таблицу. Например есть таблица заказов и в ней есть поле client_id. Это поле будет ссылаться на ID нашего Иванова Ивана Ивановича в таблице с персональными данными.

Индексы нам нужны для ускорения поиска.

Представь, у тебя есть огромная книга (миллионы строк в таблице). Если ты ищешь слово вручную — придётся листать страницу за страницей.

Но если есть алфавитный указатель (индекс) — ты сразу находишь нужное слово.

Примеры:

• Поиск клиента по номеру телефона

• Поиск заказов по дате

• Поиск товаров по категории

Индексы ускоряют запросы в разы, но требуют памяти и времени на обновление (поэтому ими злоупотреблять тоже не стоит).

Слияние «всего подряд»

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

А в канале На связи: SQL уже первые посты про структуры запросов и JOIN ждут тебя.

Если тебе нужна поддержка и мотивация или просто сопутствующие слова для твоего развития, то приходи в канала Сила слов. Там каждое утро тебя ждет мотивационное и поддерживающее послание.

Компания Vast Data, занимающаяся инфраструктурой искусственного интеллекта, как сообщается, привлекает несколько миллиардов долларов в рамках раунда финансирования, который может стать крупнейшим в истории израильских технологий, сообщает Reuters. Этот раунд, возглавляемый Nvidia и подразделением Alphabet по развитию CapitalG, может превзойти предыдущий рекорд, установленный компанией Wiz, специализирующейся на облачной безопасности, которая привлекла 1 миллиард долларов при оценке в 12 миллиардов долларов в мае 2024 года.

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

Компания Vast Data, основанная в 2016 году израильскими предпринимателями Ренен Халлак и Шахаром Финблитом, пошла по пути, радикально отличающемуся от её израильских «единорогов». Компания базируется в Нью-Йорке и имеет научно-исследовательские центры в Тель-Авиве и Хайфе. Компания сохраняет бережливость, намеренно не привлекая к себе внимания и, что примечательно, приносит прибыль. Её офисное пространство в выставочном комплексе Тель-Авива лишено привилегий и вечеринок, характерных для «единорогов». Вместо этого она предлагает передовые технологии, растущий список клиентов из числа «голубых фишек» и финансовые показатели, которым позавидовало бы большинство публичных компаний.

К началу 2025 года годовая регулярная выручка (ARR) Vast превысила 200 миллионов долларов, и компания прогнозирует утроение этого показателя в течение года. Один инвестор, знакомый с бухгалтерской отчетностью компании, заявил, что к 2026 году она, скорее всего, достигнет 600 миллионов долларов ARR. В отличие от многих компаний, разрабатывающих корпоративное программное обеспечение и зависящих от краткосрочных контрактов, Vast удерживает клиентов на 5–7 лет, что способствует необычайно низкому оттоку клиентов.

Среди клиентов компании — крупнейшие компании государственного и частного секторов: ВВС США, Министерство энергетики, Booking Holdings, Zoom, Pixar, Бостонская детская больница и стартап Илона Маска в области искусственного интеллекта xAI. Сама Nvidia, один из предыдущих инвесторов, является одновременно и клиентом, и активным сторонником. На конференции Computex в Тайване этим летом генеральный директор Nvidia Дженсен Хуан посвятил часть своего доклада объяснению того, как технология Vast повышает производительность графических процессоров, назвав её критически важным фактором масштабного развертывания моделей ИИ.

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

Рост Vast отражает более широкий сдвиг венчурного капитала и корпоративных инвестиций от броских потребительских приложений к инфраструктуре экономики ИИ. В то время как её израильский конкурент Weka.io привлек $140 млн при оценке в $1,6 млрд, а такие гиганты, как Databricks, планируют IPO при оценках выше $60 млрд, Vast выделяется своей финансовой дисциплиной, глубокими технологиями и стратегическими партнёрствами.

Одно из таких партнерств — с CoreWeave, поставщиком облачных решений для ИИ, который недавно вышел на биржу и взлетел до 77 миллиардов долларов, но затем упал до текущей оценки около 50 миллионов долларов. CoreWeave интегрирует уровень хранения Vast в свой инфраструктурный стек, что свидетельствует о технической надежности Vast и соответствии продукта рынку.

На сегодняшний день Vast привлекла около 380 миллионов долларов, что довольно скромно, учитывая её нынешнюю оценку. Способность компании масштабироваться без лишних затрат позволила ей избирательно подходить к предложениям о финансировании и поглощениях. Хотя IPO пока не ожидается, назначение Эми Шаперо, бывшего финансового директора Shopify, в 2024 году было воспринято как явный сигнал о готовности к IPO.

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

Если раунд завершится так, как и ожидалось, Vast станет уникальной компанией в сфере израильских технологий.

Перевод с английского

ИСТОЧНИК

В нашей жизни есть разные шкафы. Платяной шкаф, кухонный шкаф, шкаф с инструментами и т.д. Так и в мире данных есть разные БД.

Виды баз данных и зачем они нужны

1. Реляционные БД (табличные)

• Данные хранятся в таблицах (как в Excel, только гораздо умнее).

• Таблицы связаны между собой: в одной лежат заказы, в другой — клиенты, и они связаны по уникальному номеру клиента.

• Примеры: MySQL, PostgreSQL, Oracle.

• 📌 Где хороши: когда данные структурированы и связи между ними важны (интернет-магазин, банковские операции).

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

Так и база данных — она состоит из разных «ящиков» (таблиц), в которых хранится разная информация. Но чтобы получить полный «наряд» (то есть ответ на запрос), система быстро соединяет данные из этих ящиков и выдает нужный результат. Это и есть работа с базой данных — быстро и удобно находить нужные сведения, даже если они лежат в разных местах.

2. Документоориентированные БД

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

• Данные хранятся в виде документов (JSON, XML) — как целые досье.

• Каждый документ может содержать разную структуру, без строгих таблиц.

Примеры: MongoDB, CouchDB.

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

📌 Где такие базы удобны? Когда данные часто меняются и не всегда бывают одинаковыми — например, каталоги товаров с разными характеристиками или профили пользователей с разным набором информации.

3. Ключ-значение

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

В базах данных типа ключ-значение, например Redis или Memcached, всё устроено похожим образом: есть «ключ» — это как ярлычок на контейнере, и «значение» — содержимое внутри. Когда нужна информация, система быстро находит значение по ключу — без лишних сложностей и долгих поисков.

📌 Где такие базы классно работают? Когда нужна очень быстрая реакция: кэширование данных, хранение настроек, сессий пользователей, временных значений — чтобы всё на кухне (то есть в системе) шло как по маслу.

4. Графовые базы данных

Соцсети — отличный пример того, как работают графовые базы данных.

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

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

📌 Где полезны графовые БД? В соцсетях для построения друзей и рекомендаций, в картах для прокладывания маршрутов, в системах рекомендаций товаров.

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

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

Графовая база поможет быстро найти нужных людей и понять, как информация и задачи «текут» внутри компании

Итог

База данных — это способ хранить и упорядочивать данные, как мы упорядочиваем вещи дома или в рабочем шкафу.

• Хотите чёткий порядок и строгие связи? → Реляционные БД.

• Нужна гибкость и разная структура? → Документоориентированные.

• Важна молниеносная скорость для простых данных? → Ключ-значение.

• Важны сложные связи? → Графовые.

Как у хорошей хозяйки или стилиста — в базе всё лежит там, где нужно, и всегда можно быстро достать.