PostgreSQL как векторная база данных: ИИ‑поиск без лишних сервисов

Итак, коллеги, да, всем доброго, доброго вечера. Рад вас всех приветствовать на сегодняшнем открытом уроке. Зовут меня Алексей Железной. Сегодня вместе с вами будем говорить про такую прекрасную базу данных, как Позгос. На сегодняшний вечер это будет моя любимая база данных. Немножко расскажу о себе. И, собственно, начнём.

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

Давайте на всякий случай проверим, что меня хорошо видно и слышно, да? Если так, то поставьте, пожалуйста, плюсик или там какую-нибудь реакцию, как вам удобно. Если вдруг что-то потеряется в какой-то момент, надеюсь, такого не произойдёт, но в любом случае а будем стараться быстро реабилитировать связь. Вы об этом, соответственно, пишите. Если я не замечу, то коллеги, которые мне помогают сегодня от команды Отоса, смогут мне поассистировать в этом плане. Отлично. Рад то, что всё хорошо видно, слышно.

Давайте кратко расскажу информацию о себе. Зовут меня, как я уже сказал, Алексей Железной. Являюсь став дата инженером в финитех компании. На текущий момент и на последних проектах строю аналитические хранилища данных на базе Кликхауза и смежных инструментов и систем. Это кавки, гринпламы, постгресы всякие, трина, дbтишки, airflow и множество из других инструментов, которые у нас входят в группу больших данных Big DAT. Да. Соответственно, задача в основном это построить с нуля хранилище, аналитическое хранилище на базе Глихауза. Это распределённая P система и, соответственно, достаточно много нот, шардов, которые нужно увязать между собой. После этого предоставить эту инфраструктуру и саму логическую структуру хранилища для дальнейшей загрузки данных, их использования, обработки и визуализации, то есть представления конечным бизнес-пользователя.

В рамках Отуса, который я сегодня также представляю, я преподаю уже больше 5 лет и являюсь руководителем нескольких курсов по кликхаусу, по двых аналитике, по гринпламу. Ну и также опять же преподаю на курсе по постгрусу, который сегодня также представляет, да, немножко тавтология случилась, но пока разминаемся. Соответственно, мои контакты на случай, если захотите пообщаться на тему баз данных, bigдаты или прочих, представлены здесь на экране. Ну а мы, пожалуй, пойдём с вами дальше.

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

Соответственно, немножко информации я рассказал о себе. Буду также очень рад информацией о вас. Какая у вас должность, какой целью пришли сегодня и опыт работы с постгресом. Было бы наиболее интересно это узнать. Соответственно, в рамках нашей с вами сегодняшней лекции мы постараемся раскрыть тему постгреса с точки зрения привязки к искусственному интеллекту, к AFC всей вот этой повестке, а для того, чтобы быть немножко, так скажем, в тренде. Ну, а на самом деле, а поскольку сейчас эта тема очень сильно набрала обороты, если раньше нам казалось то, что все просто на этом мыльном пузыре скоро лопнут, сейчас всё больше и больше подтверждений того, что наша жизни техническая, и реальная в какой-то степени всё-таки меняются ввиду появления таких мощных технологий. В общем, буду рад а вашему вашей краткой информации о себе, но мы пока пойдём дальше и поговорим немножко об Утусе.

Сама по себе US компания в сфере онлайнообразования создаёт авторские онлайн-курсы для различных специальностей, специалистов и других, соответственно, а систем смежников и так далее. Уровни совершенно совершенно разные у этих курсов, от джунов до лидов, а часть из них, соответственно, в том числе помечена на лендингах этих курсов. Разрабатываются отдельные программы на основе запросов IT компании к кандидатам. Изначально эта компания развивалась, становилась как компания, которая предоставляла курсы по увышению квалификации, но с течение времени с появлением новых преподавателей, новых сфер, специфик, а, очень сильно начала, соответственно, развиваться. У Отуса есть образовательная лицензия, соответственно, предоставляется в рамках окончания курса, как минимум по части курсов. Расскажу вот про те, которые я представляю. Предоставляется отдельный а сертификат о прохождении этого курса. И также можно получить удостоверение о повышении квалификации, а в случае, если успешно защитили проектную работу на нашем курсе. О том, из чего состоит сам курс, какие составные элементы, сколько лекций, какие домашки, как проходят. В целом занятия поговорим чуть-чуть позже. Но пока ещё кратко про US.

Направлений курсов достаточно много. Они достаточно активно появляются, часть из них закрываются, часть из них дорабатываются на основе отзывов от вас и на основе текущего рынка, текущего опыта, соответственно, а самих преподавателей, технических специалистов и не только. Я, соответственно, представляю сферу, которую можно здесь выделить как сферу датасаciнса, но это аналитика, анализ, а, большие данные и, соответственно, БДИки. По этим вопросам можно, в том числе ко мне обращаться. Соответственно, это всё, что хотелось рассказать вводной части.

Давайте я немножко познакомлюсь с тем, что вы написали в представлении, и пойдём говорить про постг векторную базу данных. Посмотрим, что же здесь можно сделать буквально за то небольшое количество времени, которое нам отведено сегодня. Григорий Python Backend Developer пришёл на вебинар, чтобы послушать провекто про про вектора, потому что изучаю рак. Отлично. Добро пожаловать. Так, Камила, да, спасибо большое за вводную информацию. Здесь обратите, пожалуйста, внимание, коллеги, на сообщения от моей коллеги, да? А правила, сам курслендинг, где будет выложена соответствующая запись. И также будет очень приятно, радостно и в целом полезно, если вы пройдёте опрос по завершении нашего вебинара, чтобы мы понимали, что было хорошо, что было плохо, чтобы я также знал, что нужно улучшить для следующих наших открытых уроков.

Итак, дальше. Выпускный курса AIL Advance. Сейчас без работы. Сделал маленький проект NSQ Lite и хотел бы подробнее войти в дата инженеринг и инфраструктуры базданных. Отлично. Очень поощряю такие начинания. Спасибо большое, Олег. Системный архитектор, интересует использованию Постгрос для рага. Отлично. Михаил Java разработчик. Опыт с Постгрос около 7 лет. Очень круто, прямо действительно круто. Так, а, Григорию, видео Владислав C. О, добрый вечер. А, хочется прослушать инфу про постга и вертикали векторов и и отлично. Надеюсь, то, что получится ответить на ваш вопрос. Так, Двос инженер в ритейле с коллеги. Андрей, добрый вечер. Евгений, разработчик ДВХ с постгроса работа в год. Отлично. Итак, соответственно, вот так активно использую Постг для решения задачи автоматизации в рознице и своих проектах. Отлично.

Сам по себе Постгрос достаточно мощная СБДшка, которая начала развиваться очень-очень давно. Одна из, наверное, старейших, которые сохранили свой тот же пыл развития и до сих пор непременно обновляются как комьюнитиверсиями, так и отдельными вендерами поставщиками более более, может быть, продвинутых с какой-то точки зрения, ну, и платных версий Постгроса в том числе. Соответственно, сам по себе Постгрос у нас очень сильно представлен на рынке и как бы то ни было, он никуда, скорее всего, не денется. Базовое - это OLTP СУD, которая предназначена в первую очередь для хранения, обработки транзакций. Очень хорошо подходит для того, чтобы быстро информацию к себе сохранить, записать, если нужно будет сделать апдейты, делиты в целом базово произвести какую-то аналитику и в дальнейшем, в зависимости от ваших объёмов, либо остаться на этом же постгресе, либо передать какие-то более подходящие для терабайт, питабайт данных системы типа гримфламы или кликхауза. Часто многие проекты начинаются с постгроса или различных его тоже ответлений, как онсорсных, так и не очень, и в дальнейшем уже развиваются в нужной своей стезе.

Поэтому, собственно, как и на предыдущем открытом уроке по Кликхаусу, когда я тоже рассказывал про подобную связку между бдшкой и и а хочется поднять такой вопрос перед нами всеми. Если у нас есть уже постг на проекте, он, скорее всего, действительно есть. И у нас возникает вопрос вот переделки нашего проекта либо его доработки, давайте так, апгрейды эволюции, да, нашего проекта в сторону проекта, который предусмотрен, который строится вокруг и решений, да, это сейчас модно PDLC, всякие решения AI, PDLC. И, а, ответим, попробуем на вопрос, есть ли функционал такой у Постгруса для того, чтобы не встраивать дополнительные СУBD, которые векторные, которые специализируются как раз на таких алгоритмах поиска гибридного, векторного и так далее, а у вас потёся именно функционалом этой отдельно взятой БДшки. Этот вопрос постараемся сегодня себе задать и, соответственно, на него ответить. Опять же, делитесь своими мыслями.

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

Так, а причёл целях освание, интегрирования и в постгре издав возможности автоматической генерации векторной BD. Круто. Андрей, как получить прош прошлый урок про тоже для кликхауза? Как вот здесь вот чуть выше моя коллега Камилла написала, есть группа во ВКонтакте, куда публикуются записи, а по, соответственно, нашим вебинарам. Там её можно найти. Прошлый урок. Могу подсказать, буквально секунду, потратить на это время. Могу подсказать, когда этот урок был. Он был 25 марта. Соответственно, вот в это время можно его искать. Назывался развитие на основе клиckхауса, где две буковки и, типа колабо такой вот. Ладно, давайте, соответственно, начинать.

Цель вебинара- научиться работать с ПГТР одно из главных возможностей постгреса в этой стезе, да, это наше дополнительное расширение. Попробовать его, соответственно, поставить в зависимости от того, сколько у нас времени остаётся, либо посмотрим на уже готовой виртуальной машине, которую я развернул до нашего вебинара. Изучить возможности гибридного поиска в рамках одной базы данных. И вместо краткого сравнения со спецдэшками мы поговорим про индексы, которые здесь могут помочь нам ускорить выполнение тех или иных запросов. И это, соответственно, поможет нам понять и ответить на вопрос, стоит ли, а останавливаться только на уровне постгреса и как и во многих других сферах, считать, что Постгрос подходит для 95% ваших задач или всё-таки нужно будет идти в специализированные СУБДшки для решения поставленных целей.

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

В рамках нашей лекции мы также будем рассматривать специализированные индексы, но очень кратко. В конце вебинара будет отдельный слайд со списком дополнительных материалов и статей, которые очень рекомендую почитать, с которыми рекомендую ознакомиться. Соответственно, сам по себе векторный поиск анализирует сематическое значение данных, смысловое значение и позволяет компьютерам, компьютерам понимать взаимосвязи между абстрактными концепциями, обрабатывая неструктурированные данные, как, например, медиафайлы. Фотографии, видео, то есть то, что мы стараемся, а, так или иначе преобразовать на компьютерный уровень, чтобы в дальнейшем обучать модели, делать фильтрацию моделей, делать, наоборот, поиск для дополнительных поисковых движочков, которые основаны, в том числе на искусственном интеллекте и так далее. Сам себе векторный поиск ориентируется и на текст, и на числовые данные, и на медиафайлы. Главное преобразовать нашу смысловую информацию в так называемой имбединге. Они встроены в целом таким вот одним из основных слоёв для множества различных систем, э для трансформеров, для отдельных моделек, для задач, которые решают вопросы перевода текста с одного языка на другой и так далее.

А так применяется ли библиотека Word to VC внутри векторного поиска? На текущий момент не уточню. Возможно, чуть-чуть, соответственно, позже а будет время для того, чтобы это быстренько попробовать поискать. Соответственно, поскольку разные библиотеки могут быть использованы по-разному или в рамках ПГЕктора это может использоваться в рамках другой библиотеки для того же кльхауза, нет, поэтому здесь не подскажу, но по названию кажется, что вполне могут быть.

Как сам по себе работает векторный поиск? Очень-очень кратко и ёмко можно представить на вот этом слайде. Во-первых, идёт процесс векторизации. Модель глубокого обучения обрабатывает входные данные, выдаёт вектор признаков тех самых имбединг. После этого для того, чтобы на наших огромных объёмах информации, поскольку, да, здесь вот в сфере EИ огромные просто данные прокачиваются, и просто так эту информацию на условном одном ноутбуке как-то хранить без возможности дополнительного индексирования будет практически нереально. Соответственно, нам нужно дополнительно дополнительно эту информацию в той или иной мере разметить, соответственно, проиндексировать. Для быстрого выполнения поисковых запросов векторы организуется с помощью специализированных алгоритмов, часто хранящихся в специальной векторной базе данных. Собственно, поэтому мы можем в лёгкое отступление уйти в сторону клика, который по умолчанию является вектором кликахауса. Примерами таких векторных СУД, которые мы бы могли рассмотреть, представлены здесь тоже на слайде. Но спрашивается можно? А зачем? Есть у нас всё-таки есть PG вектор, как который мы можем а установить на любой постгрес. Б, поскольку экстеншены в рамках постгреса работают только в рамках выбранной субдшки, мы можем совмещать данные, которые относятся к LTP, которые относятся к маломайской аналитике с данными, которые мы будем использовать, в том числе для векторного поиска. Соответственно, останется только решить задачу передачи данных через какие-нибудь дблинки, фдвшки между СУBD внутри постгреса и дело в шляпе, либо на ту же базу данных и навешиваю типвектор. Почему бы нет?

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

Базово, помимо всего прочего, нам ещё нужно эту информацию как-то внутри себя хранить, те самые векторы. Как же нам это можно решить? Решение достаточно простое. Есть специализированный exнtion, а, openсоourсный, который был разработан специально для нашей любимой на сегодняшний день базы данных постгсов. Экстрашн называется, как вы можете видеть, PG-вектор, как я его уже здесь называл. Соответственно, здесь указан гитрепозиторий. Единственное, что характерно для Постгреса, те, кто с ним достаточно давно а работает, возможно, меня поддержит. Харатерно для Позгоса то, что в какой-то момент все вот эти репозитории начинают выглядеть вот так. Это последний комит там был 2 месяца назад, и это начинает немножко напрягать. Но тем не менее до сих пор вектор много где можно увидеть. И опять же, если есть постгрос, поставить дополнительный экстеншен, попробовать реализовать те или иные операции можно достаточно легко. Опять же покажу, как это можно сделать сегодня на практике.

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

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

Так, а здесь пока кратко для чего не используется, представляю и посмотрю, что у нас в чате происходит. Так, Алексей, прошу прощения, а что вопрос не по теме. Видел вас на на слайде ссылка на линк. Скажите, какова ситуация? Стоит ли там регистрироваться? Понятно, что сейчас без без обходных путей туда не попасть. Нормально ли я работаю сервис? Просто я слышал, что там блокирует аккаунты. Григорий, не смогу прокомментировать никак этот вопрос. Ссылка есть. Соответственно, можете сделать вывод, что я не просто так ею делюсь. То есть можно там что-то, какую-то информацию читать. Часто попадается информация, которая может меня интересовать, в том числе по базам данных. На этом, пожалуй, от комментария в дальнейших откажусь по этой теме. Можно ещё считать манхэттенское расстояние. Также называется L1. Да, абсолютно согласен. Отличный тоже вариант. Итак, мышка, не буянь. Так, система измеряет расстояние до сохранённых векторов при помощи. Здесь а-а будет ли информация про то, как этот процесс оптимизируется? Владислав, чуть-чуть дальше посмотрим. Насколько помню, вставлял это в презенташку. Если нет, то, соответственно, можем продолжить общение, а, по тем опять же ссылкам, которые в начале указывал. Попробую найти интересующую вас информацию или спросить у коллег.

Итак, соответственно, ПГ- вектор и три основных метрики сравнения этих векторов. Давайте очень кратко посмотрим и попробуем понять, как они между собой работают. Первая метрика, которая используется чаще всего - это евклидовая метрика или L2. Представляет собою гипотенузную метрику двух векторов. По сути, у вас есть, соответственно, ваша, а, ваши две оси X и Y, да, векторное пространство. А дальше есть отдельный вектор, у которого есть свой соответствующий размер, длина этого вектора и какие-то конкретные тоже точки. И, соответственно, а с помощью такого метода, такого алгоритма высчитывается гипотенузная метрика двух векторов, измеряет величину расстояний между точками, в которых заканчиваются эти самые векторы. Соответственно, такие алгоритмы чаще всего оптимизированы хорошо и для хранения, и для использования в рамках субдшек, поэтому можно здесь их попробовать применить. Вылет это всё следующим образом. Рассчитывается по конкретной формуле. Сегодня мы всё-таки говорим про постгроссы и применение внутри него, не про математику. Поэтому кратко информацию и картиночку представил здесь. Мы можем представить его как объём пространства между двумя объектами. Как далеко ваш экран находится от вашего лица. Соответственно, единственное, нужно найти ту самую изначальную точку, от которой мы будем это всё дело рассчитывать. Формула расчёта и внешнее представление, как оно само по себе вылит.

Если мы говорим про косинусную схожесть, то это угол между длиниями в точке их пересечения, да? Здесь точно те же самые у нас векторы, королева и король, и между ними расчётный угол, про который мы и говорим. Здесь, а, используем такой термин для обозначения разницы между ориентациями двух векторов. Например, насколько нужно повернуться, чтобы оказаться лицом к входной дыре. То есть, насколько нужно, а, быть близким, чтобы совпадать с тем вектором, который у нас был и до этого собственно взят и проиндексирован. Здесь формула расчёта, как видите, существенная изменяется, но сама по себе сиilarриity, на которой мы можем обращаться, 0,28, здесь 003 тоже может, соответственно, отличаться в зависимости от выбранного а алгоритма. При этом алгоритм, как правило, выбирается один и тот же в рамках поиска, поэтому такие порядки величин нас тоже не смущают, если они сильно расходятся.

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

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

Виртуальную машину я развернул в формате Убунту, да, операци операционная система Убунту. Есть публичный опишничек и по ресурсам достаточно стандартные четыре ядра, 16 ГБ оперативной памяти и 100 ГБ диска. Аа такое соотношение, такого соотношения хватает для большинства и субдшек, для тестовых прогонов, и для различных инструментов типа того же Airflow, для переливки данных и так далее. Далее, соответственно, необходимо поднять постгрес. Вариантов его поднятия тоже достаточно много, но раз мы используем Убунту, то можно воспользоваться инструкцией, которая в целом была скопипащена из официальных, соответственно, инструкций самого конгресса. Здесь, а, немного информации собираю, в том числе для курсов и по кликхаузу, идифки есть специально для кликхауза, и постброса, решающие те или иные задачки. И есть вот такая вот сборная солянка, где всё представлено, в том числе и очень краткой инструкция по развёртуванию постгреса, если кто-то захочет с ним поработать и его попробовать.

После этого есть настройка, как развернуть позгрыз для того, чтобы у него появился внешний апишник и к нему можно было подцепиться. Открывается порт и делается подключение доступно на всех. Это, проговорювала достаточно страшная настройка, потому что при таких настройках и если вы не заложили какой-нибудь хоть маломальский пароль, к вашей базе данных могут постучать всякие разные процессы, которые сканируют стандартные порты. У Посгрса, наверное, один из самых стандартных узнаваемых портов 5432. И могут получить доступ через PSQL, через консольный клиент Постгреса к вашей Linux тачке. Поэтому, пожалуйста, будьте аккуратны. Такие настройки я предлагаю только, если вам нужно что-то быстро протестировать и при этом с установкой отдельного пароля и лучше со смены порта. Если нужно взять какие-нибудь базовые данные, то тоже можете с этим ознакомиться. Это базовый датасет с полётами Bookings, Flights, все вот подобного рода. Соответственно, развернули мы базово постгс и подключились к виртуальной машине. Развртывание при этом происходит через консоны клиент. Здесь в том числе как поднять эту машинку виртуально. Тоже информация есть. Буквально вот ровно этой команды. Единственное с другим названием я сегодня и воспользовался. Вот она у меня как раз меня и выкинула. В дальнейшем производим подключение к нашей виртуальной машине и начинаем, соответственно, нашу работу. Базово я также выложу отдельную ссылку, а в рамках презентажки, её дополню а вот этот тестовый проект, который был собран для нашей с вами сегодняшней работы. Соответственно, базово устанавливается постг. Мы можем посмотреть и проверить, что он у нас действительно присутствует. Достаточно стандартно вggs clusters. Единственное, главное на английском это написать. По-моему, даже без суда.

тоже работает. PGLS clusters. А наш кластер, да, одна нода, восемнадцатая версия под названием main со стандартным портом. Здесь я доступ наружу ему не открывал. Соответственно, устанавливается и дополнительно необходимо установить зависимости, которые нам нужны для того, чтобы установить сам PGвектор. То есть базово есть экстеншены, которые постг поставляет по умолчанию, да, вместе со своей сборкой, которую мы скачиваем там из отдельных репозиториев. И есть дополнительные, которые мы обязаны в том числе здесь включить и закачать.

Соответственно, эти настройки я уже выполнил на этой виртуальной машине. И дальше нам необходимо сделать сборку и установку ПГ-вектора из исходников. Для этого произведена скачка этого самого ПГ-вектора Gitклон внутрь, то есть Giton и этот репозиторий внутрь. Мы заходим PG вектор и видим всё содержимое этого самого репозитория. После этого у нас здесь есть отдельные make-файлы, которыми мы можем воспользоваться, которые выглядит достаточно непрозаично. Makefile указывается, что именно нужно просто сделать в рамках такого вот небольшого скриптика. И базовый, кстати, называется непг вектор объектор, а это расширение. И после этого sudo make install позволит нам установить нашу работу.

Дальше дополнительно в рамках скриптиков будет указана установка зависимостей для демоскриптов, для того же самого питона. А виртуальное окружение и, собственно, его открытие на всякий случай. Я, пожалуй, так и сделаю. source. А нет, в PG векторе source v bein activate позволит мне активировать виртуальное окружение. С какого-то времени питоновские библиотеки просто на сухую в виртуальную машину не ставится, требуется вот такое вот виртуальное окружение. Либо дополнительную библиотеку нужно для этого тоже поставить.

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

После того, как мы произвели базовую установку, да, можем ещё раз проверить статус самого постгреса. Видим то, что он действительно у нас работает уже там больше 3 часов, сам по себе развёрнут. И дополнительно рекомендуется настроить автозапуск позроса в случае отключения или включения машины виртуальной машины. Systeml enable postg sc прямо как стихи получается.

Дальше, соответственно, мы работаем над уже созданием самой базы данных Create Database и обязательно задаём пароль для вашего постгреса для подключения. Обычно это команда alter user, погрово и название вашего нового пароля, да? И таким образом мы себе немножко обезопашиваем. Для того, чтобы войти внутрь, как вы себе уже знаете, нужно sudo minus sudo postgres PSQL. И мы попадаем к нам, а, уже внутрь контекста.

Для наших с вами действий было была развёрнута вебинар DB, просто созданный create database, и в неё нам, соответственно, нужно перейти. Все остальные базы данных являются базами данных по умолчанию для постгреса. Это postgres, template 0 и template 1. Teamplate 0 самая базовая шаблон. Teamlate 1 на основе teamlate 0 создано, а postgres, соответственно, это первая условно пользовательская, которая у нас есть в рамках нашего кластера.

Соответственно, мы переходим в базу данных вебинар DB, переключаемся, и здесь необходимо создать тот самый extension. Extension, напоминаю, действует только в рамках той или иной СУD. Соответственно, здесь, если мы посмотрим PG extension вектор, увидим отдельная тоже версия, айдишник уже назначенный и название, как мы видим, это вектор. Если мы вернём на уровень базы данных Могс и запи запустим тот же самый наш запрос, то, соответственно, мы ничего не увидим. Это стандартное применение нашего процесса.

Соответственно, для того, чтобы мы могли с вами поработать, была создана дополнительная таблица, которая называется таблица articles. А вот она. Вот так она выглядит. С помощью метакоманд мы можем на её структуру посмотреть. Хотя, наверное, всё же будет интереснее вот так на неё взглянуть. Это таблица, которая имеет некоторые idшник. Один на serial primary key, title, text, body, то есть, по сути такая таблица статей, основная демо таблиц. И, соответственно, дополнительно мы используем сразу для полнотекстового поиска такой так называемый tвектор и, соответственно, функции, которые здесь по умолчанию включены. Для полнотекстового поиска ничего дополнительно делать не нужно. всего оказывается по умолчи.

Векторное представление - это бединг и отдельный тип данных, который приходит к нам вместе с нашим экстеншном. И есть отдельные его измерение, расширение, называйте как, соответственно, правильно, как хотите. И, соответственно, createed для того, чтобы на эту информацию как-то можно было дополнительно закладываться. Соответственно, в зависимости от той или иной выбранной модели у нас может меняться измерение. То есть, условно, если модель, как она называется здесь, all mini LM L6V2, то это 384. Если это Openвская embeding 3 small, то это 1536. И, соответственно, для примера RCK системы мы создали таблицу вот такого рода Create Table, да, и с ней в том числе можем посмотреть, поработать. Здесь вышли из этого бесконечного круга. В общем, сами данные исходно произвели с ними создали.

Дальше, соответственно, нам нужна вспомогательная функция, так называемый randм вектор, который генерирует вектор случайной, а случайный вектор нужной размерности. Создаёт она её достаточно просто с помощью вот такой вот функции для того, чтобы мы могли её дальше запихнуть в рамках наших инсертов и наполнить тем самым исходные данные. Данные напоминают title, body и embeding. Сам по себе генерируется вектор, тем самым назначается к нашим исходным данным, к заголовку и небольшому тексту, который внутри содержится. Генерируется с помощью вот этой вот встроенной функции дефки, можно так сказать, которую мы самостоятельно указали и написали. Здесь эта функция у нас уже создана, ничего дополнительно делать не нужно. вставляется информация и в articles сразу в статейке и в наш нашу вторую таблицу. Вылет - это соответственно вот таким вот следующим образом. ID, title, body preview. И то же самое ID question категория здесь, соответственно, также представлен. Нужно опять же, как для демо, которые мы с вами тоже сейчас чуть-чуть позже и посмотрим.

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

Соответственно, допустим, найдём три статьи, наиболее похожи на статью с айдишником единиц. В таком случае запрос будет выли следующим образом. Соответственно, применяем те самые поиски расстояний, да, те самые косинусные расстояния и косинусные исходства с с использованием особых вот таких вот операторов, которые для каждого из наших типов здесь мы с вами и указывали, да, косинус на расстоянии. При этом в зависимости от оператора то самое расстояние и будет использоваться. Мы выбираем эмбединги, делаем соответствующее соединение и выполняем соответствующий здесь вопрос. И, соответственно, выводим информацию из articles и высчитываем информацию и косинусное исходство. Делаем это достаточно быстро. Можно даже дополнительно включить такой вот model тайминг. Понятное дело, то, что у нас данных здесь практически нет, но и постгрус тоже не промышленных масштабах. видим, посчиталось это всё супер-пупер быстро. При этом, при этом это пока мы всё делаем без дополнительных индексов, да, без работы с хинтами, чтобы эти индексы в том числе включить. На таких небольших скоростях, небольших объёмах данных, когда скорости достаточно высокие и время подсчёта, мы можем для чистоты эксперимента поставить дополнительный сет как такие условные хинты. В Постгсе они таковыми не называются, но все понимают, о чём мы, соответственно, говорим.

Можем, соответственно, поиграться с другим способом. И если мы работаем с косинусным сходством, вернуть только те статьи, у которых косинусное сходство будет больше, чем 0,7. Соответственно, здесь на текущий момент таковых нету. Здесь мы можем немножко тоже поиграть. Давайте поставим косинусное сходство чуть-чуть поменьше, например, там какое-нибудь 0,4. И вот они, соответственно, и будут у нас тоже представлены. Поэтому опять же необходимые операторы, с которым мы работаем, здесь есть. чтобы продемонстрировать варианты с евклидовым расстоянием. Тоже отдельный запрос, просто отдельный также поиск этого эмбединга из внутренних, соответственно, статеек. Ищем то самое расстояние Евклийдовое и получаем соответствующие тоже, а, статейки, а, с указанием определённого вот того самого значения, которое мы искали. Так, есть Inner product, тоже как пример, тоже как подтверждение того, что он отдельно работает. Здесь, соответственно, для нормализованных векторов это всё, для нормализованных векторов это всё также принимается, применяется. И можно дополнительно управлять качеством поиска через так называемые прос, но это нужно тогда, когда у нас есть с вами индексы. С индексами мы пока с вами опять же не работали. X не смотрели.

Это что касаемо именно векторного поиска. Дальше поговорим про гибридный поиск. Но, пожалуй, давайте я на секунду здесь остановлюсь на один слайде с вопросом. Понятно ли, как поставить постгроз, как поставить ПГ в вектор, как его, соответственно, запустить, что из создания экстеншена и через какие операторы, что у нас здесь происходит. Так. Часть вопросов буду зачитывать. А делаю проект постави себе а такой-то. Это автономный сервис аренды с локальным ИИ и платёжной системой. Используют классическую постгруз для внедрения умного поиска по смыслу использую ПГВЕК. Стоит ли переходить на специализированный или возможности будет достаточно с ПГра? очень сильно зависит а от объёмов данных, с которыми вы работаете. Как правило, вектор на базово ой вектор и, соответственно, постгреса для базовых задач, я думаю, более чем хватит вполне с головой. Дальше уже можно смотреть на специализированные варианты, если не будет хватать производительности. Особенно, если, учитывая, что, Григорий, вы спрашиваете про докер. А опять же, докер - это как отдельная дополнительная прослойка между нашей операционной системой и приложением, которое мы в докер устанавливаем. То есть отдельная система контейнеризации. Почему бы не поставить напрямую на ноду? Тем более, что достаточно просто это делается через буквально пару клинков. А так, Андрей, потому что эта часть урока есть и менеджет облакав вообще просто пару кнопок будет тогда. Да, да, соглашусь. Причём многие облака такое представляют. Действительно, просто пару кнопок для дополнительной установки и больше ничего не требуется. Самый простой вариант. Действительно, насколько векторная база тяжёлая? Можно ли её разворачивать на локальной машине, если требуется поиск по векторам по схожести? Но количество единиц для БД в пределах 500 Мб. А интересуюсь для организации сетов для локальной легковестной генеративной нейросети. В целом поставьте Постгрос, его можно хоть на Андроиде развернуть и попробуйте с него. Здесь Позгрос имеет огромное просто преимущество за счёт того, что эта база данных более чем знакома, мне кажется, наверное, самая знакомая, по крайней мере, на нашем с вами рынке для тех, кто с базами данных в целом работал. Поэтому, я думаю, её будет достаточно. Добавляете векторы, добавляйте данные и пробуйте. Тем более на таких небольших объёмах данных, я думаю, вполне должно быть. Опять же, есть статейка, 100% можно найти, где постгр разворачивали на Андроиде, на телефоне. Так, может, лучше взять Так, Григорию, указывайте. Здесь можно и такую. В рамках урока мы показываем, что можно выбрать ту, которая нам здесь будет более привлекательная. Дальше, соответственно, выбирать в зависимости от Так, запись урока будет. Да, да, да, запись урока вместе с материалами будет отправлена вам по имейлу, с которого вы, соответственно, регистрировались. Ну а опять же есть отдельная группа ВКонтакте, где можно эту информацию будет дополнительно, соответственно, взять и посмотреть, поискать. Она вот тут чуть-чуть выше указывается. Давайте на всякий случай эту группу тоже продублирую на её на неё ссылочку, чтобы никто, соответственно, её и не потерял. Вот так на всякий случай. А расстояние мы вычисляем только на таблице articles. Таблицы мы используем сейчас в примерах. Нет, не используем. Мы её просто представили как один из артикл - это основная. Сейчас таблица. Таблицу вторую. Не хочу её произносить. почему-то сам выбрал такое название, сам этот жили frequency asked questions. Мы будем, э, использовать в рамках рак пример. А, напримеры были похожи на уже сохранённые данные. Можно ли так делать какими-то с новыми данными или соединениями на другие BD аа таблички? Да, да, да, вполне, вполне можно. при соединении. Единственное, вот всё то, что вы будете делать при соединении без материализации, учитывайте то, что у вас будет, соответственно, больше работы на ЦПУ и рам в целом. А поскольку я вот больше работаю в ап сфере и там очень много данных у нас крутится, я всё чаще странюсь именно не стронюсь, а являюсь сторонником, наоборот, совсем а материализации и возможности прихранить чего-нибудь на уровне с УПД до того, как мы произведём какое-то вычисление. всякие вычисления, которые включают в себя вьюшку на вьюшку, на вьюшку и так там 15-20 штук. Мне кажется, что это может нашу СУБД немножко положить. Хотя как можно положить БД немножко одну надо вывести из троя.

Так, соответственно, вопросов вроде больше нету. Есть только вот специфичные вопросы. а, которые я, пожалуй, себе сохраню и дополнительно а укажу. Давайте вот в том же репозитории, соответственно, вам будут отправлены материалы, будет запись, я просто найду эту запись в ВКонтакте и внизу приложу репозиторий, куда я выложу ответы на ваши вопросы, часть из которых, к сожалению, я на текущий момент не могу прокомментировать. И в том числе материалы, которые использовались для демо. который сейчас показываю. Какой инструмент для ала вы используете? Клихаус. В основном это клихаус. На текущий момент этого хватает со своими нюансами. А так небольшое уточнение ПГ вектора взял для изучения рак. Объём данных четыре квартиры. Стоит ли переходить на специализированный вектор на базы данных? А попробуйте сначала на постгресе. Если будет не хватать, переходите на специализирование. Давайте так, поскольку опять же легче будет сильно в постгресе разобраться, его поставить, его подключить тем же самым докером, как вы и указывали. Так, о'кей. Спасибо большое за очень активную активность. Давайте, соответственно, двигаться дальше.

Итак, поговорили в двух словах про векторный пояс. посмотрели, как его можно реализовать с помощью ПГ-вектора на уровне уже работающего условного постгруса. Полнотекстовый поиск, который здесь дополнительно применяется, да, или просто поиск текст текста, как он указывается в рамках документа самого постгруса, возможность находить документы на естественном языке, соответствующие запросу и дополнительно сортировать их по релевантности для этого запроса. Наиболее распространённа задача найти все документы, содержащие слова запроса. То есть мы идём по сути искать по конкретным ключевым словам необходимую нам информацию. После этого вывести их дополнительно отсортированными по степени соответствия этому самому запросу. При этом чаще всего перед этими операциями происходят дополнительные пред фильтрации, агрегации и прочие подобного рода вот действия для того, чтобы уменьшить объём обрабатыва информации, который мы подаём на такие специализированные алгоритмы. Соответственно, в простом случае считается набор слов, а, соответственно, определяется частотой слов в том самом документе. Здесь также дополнительные операции, которые мы можем использовать операторы, существуют уже очень-очень многие годы. Это и стандартные like, и I like. Давайте я у вас тоже спрошу, I like. Чем от лайк отличается? Кто в курсе, кто знает? И вот такие вот специализированные тильды, тильды со звёздочкой и функции, которые работают через те же самые векторы. Тут to s вектор, а, который мы с вами увидели. Регистр зависимости. Регистр зависимость. Да. Да, абсолютно верно. То есть мы считаем то, что колонка I like какое-то, соответственно, слово, то, что лежит у нас в колонке, мы приводим к одному, соответственно, как правило, нижнему регистру. По крайней мере, в Клихаузе так это реализовано. А для того, чтобы производить, не думать о том, в каком, какие буквы, где как там расположены и не применять какие-нибудь дополнительные функции типа ловера, апора и прочего, да. При этом сами ребята из постго в документаке пишут то, что есть вещи, которых очень не хватает, э, которые нужны для реализации наших с вами задач в рамках информационных систем. нет поддержки лингвистической функциональности, не позволяет упорядочивать результаты поиска по релевантности и выполняется медленно из-за отсутствия индексов. Но здесь мы опять же решаем эту задачу комбинированную таким подходом. Соответственно, задача информационного поиска решается двумя способами. Сначала через совпадение слов, затем через близость смыслов. Можно, соответственно, либо одно, либо второе использовать, можно комбинировать. Отсюда и появляется этот самый гибридный поиск. о котором, кстати, на русскоязычном интернете достаточно мало, к сожалению, информации. Полнотекстовый постгрес поддерживает через TS Vectктори TS с SQU. Поддерживал уже прямо 300 лет. На самом деле я вот то время, когда Постгрес их поддерживал и все рассматривали индексы Постгреса, как есть B3 и всё остальное, что я никогда использовать не буду, он пережил и по сути сейчас очень активно применяется для подобного рода задачек. Также там есть всякие функции, которые работают со временем дополнительно, да, работают с геоданными и так далее. Соответственно, на практике наилучшие результаты часто достигаются при комбинировании полнотекстого и векторного поиска. Здесь вот статейку не указал, но это опять же отдельная ссылка на неё, которую вы сможете увидеть в самом конце. полнотекстовые работы для точных терминов, чисел и имён собственных, что, кстати, достаточно важно. Векторный позволяет находить сематически похожие документы даже при различных формулировке запросов. Здесь индексация полнотекстов заключается в предварительной обработке документов и сохранение индекса для последующего быстрого поиска. При этом помним то, что индексы в постгресе - это не панацея и не решение всего и вся. Их нужно использовать и указывать сумом. Базовый у вас будет всегда индекс бетришный. После этого вам нужно будет указывать определённый алгоритм, который для того или иного индекса будет, соответственно, примениться. Давайте, соответственно, попробуем создадим. А, поговорим или или нет, буквально на секунду, дате прикину. Это примеры. Это примеры. Я себе выделил 06 07 1 секунду. Гибридный поиск. Да, дадада. Давайте его сделаем. Гибридный поиск. И будет небольшой такой рак запрос тоже для примера. А дальше, соответственно, почему я, собственно, остановился. Краткая информация по курсу и специальные индексы в двух словах представленые, которые мы попробуем применить на нашем небольшом объёме данных и попробуем заставить Постгс их опять же использовать. Поскольку Постг сам по себе не дурак. Если он считает то, что sequential сканы будут быстрее идти, он их и выполнит. Даже если мы ему явно указали, что sequencial с scan ты выключаешь, если он не находит других вариантов, он его как раз и будет использоваться. Соответственно, давайте посмотрим. Соответственно, гибридный поиск плюс включающий векторный плюс полнотекстовый через TS- вектор. Допустим, только полнотекствый поиск. ищем в рамках наших статей с помощью дополнительных функций по умолчанию, доступных в рамках нашего постгреса, и указываем, что внутрь у нас входит, и добавляем соответствующие здесь условия. Вот эти операторы также принадлежат тому самому полнотекстому поиску. Соответственно, ищем те статейки, которые совпадают в зависимости от указанных нами, а, ключевых слов, ключевых функций. Можно, соответственно, здесь тайм у нас вывелся. Можно посмотреть векторный поиск лям соответствующего сравнения. Давайте попробуем. Выведем. Отработал. Быстрее, результаты, соответственно, другие. Но как их, соответственно, можно здесь в зависимости от применить? То есть мы можем и полнотекстовый использовать, и отдельновекторный поиск. И есть, соответственно, дополнительный гибридный поиск, который можно указывать с так называемым векторным ранжированием. Давайте попробуем его запустить. Будет вот такой вот достаточно большой запросик. Вот так вот страшно выглядящий. Давайте посмотрим. Ой, действительно, страшный запрос. Ну-ка ещё раз. Да. Что здесь делается? Соответственно, здесь включается сам вектор из пользовательского запроса. Здесь берём вектор статьи об индексах. Просто отдельно конкретный конкретно взятый. Здесь высчитываем по соответствующему векторному поиску и высчитываем по полнотекстовому fullтекст. После этого применяем ко вариант, делаем join с предыдущими ЦТЕками и, соответственно, выводим соответствующий результат в зависимости от указанных нами предыдущих вариантов. То есть мы и отдельно посчитали векторный и полнотекстовый на исходных данных, которые здесь взяли и выбрали, и сделали комбайнд и посмотрели на соответствующие тоже скорости. Ну, скорости не совсем верно, но соответствующие тоже результаты. При этом, при этом есть здесь отдельный тоже оператор, который позволяет нам смотреть, как именно указывать эту взвешенную сумму или альфа, как здесь это у меня в рамках запроса указывается. Здесь вот здесь она и применяется. То есть указывается, если мы укажем альфа на единицу для векторного, то в гибридном поиске мы полностью будем использовать полнотекстовый поиск для гибридскор. Если нолик не так, первая величина единица, значит только векторный. Первая величина, соответственно, ноль, то только полнотекстовый. И точно также можно указывать 0,7 03 как такое вот отдельное совпадение. А для того, чтобы принимать отдельное тоже решение по нашим поиску. И есть гибридный поиск с обязательным полнотекстовым условием. То есть здесь стратегия, как мы с вами говорили, сначала фильтруются наши данные по ключевым словам, после этого аранжируются по вектору. Такие примеры хорошо работают на больших датасетах. То есть видим, у нас опять же исходный вектор, который мог бы быть пользовательским, да, здесь здесь могла бы быть ваша реклама. И дальше сначала мы, соответственно, включаем обязательный фильтр через полнотекстовый поиск и производим, собственно, ранжирование. Тем самым подключаем тот самый гибридный поиск, как мы и говорим. и дополнительный или давайте, наверное, сейчас на паузу поставим, всё ли на этой части понятно. И сделаем такой небольшой пример с RК, да, retrieval augmented generation generation. Поиск контекста для лмки. Почему именно 0,7 и 03? Просто взяли для примера, чтобы выделить большую значимость векторного поиска, чем полный текст. Как получить вектор из строки какой-то функции? Вектор генерируется, как правило, до постгреса и обработка идёт до постгреса и складывается просто в отдельный тип данных вектор. Сам по себе постгрес, насколько помню, может, а мы можем написать дефку, которая будет высчитывать тот самый имбединг, но, как правило, мы оставляем это питон. Так. А, Григорий, по вашему вопросу, правильно ли я понимаю, что при проектировании рак системы здесь важно соблюсти баланс между недостаточностью данных и избытком, да? То есть, когда наши модели уже начинает галлюционировать, а, ввиду, а, переобучения, не уверен, что это до конца может относиться к вашему вопросу, но есть определённые тоже алгоритмы, которые высчитывают вот тот коэффициент переобучения, на котором надо останавливать процесс и делать что-то по-другому. Не совсем понятно, гибридный поиск быстрее, полнотексто или медленнее. Возможно, на этих примерах не до конца понятно, а здесь, наверное, просто нам недостаточно данных, чтобы это прямо наглядно показать. Но по факту векторы они используются чаще. Полнотекстовые помогают в случае, если большие объёмы данных и нужно сделать более легковесную операцию до того, как приступить к векторному поиску. То есть логика примерно такая.

Так. Давайте тогда продолжим, если больше вопросов нету. Напоминаю паттерн рак. Сначала пользователь задаёт вопрос, потом вопрос кодируется вектор. Постг возвращает n релевантных фрагментов и фрагменты плюс вопрос передаются уже в лмку. А лмка даёт ответ на основе контекста. Собственно, для этого мы и можем использовать постгс прямо вживую, когда у нас есть отдельная модель. И мы по сути с исходными данными плюс с тем, что возвращает наша СУБДшка на тех данных, которые есть внутри, возвращаем результат в LRM. Соответственно, для нашего примера как раз тот самый frequently asked questions, таблица с буквой F, давайте так её буду называть. А запрос получить контекст из этой таблицы по вопросу пользователя. То есть, допустим, мы выбираем здесь вопрос. этот вопрос, как выбрать индекс для ПГ вектора и имитируем его вектор второй записи в, да, по сути, это вектор второй записи в нашей таблице. Соответственно, делаем поиск, указывается отдельный вектор вопроса и порог релевантности, который мы также высчитываем с помощью оператора, включённого в наш пк-вектор. То есть выбираем сам вопрос условно, который нам был задан. Здесь на самом деле будут наши исходные данные, а, от пользователя и получаем соответствующий здесь тоже результат и relevance. Изначально у нас был вопрос, а как выбрать индекс для PGвектора? Собственно, здесь у нас и прошло совпадение индекс и вот здесь вот тот самый PG вектор по тем статьям, которые мы, а, по тем вопросам, которые мы здесь, соответственно, выводили с указанием тоже порога релевантности. Здесь прямо единичку совпали, здесь больше 0,5, соответственно, и увидели. Второй вариант, когда рак у нас есть с метод данными, то есть фильтрация по категории плюс векторный поиск. Вопрос следующего вида. Также включаем проверку на релевантность и дополнительно указываем прифильтры по метод данным. Часто такое тоже может быть, когда без каких-то замудрённых функций у нас просто попадает отдельная категория. с указанием фильтра. В таком случае тоже видим результат и релеранс, который здесь указывается в рамках нашего с вами запроса. И тот самый финальный вопрос, который мы можем рак запрос, который мы можем выдать уже в контекстеламки. Соответственно, давайте его тоже здесь выведу. Вот таким вот образом он выглядит. Первая ЦТЕК - это user query vector. Здесь приходит это из приложения, тоже можно посмотреть их генерировать. А, тоже второй по-прежнему используем. И, соответственно, ищем наши, э, отдельные документы, которые могут быть релевантны по тому или иному запросу. В общем, подготавливаем также 11ешку. И после этого собирается контекст в одну строку для передачи в лмки. Делаем это тоже с помощью встроенных в постгрес функций. А, прямо в рамках одной такой вот операции, не вытаскивая эту информацию напрямую в какой-нибудь Python. Делаем это на уровне субдшки, чтобы облегчить последнюю ему.

жизнь. И получаем соответствующий здесь контекст. То есть у нас указан вопрос. Сюда подставили этот вопрос, тот самый пользовательский. После этого указывается ответ, тоже он подставляется и выводится, соответственно, несколько таких вот вариантов с дополнительными вот такими вот условными разделителями, как мы по сути здесь и сказали. Вопрос, подстановка, ответ, подстановка переноса строки и уже соответствующая, а, соответствующий отдельный контекст, который мы собрали. Опять же, кроме постгреса ничего не использовалось. Даже то, что я вам показал виртуальное окружение Pйthon дополнительные эти библиотеки мы с вами не использовали. Даже в рамках базовой генерации всё это сделали базовой встроенной функцией.

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

А-а, а какую цель вы, соответственно, хотите достичь? Вы хотите дать исходному пользователю, который отправил запрос вариативность в выборе а ответа для того, чтобы затем проконтролировать про введение модельки или как? То есть в целом и лэмки позволяют делать, и там какой вариант вам больше нравится, как они часто предлагают. Я из таких выбираю говорить не сразу прямо то, что мне нужно без вот эти вариативности. Может быть, я нетерпелив, если правильно. Опять же сейчас понял ваш вопрос. Неточность в том, что пользователь получает не ответ, он получает контекст. На осном контекста плюс запрос лм строит ответ. Да, Владислав, соглашусь с вами. Спасибо большое за полезный комментарий. О'кей. Хорошо. Это та часть, которая нас касается вводной составляющей. То есть здесь мы с вами проговорили, хотя ничего себе, вводная составляющая уже больше час. А информация, которая касается именно возможности ПГ-ктора в рамках нашего подкуса.

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

Итак, а, небольшой перерыв на информацию о нашем курсе, который я представляю. А, открыт урок курса администрирование постгли. Экспертный уровень. Давайте попробуем на него перейти и его посмотреть, что же здесь составляется. О, кому нужно. А с 5 по 30 апреля за прохождение теста по любому курсу в течение 2ву часов. Не знаю с какого момента она началась, но здесь она в том числе также указано. Соответственно, здесь вы попадаете на лендинг нашего курса, на котором можно, а, познакомиться с его содержанием. Курс продвинутый версии Постгроса. Есть постгрес для ДБА архитекторов, есть администрирование постгса, экспертный уровень. Курс рассчитан на 4 часа и подходит для таких-то специалистов и указывает необходимые знания, в том числе и навыки. А расписание занятий - это вторыг, пятницу в 8:00 вечера. Сами вебинары проходят в том же формате, что и сейчас, только у вас там есть право голоса. То есть вы можете а включать микрофон и задавать вопросы голосом. мы можем с вами дискутировать такой формат мне, разумеется, нравится больше, потому что более живое получается общение споры, нахождение истины во многих водах. Соответственно, курс длится 4 месяца, начинается 28 апреля, проходит онлайн в формате вебинаров два раза в неделю, как правило, стараемся без переносов, э, после назначения базового, соответственно, календаря. Здесь кратко про процесс обучения, про то, что вам даст этот курс. Больше я бы хотел, наверное, сакцентировать внимание на программе. Здесь стараемся, как и во многих других курсах, проходить таким достаточно большим сквозным кейсом от каких-то базовых, но уже базово продвинутых вещей на уровне постгруса до, соответственно, постгли больших данных. То есть рассматривается на курсе и вводной составляющий про настройку, поднятия, репликации, бэкопирования, всякие мониторинги, визуализации и прочее. Дальше, соответственно, позгроз в облаках, который сейчас всё ещё набирает обороты и даже не не набирает обороты, а очень часто активно используются. возможности настройки постгруса в кубере с использованием терафома ансибла. Что, соответственно, делать, если вы хотите понять его в том или ином облаке? Как раз, чтобы натыкать на те кнопочки и не думать о том, как разворачивать с помощью каких-либо скриптов. Рассматриваются основные облачные провайдеры, самые, наверное, популярные и крупные. После этого, соответственно, приступаем к модулю, в котором я чаще всего покрываю все лекции. Может быть, кроме последней. Это работа с постгресом большими данными, работа в кубере, развёртывание через операторы, хильмчарты. А сра сравнение постгреса ванильного с теми инструментами, которые больше ориентированы на работу с большими данными с точки зрения алапа, как роучи, сайтусы, югобайты, всякие гринпламы, грингейджи, что у нас там есть, cloudberry, всё остальное. То есть умеренно по соответственно объёму, по количеству различных инструментов, чтобы всё равно была ясность. Но рассматриваем то, как Постгрес в какой-то момент свернул, не сказать, что не туда, в немножко не даже не второстепенную, а в другую основную ветвь, когда мы сидели, думали с вами, чего делать, нравится постг, но он больше для OLTP, как бы пойти в сторону аналитики. Соответственно, вот в эту часть большие данные, в отказоустойчивость здесь также будем говорить. И также отдельный модуль проектной работы. В рамках курса выдаются отдельные домашки, которые, а, соответственно, отвечают на те вопросы, которые вы в рамках лекции тоже обговорили. Просто дублируете и дополнительно изучаете тот материал, который нужен для их выполнения. Проектная работа по своей сути включают большую-большую работу, которая подразумевает аккумуляцию всего опыта и знаний, которые вы получили в рамках курса. выбирается отдельная тема и в течение месяца, чуть больше, чуть меньше, а, происходит, соответственно, подготовка вашего, конечно, проекта, по сути, наработка портфолио и, соответственно, защита. Преподаватели здесь представлены. А кто является руководителем курса? А, Виктор. Есть также информация также кратко и обо мне. Нужно, кстати, обновить везде три три разных названия одной и той же должности и другие. Здесь можно с этой информацией дополнительно ознакомиться и посмотреть. Сегодня наши, соответственно, мероприятия. Дальше также можно увидеть прошедшие мероприятия и на них перейти, чтобы их также посмотреть и познакомиться с теми преподавателями, которые будут, э, с вами дискутировать в рамках курса. выдаётся, соответственно, сертификат, указана цена и те самые частые вопросы, которые нам можно в целом занести во вторую табличку и с ними тоже поработать. Это то, что касается лендинга и нашего курса в целом. Здесь на курсе не разбираются вещи касательно иишки. А, кстати, интересно, хорошо это или плохо, коллеги? Минусик давайте плохо, что не разбираются. Плюсик хорошо. Хотели бы вы, чтобы сюда эти материалы были включены? Так, отлично, отлично, вижу. Может быть, даже что-нибудь получится придумать, но вряд ли в ближайшее время можно ознакомить с отзывами. Остальные куда-то делись, их было значительно больше. Сертификат, цена, собственно, частый вопрос. Так, понял, увидел. Спасибо большое. Все поставили минусики. Соответственно, действительно имеет смысл чего-нибудь с этим сделать, да? О'кей. Спасибо. Я думаю, и я, и коллеги, которые у нас на вебинаре тоже присутствуют из Отуса, подхватим эту информацию. Это что касаемо курса. Значит, программа преподавателя обучения. Вот здесь остановлюсь кратко, чтобы вы тоже могли посмотреть, прочитать и вернусь к к нашему тоже обсуждению.

Пользователь спросил: "Вот условия аренды, бот выдал данные из базы, что нашёл в документах. По-другому не могу объяснить". Здесь вот Владислав, задача рак: обогатить запрос пользователя. Запрос пользователя: "Покажи среднее условия аренды." Рак вместе к этому запросу добавляет текст топ nн от 10 до 50 договоров. Далее запрос пользователя вместо с место вместе с текстом этих договоров идёт в МЛМ создаёт ответ. Так, ответ получает несколько вариантов. Правильно ли я понимаю, что не слет ограничивать выдачу только одним наиболее релевантным фрагмента? Наверное, давайте я Григорию отвечу, что да, можно выдавать несколько вариантов. Здесь вот Владислав тоже постарался ответить, а, добавить, наверное, информацию, насколько я понял, к вашему вопросу. А вот, наверное, стоит попробовать вот эти несколько вариантов. Честно, аа давайте честно признаюсь, то что не до конца всё-таки, а мне кажется, что я могу ответить на этот вопрос, по крайней мере, на сейчас то ли до конца не погружён в это, то ли что. К сожалению, прошу извинить. То есть вы достаточно много уточнения сделали, чтобы я понял, но я, к сожалению, видимо, в четверг вечером слегка перегрузился. Давайте я тоже я попробую скачать этот чат. Его же можно скачать в настройке чата. В общем, перед завершением разберусь, как скачать информацию, чтобы все ответы у вас были. Извините, что сейчас не получается.

Значит, информация о курсе, QR-кодик и по сути, да, QR-код на тот же самый лендинг. Здесь, как коллеги рекомендуют, я добавлю ссылочку на опрос. Те, кому надоело меня слушать, можете опрос заполнить и, собственно, всё. А остальные давайте, у нас осталось ещё немножко времени, 15 минуточек, в которые давайте попробуем уложить информацию по спецндексам, которые здесь у нас есть. Как правило, если посмотреть на какие-нибудь источники, два спецндекса выделяются, которые можно здесь применять в зависимости от условий. информацию о них можно в целом укладывать один индекс, один большой вебинар. Опять же при подготовке смотрел, сколько по ним всего, а, всякого разного описано. Давайте попробуем кратко понять, чем они могут помочь, и попробуем их активировать в рамках нашего постгресуния, которое мы с вами сегодня используем. Соответственно, векторные индексы, если более человеческий пример придумывать, у меня часто библиотека здесь идёт, это библиотекари в мире векторных баз данных создают некоторую дополнительную систему для группировки и классификации точек данных, что позволяет гораздо быстрее находить то, что вам нужно. Но, как мы уже говорили, взяли данные, их как-то размапили, разметили, проиндексировали и в дальнейшем существенно быстрее находим уже полученную нами информацию. В целом на уровне больших данных, чем лучше мы информацию преподготовили, тем лучше она у нас в дальнейшем нам служит, условно, то есть отбросили ненужное, проиндексировали нужное, отсортировали по ключевым словам, чтобы в дальнейшем при поисках, при условиях V у нас большие чанки отваливались и так далее. Соответственно, индексы в обычной базе данных помогают быстро найти конкретное значение в столб. Векторные помогают найти ближайших соседей к заданной точке многомерном пространстве. То есть наши алгоритмы отчасти запихивают те же самые индексы, создают, соответственно, ярлыки, группируют песни по их характеристикам, а-а, да, в зависимости от контекста, при поиске похожих песен. Делает поиск по схожести молниеносным, даже при наличии миллионов элементов. Попробуем, давайте это посмотреть. Два варианта. Первый вариант, а, популярная техника индексирования на основе квантования, используемый для эффективного поиска ближайших соседей. Здесь строится отдельное, а, векторное пространство для больших наборов данных. Ключевая идея заключается в использовании векторного квантования для группировки векторов в кластера. Здесь очень рекомендую отдельно посмотреть, чтобы лучше понять, чего на самом деле происходит. По сути, принцип работы здесь вот представлен вот тут. Соответственно, разбира разбирает все векторы на кластеры, каждый, который имеет отдельно свой центр. У них даже такие прямо красивенькие есть всякие разные рисуночки. Как это всё работает? Вот на отдельной статье, которую я прикрепил, отдельные кластера, каждый имеет свои центры. Потом находятся векторы, которые, э, близки к нашим исходным центрам. И происходят дополнительные операции, где мы как раз и получаем уже исходные наши значения. При поиске сначала находят центры кластеров, наиболее близкие к вашему запросу, затем ищутся наиболее близкие векторы внутри этих кластеров. То есть разметить, разбить на кластера, найти центр. Ищем точки, близкие к этому центру. Если нашли, значит, они находятся в рамках этого кластера. И выбираем два конкретных из них для дальнейшего поиска. Если прямо очень кратко. Как это, соответственно, выглядит, если в двух словах, в двух словах, в трёх картинках, как здесь у нас и представлено.

Для рак подойдёт модель гигачата или слишком тяжёлая? А я не уверен, что с точки зрения точности нужно смотреть, насколько гигачатовская моделька хорошая. Среди российских, я думаю, она точно будет одна из лучших, если не лучшая. А я бы использовал, наверное, более популярные пенсорсно легковесные модельки. Сначала начать с легковесных и посмотреть на результат. Может быть, гигачатовское вам и не понадобится. Хотя, насколько я знаю, ребята из Сбера очень хорошо развивают это всё направление, расширяют его и в том числе open sourceт. Поэтому вряд ли бы, наверное, они openсорсили что-то, что плохо работало бы, сильно плохо работало. по той или иной задачке, но мне кажется, всё равно она слегка тяжеловатая, тем более для Григорию вашего запроса будет.

И второй тип векто второй тип индекса. Метод индексирования на основе графов разработан для эффективного приближённого поиска ближайших соседей. Стандартный тот алгоритм. В целом вот такие буковки возьмите, подставьте к любую популярностью СБД, типа постгреса, там какого-нибудь кликхауза и найдёте то, что они либо реализуют, а что они и реализуют те самые а алгоритмы похожести, которые мы с вами смотрели, два, три, дополнительные и так далее. Либо, а, соответственно, предлагает тоже специфичные индексы или или и в том числе здесь напоминает список пропусков, поскольку организует векторы в несколько слоёв, где каждый имеет всё меньше узлов, что позволяет эффективно перемещаться по слоям при поиске. То есть вот он наш векторный поиск. Ищем по отдельным слоям и пробуем, соответственно, найти совпадение с ближайшим нашим вектором. Работает как многоуровневая карта. сначала создаёт граф, которым каждая точка соединяется со своими ближайшими соседями. Потом несколько уровней этого графа строится и при поиске начинает с верхнего уровня и быстро сужает поиск до нужной области. То есть через определённый здесь э тот самый граф и идёт была карта мира, страны, города, когда мы увеличивали тот самый масштаб в зумелении, так скажем. Соответственно, давайте попробуем на наших запросах проделать то же самое, но создавая индексы. Соответственно, базовы, как я уже сказал, индексы у нас создаются с помощью просто createс. Если есть primary key, то он создаст на него первичный индекс типа B3, да? А для сравнения из того, что говорят, первый вариант тот, который EVFT, он быстрый, экономичный, чуть менее точный. Второй быстрее при запросах точнее, но при этом требует сильно больше памяти. Пожалуйста, обращайте внимание на то, какие индексы вы создаёте и как сильно они, соответственно, у вас, э, отжирают ту самую память. Создаётся он следующим образом. указывается название, указывается сущность, указывается алгоритм. И, насколько я помню, этот вектор, кстати, это даже интересно, но сейчас быстро не проверим. Насколько помню, эти типы тоже подгружаются певектором, но это не факт. При этом, а, коллеги, наверняка понимаете, знаете то, что индекс строим сначала, строим после того, как наши данные попали в нашу таблицу. для того, чтобы всёрте у нас каждая условная запись или блокзаписи не проходили через отдельный процесс indats. Соответственно, здесь дополнительно вот есть здесь параметр lists и а считается он как если до 1 млн строк у нас в нашей сущности, то указывается как квадратный корень из количества строк. Если больше миллиона строк, то количество строк делится на 1.000. отдельный тоже параметр. При этом можно также управлять качеством поиска через те же самые пробы, а которые указывают, сколько кластеров просматривать. По умолчанию здесь указывается один кластера, те, которые мы с вами посмотрели условно на картинках, на которые разделяются условно наши данные при индексировании. Соответственно, чем больше таких кластеров нам по умолчанию нужно рассматривать, тем точнее будет результат, но тем медленнее будет происходить запрос. И, соответственно, второй индекс, он у меня здесь создан. Здесь ничего, по сути, не делается. И второй индекс, который мы с вами указываем здесь, поскольку у нас граф M - это число связи каждого узла в графе, по умолчанию 16 штучек. И второй параметр, который EF construction, размер очереди при построении по умолчанию 64. Принцип тот же самый, большее значение, точнее, но при этом дольше строить. Соответственно, его мы с вами пока создавать не будем, чтобы они между собой не конкурировали. Попробуем запустить эти запросы для того, чтобы с ними тоже поработать. Давайте. И индекс для полного текстового поиска просто, который рядышком затисался, это тип днin, а, без каких-либо дополнительных там настроек. Он здесь уже был создан. Соответственно, проверяем индексы PG и indксис. Ага, оба у нас здесь и созданы. Давайте, соответственно, мы всё-таки один из них дропнем, чтобы они нам здесь не мешали. То есть есть primary, да, битришный, как он здесь указан. И вот эти два. Давайте уроним вот это, чтобы между ними не было разнограсий. Дроп индекс. Дропнули, посмотрели. Всё, три индекса у нас здесь осталось. Запрос достаточно стандартный. Можно посмотреть размер индекса. Единственное, я здесь создал как relation name, а хотелось бы, чтобы это был всё-таки index name, но они здесь тоже указаны сами по себе по размерам. Есть PG Stat user tables, насколько помню, в этой сущности или, может быть, слегка в другой, но по умолчанию включённой в постгрос системной сущности можно посмотреть размер индекса относительно размера данных, которые есть в таблице. И частенько можете заметить то, что индекс даже больше может весить.

Итак, давайте попробуем чего-нибудь здесь посмотреть. Сделаем exct search без индекса. Посморим, посмотрим, что у нас здесь получается. Значит, у нас здесь сканы по умолчанию, кстати, у нас включены. Show enable index scan включён. sequential scan тоже включённы те и те включены соответственно данных, как вы видите, прям сильно немного, поэтому он и нам говорит секре сканы идут немного записи, поэтому так и обрабатывается снизу вверх читаем лимиты, sequential сканы, сортировки и так далее. Попробуем enable se scan сделать off. Se scan поставим на off или через нолик. Можно то же самое. И попробуем повлиять. Вот, соответственно, получилось. Повлияли мы с помощью этого самого индекса. Вот он у нас теперь создался. Поскольку опять же у нас execution time, planing time очень-очень маленькие, поэтому, собственно, мы и не всегда на эти индексы попадём, но видим то, что у нас сразу два индекса сейчас включились, когда мы отключили возможность запускать после sequential, да, последовательное сканирование по всем нашим данным. Видим, сколько у нас индекспоисков было, как они здесь, соответственно, применялись. Соответственно, индекс дополнительно давайте, да, создадим, дропнем, который у нас был. Сейчас запутался в своём же примере, чтобы показать. Так, нам нужно дропнуть. У нас сейчас есть индекс, который flat. Правильно же? Правильно же. Давайте его дропнем, посмотрим, как он повлияет. Не он, а как повлияет новый индекс, который мы только что хотели с вами сделать второго типа. Вот этот. Его сделаем. Ещё раз посмотрим. Вот. И он применился. Чуть-чуть дольше выполнялся, но это опять же доля секунды. Но видели то, что и он, соответственно, здесь применяется и используется вместе с primaryки key. Соответственно, дальше, чтобы оценить performanceс поиск ближайшего соседа, мы ещё раз его дропнем. тот индекс, который до этого мы вот сейчас создали, нужно было его создать изначально, на нём протестировать и создать фл, который мы бы сейчас заиспользовали. И его создали. И можно указать для этого индекса те самые, которые будут влиять у нас на нашу точность наших вычислений. И выполняем тот же самый запрос. Смотрим на его результат. Видим, что он опять же применился. скорость особо сильно у нас не изменилась, но сам индекс у нас тоже присутствовал. И, соответственно, давайте попробуем посмотреть, применялся ли у нас наш индекс или нет. Полнотекстовый поиск у нас ни разу нигде не применился. Поиск по B3 применился аж 23 раза. И сколько тапов он прочитал. И наш индекс, который мы здесь запустили, применился один раз, поскольку мы его несколько раз опять же взяли и пересоздали. Это также можно посмотреть.

Соответственно, это тот материал, который хотелось вам сегодня продемонстрировать, показать. Ссылки, э, презенташка вам должна будет быть отправлена по имейлу, а, по почте. AIL, обалдеть, откопал слово. по почте и вместе с записью. Постараюсь найти запись, когда она будет выложена, выкладываться, не подскажу даже насколько часто, насколько быстро. В рамках наших занятий записи выкладываются в течение 24 тире48 часов, чаще там и то меньше. А здесь, соответственно, посмотрим. Выложу это в Git и приложу ссылку. А, то есть два индекса разного типа нельзя создавать вместе в рамках одной BD. Могут конкурировать между собой, лучше подбирать один или другой в зависимости от исходных данных и тестировать, какой из них лучше работает, какой хуже. Не было презентации на email. А так она присылается тоже после вебинара. Они не приходят, только запись присылают. Да. А, о'кей. Давайте уточним тогда, почему они не приходят. Преза не приходят. А может быть, я что-то не знаю и вас зря дезинформирован. Запись будет, а, о, запись будет выложена в группе ВК, а также отправлена на email всем, кто регистрировался на вебинар. Да, видимо, я вас дезинформировал, когда сказал, что презенташка тоже будет отправляться. Давайте я тогда уточню, могу ли я эту презенташку выложить просто под запись? Если нет, то опять же контакты были в самом начале. Давайте на них, собственно, перейду. По сути у нас завершение нашего занятия. Список материала для изучения, который я использовал, в том числе для подготовки. Очень хорошая статейка, на которую очень рекомендую обратить ваше внимание. Да, увидел то, что вы пишите, что прежда не приходит. Я уточню со своей стороны, что в таком случае делать. Либо приложить как-то к самому аа соответственно вебинару, к его записи, либо какой-то другой вариант мы рассмотрим. Тут сам принимать решение, к сожалению, не могу. Нужно консультироваться с представителями той же компании, с командой компании. Слайд с контактами. Вот он. Он могу, наверное, здесь я вероятнее, что отвечу. Давайте здесь приложу. Надеюсь, ничего страшного в ответ не получу в личное сообщение. О'кей. Хорошо. А, итак, коллеги, на сегодня по материалам у меня всё. Если есть вопросы, задавайте. Я, соответственно, попробую как-то выгрузить этот чат сегодня или просто пройтись по вопросам. Григорий, ваш вопрос запомнил. Владислав, ваши вопросы были, на которые я точно не ответил. А соберу их тогда и их, я думаю, могу приложить вкль ответ. О'кей. Коллеги, спасибо большое за сегодняшнюю лекцию. Надеюсь, что вам было интересно, познавательно и вы с пользы провели эти полтора часа. Надеюсь очень увидеть вас в рамках нашего с вами курса. На сегодня тогда всё. Всем большое спасибо. хорошего вечера, хороших выходных и если что по теме, пожалуйста, пишите. Так, Григорий увидел, считал, аэ, собственно обратную связь по этому процессу. Понял вас. Извините, что так получается. Так нет, у вас были хорошие вопросы, Владислав, и прямо много и по делу. О'кей, спасибо большое. Всего доброго, хорошего вечера. Я пока здесь остаюсь, не выключаю, чтобы ваши вопросы забрать. До свидания.