RAG for AI Agents. База знаний из сложных документов + ответы на вопросы

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

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

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

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

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

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

Есть в целом рак система, которая работает как САЗ, готовая с коробки. Вы просто подключаете, по пишке ходите, забираете что угодно. При этом они там могут свои лмки уже использовать и так далее. А и стоит это вот, допустим, вот эти вот лимиты, да, вот которые есть, 20.000 просто запросов рак 20, ну, плюс 20.000 зас запросов с участием лмки, который вам предобработает, ну, посто обработаю, вернее, ваш э этот ответ и 200 Мб именно чистых текстов, ну, джесонов туда можно загружать. То есть это такая немало, немного, но так среднее такое значение, допустим, чтобы потестировать уже в каком-то продукте, да, чтобы не совле делать и, допустим, не нужен вам интерфейс и так далее. Вы просто хотите свой продукт или в какой-то агента что-то добавить и попробовать вообще нужно, не нужно. Вот эта штука стоит в месяц 100 долларов. То есть разработка явно будет дороже, сложнее и так далее. Но эта штука уже хорошо работающая прямо. То есть там люди как бы знают, что делают, и в целом можно одну из них взять. То есть это как пример, там типа 100, есть там вторая какая-то другая, там есть 600 в месяц. Ну есть они там разных ценой. То есть там на рынке есть две-три хороших, которые я находил по разной цене.

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

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

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

Потом у нас есть самарак, э, система, которая состоит как бы из двух частей. у нас есть какой-то пайплайн, а обработки входящей информации и её структурирования. То есть у нас есть это входящие документы, условно, потом мы это делаем, допустим, Marкдаун, потом делаем какую-то очистку, потом это складываем в jon. Почему JSON? Потому что туда ещё можно положить метаданные. А я очень топлю за метаданные. Просто как бы положить куски текстов - это как бы плохой подход. Нужно добавлять туда метаданные. Какие метаданные, потом поговорим попозже. Собственно, по поводу пайплайнов, тут главное три самые трудоёмкие вещи. Это, ну, вот этот Jon структура, которая на выходе получается, её прямо надо продумывать. А она зависит от того, какую мы проблему на выходе решаем. То есть какие вопросы будут задаваться примерно, какие данные нам нужны. И структура документа. Вот это же сонно прямо надо подумать.

Потом надо подумать, как мы будем валидировать в целом ответы и валидировать то, что у нас в целом получается. Потому что, ну, хорошо было бы, если было быть 100 вопросов на входе, которые, допустим, типичная техподдержка вот какая-то, да, типичные 100 вопросов. Мы берём из них там, допустим, 70 тренируемся, ну, условно говоря, оттачиваем нам наш наш рак на 70, а 30 даже не видели, да, а потом нам тридцати показывают, и мы там показываем как бы голый тест, то есть не ну как бы не поддельный. И, собственно, на эти тридцати в конце мы в итоге показываем, как мы там настроили, какие минусы, какие плюсы и так далее. То есть это самый такой примитивный, может быть, простой подход. Ну и дальше до бесконечности каким-то образом надовалировать, проверять и так далее. Кто-то лэмку использует, я не сильно сторонник, то есть там можно кое-что через лэмку проверять, но в целом всё равно валидация человека никуда не уходит. То есть, чтобы вашу рак систему всё время МКА проверяла прямо на правду, на 100% и ещё и знала, что у вас вот этой, ну, в джисонах исходных было тоже всё правда, но это как бы овер, по-моему, недостижимый пока уровень, на мой взгляд, я могу ошибаться.

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

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

И последнее, что ска, ээ, где мы всё это храним, то есть, э, три как бы варианта. То есть самый простой вариант хранить. Если у нас просто JON есть и всё, мы храним, допустим, в постгрес SQL там PG вектор берём, чтобы у нас всё чисто постгрессы и больше ничего нам на не надо, но это такой как бы базовый подход, базовый минимум, я бы сказал, да. Вообще в лоб, если решать, то это просто векторная база, просто чанки. Но это даже я не рассматриваю, то есть это не совсем рак, это просто векторный поиск, который не сильно хорошо вообще показывает результаты. Поэтому нам надо минимум какая-то база более-менее, и это постг SQL с векторами поисков.

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

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

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

Вот примерно вот картиночка, если представить такой как бы объёмный, да, объёмный вот этот весь, э, у нас в по каким-то векторам вот здесь вот какие-то продукты, съедобное, там где-то Apple даже рядом, но в целом где-то вот в этом области такой-то домен животные вот в этом и так далее. То есть у нас есть какое-то большое пространство векторов именно семантических. И мы вот в этом, а, в этом пространстве говорим, что вот эта фраза, вот эта фраза лежит примерно вот тут. И тут адрес, как знаешь, как как на карте. Оно где-то вот вот вот здесь вот, да? Если другая фраза, допустим, где-то вот здесь вот лежит, то они вообще не похожи. Одно вот здесь лежит, другое здесь. Ну совсем не похоже. А если первая фраза лежит здесь, а вторая вот здесь, они прямо рядом лежат. Эй, похожи. И вопрос только, насколько они похожи. И вот насколько они похожи вычисляется по косинусу. То есть вот этот вот визуально, да, вот это у нас а и b косинус между ними, вот это вот расстояние. Тут какая-то сложненькая формула, если кому надо. Но смысл такой, что мы просто берём два числа, сравниваем между собой, получаем какой-то 0,8, 0,7 и так далее. И это получает этот же скор. Он считается примерно следующим образом. Ну, примерно вот так вот, да, можно говорить. Единица - это полная идентичность. 0,9 почти почти там 0,6 - средняя схожесть. 0,2 почти ничего. И там 0,2 - это вообще, ну, как бы совсем небо и земля.

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

В целом всё, больше у нас как бы нету. А теперь возвращаемся к векторным базам. То есть, что делает векторная база? Это у неё есть, условно говоря, если это SQL, в одном столбце, вернее в одном столбце у нас есть вот этот текст, во втором столбце у нас есть вектор. У нас на вход залетает какое-то число, вернее, сейчас вот я неправильно показал. Вот у нас в базе лежит вот этот текст, а у него есть вот этот вектор. На вход у нас получается текст вот этот. Мы получаем число, отправляем число как бы на поиск. И оно вот это число сравнивает со всеми числами, ну, векторами по сути в базе. То есть, если там миллион, да, оно должно вот это число сравнить вот с этим числом по по миллиону вот этому. Ну, собственно, если, ну, мой ответ такой: есть векторные базы, которые заточены, на мой взгляд, только на две вещи, которые оптимизированы для хранения вот таких вот векторов, в смысле типов данных, чтобы там красиво лежало, немного занимало, и второе на скорость. И это всё актуально только тогда, когда у вас массив, ну, то есть огромная, то есть у вас столько много вот этих текстов векторизованных, ну, превышает там, не знаю, там 100.000, там больше, я не знаю, какие порядки, но в целом, когда вы уже чувствуете на на каком-нибудь, допустим, порсе вы чувствуете уже прямо задержка печальная, вот тогда вы берёте какую-то специализированную БД и храните там только вот вектора и там быстро вот будет. То есть они там прямо ну очень быстро работают. Ну, по сути, потому что это новая база данных, заточена только на одно, сравниваются вот эти вот как бы числа. Ну, если я утрирую, так больше по-простому рассказываю. Собственно, вектор BD, на мой взгляд, нужна именно вот такая специализированная в случае, когда у вас очень много объём вот этих данных, которые вы храните и векторизуете, и вам надо быстрый отклик. Всё остальное можно, ну, так для е-агентов, особенно там, ну, короче, я пока не сталкиваюсь с прямо огромными проектами, которые тоже можно как бы, если по правде распилить и распилить на агентов, которые в разный рак ходят тоже, в том числе.

В общем, аа вот то, что вы перечисляли вот, ну, из чатиков, почему? Потому что я так отвечаю. Потому что некоторые люди думают, что для того, чтобы мне надо пользоваться, я, кстати, раньше тоже так думал, для того, чтобы пользоваться векторым поиском, надо специализирован BD. Нет, можете брать классический пост SQL, делаете плагин PGTor и всё, у вас есть там вектор на поиск. Ээ, более того, все поисковики, которые Open Search и другие, вот я сейчас там покажу их, а где-то у меня ссылочки были вот здесь вот, да? То есть, а, есть, э, ну, альтернативы любые, короче, какие-либо поисковики, да, которые, ну, классические, которые там для онлайнбольших магазинов и так далее заточены, они в целом уже к себе завезли тоже по вектору поиск. То есть и там тоже это можно делать. Я к тому, что вот специализированные векторные БД, они прямо надо понимать, а зачем оно конкретно мне нужно и, ну, как бы по какой причине. Вот, собственно, это ответ на то, что типа какую бы дето там выбрать и почему вот эту или или эту. Их очень много. Я, честно говоря, не знаю ответ, почему ту или иную надо выбирать. На мой взгляд, а, надо выбирать от потребности именно либо большой объём, а, либо прямо скорость. Ну вот это это, наверное, две главные причины. А скорость она прямо напрямую зависит от какой у вас объём там данных. То есть, если там у вас, ну, прям прям очень много, то, конечно, надо выбирать, которые побыстрее. Ну, собственно, там и сравниваются счмарком, и так далее.

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

А-э, ну да, вот если прямо очень много тысяч, да, вот там вектор НБД специально есть смысл, а туда брать. Но у меня вот большой вопрос, вот если у кого-то 500.000 уже векторизованных документов и так далее, а значит, у вас уже какая-то система работает, значит у вас уже какая-то БД есть. Следовательно, вы говорите либо хотите пересесть на что-то другое, либо вы гипотетически говорите, что у меня как бы будет, я вот хочу вектор BD. Так, вы возьмите просто из этих 500.000 1.000, сделайте на возрасте, потренируйтесь, а потом переедете. То есть, ну, как бы я бы так подходил.

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

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

Ресная локи обновления данных вектора на базе. Есть информация меняется частично. А, ну, в принципе, я на это смотрю, что если у вас залетел, если у вас есть пайплайн, вот этот, да, у вас залетело сюда, допустим, 100 документов, вы сделали с них Джесона, вы положили сюда вторые данные, и они сюда перекочевали по вашей там логике. Следовательно, у вас всё здесь готово, викторизовано лежит. Представим, что из этих 100 документов, которые имеют свою свой линк на S3, у вас меняется на S3 документ. Ну вы же обновили его, по идее, да? То у вас, получается, линк меняется, можно сравнить по Джисону, что там поменялось. Собственно, если сам GSON вот этот вот ну, короче, отловить, что у вас поменялось, и из этих став вы меняется только два. Следующим, вы берёте опять стрит два документа, прогоняете опять по пайплайну, сохраняете сюда как бы сырые данные и здесь вот меняете. Это если у вас прямо документ поменялся. Другое дело, что вот если, допустим, рак вопрос-ответ, ну, допустим, у вас есть 1.000 вопросов и 1.000 ответов, вот такой вот рак, и у вас, напусть поменялся один вопрос, тогда у меня если вы храните всё это в, допустим, там, не знаю, в Google таблицах или где-то ещё, вам просто надо придумать, как вы отслеживаете изменения на уровне строк, например. Вот. Ну, собственно, ну, какая-то классическая такая задачка, как отследить изменения сырых данных, а потом уже их повторно векторизовать.

Как определить подходящий объём одного чанка для векторизации? Хороший вопрос. Это прямо философская длинная тема, но мы там об этом тоже поговорим. Я покажу, в чём проблема. И не

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

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

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

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

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

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

Собственно, ещё раз повторю, а почему я тогда рисовал вот три таких? Потому что если у нас был бы тоже просто вектор, нам надо было просто векторная база и больше ничего не надо было. Но так как мы будем хранить метаданные, то есть вот здесь вот и и здесь они тоже будут, и у нас исходные ээ файлы мы тоже хотели сохранять. И чтобы к ним обращаться и, условно говоря, даже знать на какую страницу пдфки а человека, ну, то есть не просто имфайл дать, а конкретно страницу показать. А это мы можем из метаданных получить. Собственно, нам надо будет ссылка, то есть а м это я говорю, почему вот эти три базы, в принципе, что мы храним и куда мы храним, показывал. То есть одного СQэля, возможно, не хватит я к этому. А вот поэтому вот гибридный поиск. Я вот, честно говоря, вокруг вот этого всего а практически всё кручу. Ну, то есть, если я бы что-то делал, всегда я бы вот этот гибридный рассматривал, потому что он, а, позволяет достаточно не выкидывать старый технологии, мягко говоря, а потому что вектор - это, ну, ну, да, тула, новый как бы подход. Мы его берём и просто, а, совмещаем со всем старым, что мы раньше использовали. Вот. Аа он позволяет достаточно сильно такою, ну, я бы сказал, итерационно усложнять систему, а, и позволяет, если что-то где-то плохо работает, какие-то делать как бы апгрейды, потому что а смета метада так а схемы метаданных как формируются ключи, например, да, она формируется в зависимости от того что вам в целом надо там иметь, да, то есть, ну, вы же не просто от балды делаете метаданные, вы как бы думаете: "О, этот ключ мне понадобится по-любому. Вот, допустим, производитель мне точно нужен записать там или там ссылка на исходный документ, точно надо". И таким образом вы думаете заранее, почему я говорил про структуру, да? То есть я говорил вот много очень уходит вот здесь вот, когда я показывал вот pйeline и вот эта структура документов GSON. По сути, документы JSON - это, ну, метаданные в том числе же. И вот там надо подумать, какие у вас поля есть. Если я сейчас покажу показываю вот этот же сон, как вы видите, здесь не совсем ключ значения, потому что вот аа против чего лечим. Допустим, здесь только одна позиция и здесь может быть там пять позиций. У вас там ключ значения не особо получится. А здесь у нас получается списки тоже есть вот культуры, которым, ну, которым можно этот химикат применять. То есть ээ здесь получается списки уже идут. То есть этот достаточно такой сложный может быть пример, но для начала у вас может быть вот как бы вот первая часть, допустим, там, не знаю, 10 ключ значения и как бы всё. Ну, достаточно, наверное, для первой итерации, например. Схема универсальная просто не существует, то есть она очень от документа зависит. Ну, тут тут логично, мне кажется. А вернее, даже не от одного документа, а от типов документа, которые вы хотите обрабатывать. То есть, допустим, для договоров один тип схема, допустим, для учебника по химии другой тип, там и так далее.

Так, 0,7 - это просто магическое число из опыта, я правильно понимаю? Нет, нет, нет. Ээ нет, это не магическое число. Это прямо жёсткое значение, которое имеет смысл. Вот ещё раз. А значит, ну это сходство на уровне математики, скажем так. То есть единица - это 100% похожесть текста. от 0,9 - это там почти 0,8 и так далее. То есть это прямо математика. То есть это не это не лмка придумала, это вот именно косинус сходства двух чисел, прямо математика. Вот почему она может быть неточной, это только из бегмодель либо из-за мусора, который у вас там хранится. Ну, то есть, если у меня вот здесь вот в этом тексте а будет вот этот текст, да, и половина вторая, которая вообще не имеет смысла к этому, то если мы всё это вместе завекторизуем, то вектор будет нечистый. То есть как бы сбит в этот вектор по сути немножко не туда нам показывает, собственно, а, и тогда только он будет неправильный. Но в целом, если вот текст прямо хороший и сделать из него вектор и сравнить с запросом, то их похожесть будет всё правда. То есть так.

Какую бединг модель посоветувать для кириллицы? А тут я советую не заморачиваться. Есть сейчас две, ну, то есть топовые модель- это Open Large 3. Вот этот. Мм, советую её брать и вообще не париться. Она работает, ну, лучше всех и она очень дешёвая. Смысла на этом экономить нету. Вторую модель я ещё не тестил G AI. Они какой-то сделали апгрейд буквально там, ну, в этом или в прошлом месяце, но я её не тестил. У меня какие-то такие, собственно, есть тесты. В общем, а, но в целом я не тестил, но я бы её посоветовал. Gи делает неплохие штуки по поводу эмблединга в целом, куда они смотрят. LM недодетерминированный, это проявляется и в случае виктора. Нет, тут не так работает. То есть сейчас ещё надо ли использовать один сид для всей своей базы векторизации? Нет, сидов векторизации вообще не существует. Ну, как бы, насколько я понял, нет, там сидов нету. То есть это не генеративная штука в целом, потому что у вас есть, представьте, что у вас вот это вот векторное пространство - это как бы слепок мёртвы, как сказать, фиксированный слепок неких, ну вот чем-то сравнить. Вот графы знаний больше похожи, когда у вас куча всяких доменов, слов, они между собой где-то сгруппированы в какой-то группе, и группы потом где-то лежат в пространстве каком-то. Так вот, это как такой сслепок всех там слов мира или не знаю, как по-другому назвать. и на на основе текстов, там на основе чего-то. Это всё сделано пространство, и оно как бы выдаёт результат всегда одинаковый. То есть если вы скажете лмке: "Расскажи анекдот про кота", оно он выдаст всегда разный результат, да? Вот для этого нужна сид фраза. Ой, сид ну да, фраза или номер там по факту. Значит, ээ чтобы у вас получился на выходе одинаковый результат. И то же самое с картинками работает. А по вектору у вас всегда одинаковый результат на выходе. То есть, если вы векторизуете вот эту фразу, у вас на выходе будет одинаковое число. Собственно, это нем в этом плане.

Так, гибридный рассказал. А вот теперь уже примеры. Вот. И на примерах будем понимать, наверное, я сразу покажу пример, чтобы прямо какое-то, ну, графическое было, как это вообще, с чем это едят, а, и на что это похоже. Значит, а, есть простые документы. Представим себе документ, который как книжка имеет абзацы. Вот у нас, допустим, вот этот кусочек, да, вот возьмём. Вот, допустим, у нас вся книжка такая, весь документ, просто абзацы тексты, да, вот просто это самый простой вариант, это прямо, ну, легче нету. Но первый подход какой? Давайте мы этот текст разобьём. Вот чанки, все говорят чанки, чанки. И вот на какие-то куски текста по объёму, допустим, по 100 символов, условно говоря. То есть мы берём вот отсель досель, отсель досель и так далее. То есть и что мы видим? Мы разбиваем наши абзацы на какие-то прямо половину куска тут, половину куска там. Следовательно, наш атомарный текст не совсем атомарный, потому что он как бы связ другой и так далее, поэтому смысл нарушаться будет. А и вот этот чанкирование - это вот первый, да, способ просто вот разрезать, да, потом они говорят с перехлёстом, это тоже не всегда помогает. Потом есть и там дальше, что почитать надо почитать, я сейчас не буду мне рассказывать, какие есть способы вообще ченкирования и так далее. Надо почитать лаama индекс где-то у меня был с, э, вот вот лаama индекс, почитайте, все подходы чанкирования там описаны плюс ещё можно нгчейн почитать. У них там прямо методы пайтновские описаны и готовы как бы, чтобы они работали именно прочанки, в том числе с использувам. То есть всё уже придумано, там другого ничего не придумали и достаточно сложно тоже, в том числе. Собственно, у вас задачка, каким образом надо разбить вот этот вот как бы условно вашу книжку вот эту вот, на какие куски атомарные. Вот чтобы они были атомарные. Аа самое такое грамотное, ну что, в принципе не надо думать, наверное, давайте мы разобьём по абзацам. Вот так вот по абзацам. это уже будет ближе к правде, что на самом деле так и есть, что мы можем через тот же Python после парсинга разбивать. Ну, в принципе, библиотеки, которые делают парсинг, вот я сейчас покажу, как они работают, но в целом они уже это делают. Вот. И, собственно, они уже разбивают по абзацам. И вы можете на уровне абзацев разбивать. Это уже, ну, достаточно неплохо, неплохой подход. И, допустим, нас даже он устраивает, и дальше будет проблемы, потому что у вас есть просто текст, а потом у вас появится там текст, текст, текст и там какая-нибудь картинка. Ну, условно, здесь-то она не особо имеет смысл, но, допустим, здесь может быть график какой-нибудь там или схема подвязки помидоров или что-то ещё. Ну, важная какоя-то картинка. Следовательно, вам надо уже эти картинки как тоже обрабатывать. Собственно, я к чему намекаю, что когда вы бьёте по абзацам, то вы можете так обработать только текст, если у вас там формула, что-то ещё и так далее. Надо будет ещё дополнительную обработку делать. Потом а это работает, ну, по абзацам. Хорошо, когда у вас именно вот один столп, да? Если у вас вот такой документ, как я, ну, специально показал, посложнее, то есть что здесь? Ну, как бы брошюра, условно говоря, ну, имеет там это один лист из там десяти или сколько. Значит, а она имеет столбцы вот такие вот. И библиотеки, допустим, некоторые, которые парсят в ПДФ, в MKOn готовы, да, то они понимают, допустим, что это заглавие, это абзац, они всё это разбивают, но они даже могут определить, что вот здесь вот первый столбец, здесь второй, здесь третий, з четвёртый. Но хитрость в том, что если так посмотреть ближе, то есть здесь ещё хитрее. То есть текст идёт вот так читается. Так, потом мы переходим не сюда, а читаем вот так. Вот так. Потом переходим сюда, читаем здесь, здесь, здесь и потом переходим сюда. И вот таким образом получается, смотрите, какая история. Берём, ну, библиотеку, которая сбивает парсинг, да? То есть, что она видит. Она берёт все тексты и просто кусками их сохраняет. То есть вот у неё первый кусочек, там вот я вижу текст, выделила, а, беру вот этот кусочек, выделила вот первый, я говорю, то есть она определяет абзацы. Вот, допустим, мы взяли кусочек первый, положили в кусочек второй и так далее. Идём вроде по порядку. И потом вот в этом месте логика нарушается, потому что пятый, шестой, седьмой, оно пошла вот дальше по этому сюда, потому что она вот этот пунктир, как лю, ну, люди ж пунктир видят, и она как бы воспринимается. Собственно, лмка. ой, не Лымка, а библиотека на Пайтоне уже этого не видит. Следовательно, у вас нарушается хронология а в маркдауне, которая была в документе. А и это починить можно, но как бы надо прямо подумать, как это сделать. Собственно, это первая такая проблемка, которая, э, ну, у меня, например, возникала с обработкой вот этого документа, что хорошо, я даже знаю, как мы будем вот так вот читать. Если бы всё так, было бы вообще хорошо. Но когда разбивается вот так и вот сюда оно идёт, то это вообще, ну, как бы проблемка. Это к тому, что очень сильно многое прямо зависит от типа документов и в каком формате он предоставлен. Форматирование вот этого документа это прямо сильная как бы проблемка. А потом у нас есть разные вот эти парсеры, да, вот эта библиотека на Пайтоне, их там есть там, не знаю, штук пять, наверное, уже точно топовых. А значит, есть готовые какие какие-то, ну, вот я два для примера, которые не сильно популярны, но в целом стоит полезно почитать про них. А готовое решение, которое прям много чего красивого делает, ну, типа САС или что она там не очень-то, ну, короче, она делает из ваших документов что-то красивое, что вы можете забирать. Вот. И второе, мегапас - это который, ну, там тоже, по сути, библиотека, которую можно тоже много чего распарсить. Вотма индекс тоже парсинг имеет и так далее. То есть парсинг на самом деле много. И это совсем не про лмки. Это по сути Python, который вам просто делает маркдаун. Вот. А дальше вы просто берёте этот маркдаун и каким-то образом, что у вас там в итоге получилось? Каким-то образом пост обрабатываете, а, и там дальше уже отдельный вопрос, как, ну, прямо длинный длинный вопрос, как это можно делать, потому что сейчас покажу вот типы информации, и вы поймёте, почему. Сейчас я вот пример SQL вернусь к этому. А сначала покажу, что может быть за информация. То есть представим, что в этой, ну, в этом книжке были таблицы, либо это не книжка, а просто таблица. Вот, например, такая таблица. Значит, что в этой таблице есть? Там название вот это, да? Вот у нас получается дозировка, название против чего, что там лечит, какой период там вегетации или чего-то там, не знаю. И, собственно, это вот информация. И первый вопрос: а каким образом это там ченкировать? Или по-другому я говорю, какие томарные здесь будут единица информации? То есть вот что строчка не подходит, вот этот кусок не подходит, потому что это всё относится к этому препарату. Собственно, здесь буксует, ну, как бы обычная лойка, и надо сидеть и разбираться, каким образом мы будем сохранить информацию вот такого, допустим, вида. Вот. Ну, есть подходы, понятно. А это первый пример таблицы. Второй пример. Допустим, если у вас резюме или что-то в этом роде, а значит, что у вас есть? У вас какая-то информация есть сбоку, какая-то есть здесь. А и она как бы, скажем. Ну, здесь ещё более-менее пример не сильно сложный, но я к тому, что когда информация, она в разных местах по-разному написана. В резюме бывает очень часто, там очень много блоков разных. И если это не объёмно, там две-три страницы, там проще через лэмку это всё собрать, чем парсингом, на мой взгляд. А если такая вот структура сложная, да, там ещё 100 страниц, то там уже, да, вопросы ещё рождаются. То есть второй тип, например. Потом, допустим, у вас есть вот такая штука. У вас есть как бы вроде текст, вроде ничего сложного. Текст, текст, формула пошла, объяснение. Оп, оп, оп. И тут вопрос, какими чанками вы будете разбивать? Ну, то есть тут вообще любая другая логика тоже сломается, потому что это вообще другой тип информации. А каким образом её собирать и что такое томарная часть? То есть это просто формулу собрать и либо же это две формулы должны быть вместе, то есть и там дольше, ну, то есть очень сильно зависит от типа информации. Я к этому и метаданные в том числе зависят от типа информации. То есть вот как вот этот ээ документ из 100 страниц вы будете ну загонять в рак. Это, ну, прямо длинный процесс. Собственно, почему я возвращаюсь к этому моему первому? структуры джисонов. И вообще вот этот пайплайн - это прямо кусок большой работы. И если у вас просто документ в виде там художественного книжка, это куда не шло. Но если что-то посложнее, ну, с формулами или что-то ещё, или хотя бы даже просто с таблицами, это уже как бы прям, ну, задачка. Вот, собственно, третий пример у вас может быть даже GON, то есть у вас нету сырого ничего. У вас даже парса ничего не надо. У вас вот jon вот пример, да, берём там Telegram какой-то канал, вот, а, берём Jon. Вот что они там когда-то постили, да, а и здесь вот такой вот прямо вот сырые, как бы, сырая информация вот в таком-то виде. И представьте, что вы хотите загнать в раг какой-то, ну, паблик, у которого там, ну, очень давно, там, 5 лет ведётся, и по нём там вопросы задавать. Ну, хорошая идея, хорошая. Сырые данные. Вот они. Вопрос: а как теперь этиры данные обработать, чтобы положить это всё красиво, хотя бы в маркдауне в даже просто в вектор? Да, тут тоже большой вопрос, как это всё сохранить. Следовательно, это тоже тип информации другой, и это только четыре типа. Можете пофантазировать, какие они могут быть. Ну, если там кто-то там с интеграциями работает и так далее, это тоже прям я к чему веду? к тому, что в зависимости от типа входящей информации ваш рак будет всегда, ну, то есть по сути, а как только появляется новый тип информации, в который мы хотим добавить враг, вам появляется изменение самого вашего рага, потому что каждый раз надо как бы его дорабатывать, чтобы он с этой информацией нормально работал. Вот. И это, на самом деле, самая большая, наверное, сложность и, ну, это плюс и минус. То есть такой это интересная техническая задача. Вот. С другой стороны, это к тому, что рак в целом не такая простая штука, как кажется. Типа вектора закинул и всё. И даже метаданные там не всегда прокатят. Вот. Потому что эти методаны ещё надо сделать. Вот, собственно, вот про тип информации сказала.

Теперь пример. Вот конкретно таблица. Ну, это просто вот база, да, SQL. То есть есть, а вот здесь вот столбцы просто. Вот у нас столбцы. А здесь у нас получается вот столбец. Это Markдаун таблица. Вот таблица.

Просто вот просто marдаdутекст лежит. Это как исходник. Потом у нас есть, что здесь у нас есть, а gon. Ну, как бы метаданные, можно так сказать, отдельно лежат. Потом у нас есть вот это число, это вектор вот это не вот этого исходного текста, а вектор summary. Как бы summary у нас здесь вру. Дальше вот это.

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

И что мы имеем? Получается, у нас есть исходник Markда, у нас есть summary, у нас есть вектор этого summary, а у нас есть, э, как сказать, ээ, метаданные двух типов, вот такого и такого. У нас есть категория и фильтрация, ну, как сказать, и то, и то. Две категории, две, ну, или, как сказать, ну, два фильтра, условно, или две категории, а, которые мы можем тоже в SQL запросах использовать. То есть это самый такой, ну, наверное, не сильно сложный, но в целом не сильно простой, да, подход. Вот. И это всё. Вот у вас SQL. А, и это в постсе лежит. И вы вот на этой основе можете дальше городить что-то. И это только для одного документа. Это для одного документа я сейчас покажу. Вот для таких таблиц я делал. Вот из таких таблиц вот это примерно получалось. Вот. Аа, поэтому надеюсь здесь, ну, я к чему? Я к тому, что здесь вот эта бесконечная тема, как тот или иной тип информации обрабатывать и бесконечная тема, как улучшать саму, ну, ответы, да, как находить эти ответы и как постобработку-то делать.

Вот у нас что вы думаете про стратегию разбиения чанки по смыслу? А, хороший, хорошая идея. Только вопрос: а как вы, ЛНК, объясните смысл? Ну, типа я видел такой подход. А, берёте чанки, каким-то образом разбили, векторизуете каждую чанку и потом сравниваете вектор каждой последующей чанки. Если там вектор сильно различается по скору, то значит там тема сменилась, и тогда вы разбиваете по этой по этой логике. Это без лэмки, чисто по векторам. Если делать через Лэмку, там большой вопрос, какой у вас должен быть промт. И в общем, ну, надо подумать, как это сделать, потому что, ну, идея как бы хорошая, вопрос реализации. дальше.

Но всё равно, когда мы строим пространство, конкретное значение чисел векторов будет зависеть от того, на каком объекте тестов обучался ending модель. Ну, я бы про это не парился. Я вот сейчас тоже об этом думал. Есть такое понятие брать какую-то днing модель и её фантюнинг под себя или до оббучать под себя. Я посмотрел, очень не сильно много я видел решений, которые типа, ну, типа са, да, приходите, добычили модели, их модели используете. Их не сильно много. Мало кто такую услугу предлагает. Я делаю вывод, что это не сильно популярная вещь и она сильно не развивается за последнее время. Следовательно, мало кто на рынке видит в этом смысл. А раз мало кто на рынке видит в этом смысл, я бы не сказал, что я самый умный и буду я это копать. Вот, собственно, похоже подход брать самые лучшие модель от Open не париться работает лучше всего. А я бы парился про другое, как дальше делать уже с медингом, уже когда у вас есть вот дальше что там делать? Потому что вы какой бы какая модель бы идеальная не была, вы бы всё равно идеальных результатов не получите. То есть всё равно будет пост обработка.

А метаданные не вручную, конечно же, метаданные собирают через лмку. Ну, то есть мы берём, допустим, а, сырой текст види маркдауна уже, да, и из него вытаскиваем то, что нам надо в Gсоне, структурированные через ЛМКУ. Констиктуализация исходные документы. Нет, в этом, а, в этом конкретном примере это адаптация этой информации для запросов. То есть я знаю примерно, какие будут на входе вопросы. И для того, чтобы, а, уточнить, как бы, улучшить вектор, я, знаю, какие входящие вопросы, я как бы затачиваю вот эту summary под этот вопрос. Ну, на основе исходника, конечно, чтобы они меньше шума создавали. Ну, про другое не говорили, только вот конкретный ответ на то, что он спрашивает. А уже потом даю исходник.

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

Думали ли вы над таким пайплайном изначальный контекст добавляется только summary? Исходные данные подгружаются через MSP сервер, если LM считает их релевантным для ответа. Да, супер. Вот именно этот я и показал. Только зачем мне MSP, если я сразу могу забрать из этой SQL? Ну, то есть я по сари нашёл по вектору, а ответ ему давал: "Даю не Sumy, а исходник". Это всё у меня в СQэльке лежит. Ну, по сути, два раза не надо приседать. Зачем в MSV ходить? Не надо. Sumary создаётся же или является так или это тоже метаданные по сути summary lm дела да ну это некорректно говорить summary на самом деле это сокращённый вариант адаптированный под конкретную задачу что больше sumary влезло в контекстное окно изначально тут что-то выпутаете контекстное окно какая разница откуда вы берёте у вас контекстное окно, допустим, 100.000. Вы из MSP забрали контекст, положили туда 5.000 или же забрали из того же SQL 5.000 тоже в контекст положили. Какая разница? У вас всё равно контекст сохранится минимум минус 5.000 токенов. То есть тут тут не очень понятно, чем, ну, MSP здесь городить нет смысла, потому что вы не экономите контекст. Контекст точно так же затратится и там, и там.

А значит, первое, что по поводу вот это две готовые штуки. Вот готовая штука. Для тех, кто вообще не программист, есть такая RCK Flow. Она в целом, там можем много чего делать. No cд платформа, она, по сути, обёртка, по-моему, лонгчейна, насколько я понимаю. Там можно всё потренироваться, посмотреть. Ээ вроде как открытый проект. Вот можете прямо тренироваться. Я это не сильно использую, но в целом для начинающих можно попробовать, как что работает. Дальше по серьёзней штуке уже готовые прямо такие, я бы сказал, комбайны. Вот это большой проект. Прямо большой, здоровый. Вот это большой проект. Прямо большой, здоровый. Это полегче. То есть он не та не меньше функции, но зато легче его ээ себе как бы адаптировать. Эта штука что-то новое я нашёл, решил поделиться. Интересная штука. Не сильно копался, но прямо что-то интересное мне показалось. Поизучать не лишнем будет. Потом есть у нас аа вот fullтекст вектор поиск. Это не совсем рак, но вроде очень близко к рагу. Просто надо изучать, что он может, что не может, потому что на самом деле они уже начинают сращиваться, да, там гибридный поиск. Э, короче, вот вот эту штуку я бы тоже посмотрел, поизучал. Потом надо упомянуть обязательно отдельно рак, который под капотом держит графовую, то есть графовое представление связи. Вот, короче, строит граф на уровне ваших вот этих атомарных единиц информации. Вот это один из примеров. Их тоже несколько, но я в целом в граф не пошёл. И пока, ну, недавно пост тоже в блоге делал, почему я туда не иду, почему граф в раге я не использую на данный момент. И отдельно ещё обязательно скажу, что если у вас есть, надо сделать рак, который будет искать вам информации в скэле, то есть, ну, либо в какой-то базе данных, то есть динамическую информацию брать постоянно, это тоже хорошая история. А вот это как бы проект про это, то есть рак на основе, допустим, динамическо изменяющихся различных данных в вашем там СQле, да, или в другой базе данных. И вы в эту уже базу данных можете там подгружать что угодно, а вот эта штука уже заберёт оттуда. Собственно, это с такой готовый проект, который прям, ну, я бы посмотрел. И для самых таких прямо глубоких из того, что прямо советую покопать, это первое. Был такой канал, ну, вернее, есть такой канал М под капотом, это самый такой крупный в телеграме. У них был хакатон, а RКдe, да. И вот на этом гите они выложили готовое решение, которое там, ну, выложили ребята. Советую очень почитать. Там и подходы разные, и в очень прямо прямо полезная штука. Вот второе - это тоже пример, как сказать, ну, тоже не базовой, я бы сказал, базовой сложности рак системе, которые нужно только Python снать. Всё, больше там ничего нету. Пог SQL, ну, как бы всё, всё базовое, да. Вот, вот это вот прямо хороший хороший пример. И вот этот тоже новый нашёл. Это по поводу, а как потом там был вопрос, как оценивать вообще систему, как она работает, в том числе рак систему. Вот это вот тоже можно почитать, посмотреть. Оно как бы рапортует, что оно, в том числе и рак, а может валидировать, оценивать и так далее. Вот. Вот такая штука.

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

Рак или модель тюнинг? Ну, файтнинг, да, конечно же, рак и много причин. У меня на этом по этому поводу прямо большое видео на канале есть. Можно посмотреть там. То есть, ну, прям такой длинный разговор. Почему рак намного лучше, чем файнтюнинг?

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

Как управлять ожиданиями заказчика про содержательную надёжность отсутствия системы? А управлять за Нужный вопрос с ожиданием заказчика. Самый простой путь такой. Вы берёте список вопросов, которые, а, заказчик хочет туда задавать. Ну, допустим, 100, а лучше 500. Вот если у вас 100 вопросов, а вы затачиваете свои, ну, свою раксистему, чтобы она отвечала хорошо на 50 вопросов первых. Вторую не знаете вообще, а потом тестируете на 50 оставшихся, потом дотюниваете, потом вам, ну, говорите: "Вот, готово". И дальше он валидирует эту штуку. Ну, в первую итерацию я бы так делал. А какие ожидания? Ну вот если у вас нету даже, то есть если заказчик не готов предоставить 100 вопросов, которые он туда будет задавать, то каким образом вы вообще поймёте, что вы делаете?

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

Рак или MSP. А-а, ну это две разные штуки. Если у вас есть что-то небольшое или в базу данных, или в какую-то интеграционную, типа GRA или Google, конечно же, функция. А раз функция - это MSP. Если у вас есть какие-то документы ваши или какие-то большие данные, которые тоже ваши и от других не зависит, это рак система уже. Я бы так, наверное, разделил.

Интересно послушать, обсудить реальный опыт рак. делал поисковую систему, использовал М, но рак не использовал пока. А реально опыт, ну, я чуть рассказал, но это прямо длинный какой-нибудь рассказ будет, честно говоря, тут, ну, вот это поиск агрохимикатов по, допустим, ну, запрос такой: чем лечить томаты, если он болеет таким-то? А я, допустим, использую закрытый грунт, и он тебе выдаёт из 5.000 химикатов там пять подходящих. Вот пример конкретный, да?

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

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

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

А, собственно, рак в целом очень сложная задача. Ну, как бы, то есть тут как бы и не будет там типа за 2 дня я сейчас я его сделаю. Зачем рак и что он делает? Он только и только даёт расширение контекста для эллэмки, с которым в данном случае работаете. Всё. Или агенту. Какая разница? Какая? То есть ваша задача дать ЛЛэмке то, чего она не знает. Всё, больше он ничего не делает. Вот надо запомнить, что рак - это инструмент, чтобы дать в нужный момент нужную дополнительную информацию лмки, которую она не знает.

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

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

Вопросы же ещё. Практическое применение рак в продукте. А что-то очень широкий вопрос. Ну, техническая поддержка, например, загоняете всё про ваши знания. Люди задают в чатик вопросы технические, получают ответы.

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

Я клепше заробить рак допраться у копио. Так, ну аа, смотря каком, конечно. Но в целом я бы не сильно заморачивался. Если про программирование речь, то есть контекст 7, называется MSP, который вам подгружает, а про любую библиотеку нужные данные. Если вы хотите подгружать свой код, то, мне кажется, очень сильно заморачиваться должны, чтобы он хорошо работал. Поэтому, ну, я бы, то есть, если капайл - это именно, ну, в целом про программирование, то я бы рак там не городил, на мой взгляд. Что-то это, по-моему, овер будет. А если чисто документацию, то это просто надо бы готовы контекст 7 брать. MSP MCP, правильно говорит, да? Да, MCP.

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

Так, дальше. Лучшие практики. Прикладное использование рак для базы знаний объёмом 10 млн токенов. Полом интеграции СБ постгрес и BI инструменты подбортектуры рак аргументов выбор модели. Да, есть такое отдельное направление BI. То есть у вас по сути, как я и говорил, вы по сути это в пост, ну, в любую БД ходите, и у вас рак ходит не как бы не за текстами, а за динамическими данными в БД. А БД может там 10 штук подключить. Вот вот такой рак получается, который ходит по базам данным. Это не совсем по прямо чистый как бы рак получается, но если там постобработку сделать хитрую, то он как бы рагом получается прямо. Вот, собственно, SBI такая же штука. То есть это всё вокруг, а как получать быстро ответы из ээ из разных баз данных. Ну там надо смотреть, заморачиваться по уровню доступа, да, чтобы не каждый пользователь имел к любым базам, а, и таблицам доступ.

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

Есть ещё другое понятие. Сейчас есть такой рак, что такое рак вообще и так далее. Кто-то говорит про вектор, а есть ещё как-то типа кэш. От слово кэш. Эээ, значит, смысл в чём? Вы просто берёте самую большую там на миллион токенов или там сколько? 2 млн токенов в контекст, сгружаете всё туда и каждый раз у моделей спрашиваете, ну, маленький вопрос на основе этого миллиона токенов, который там заполнен вашими документами, и всё. Ну, то есть ничего больше не делайте, в лоб так решаете. Просто просто есть же, допустим, база типа CRDB, которая она вектор поиска тоже в подгресса использует и она горизонтально из коробки масштабируется. То есть как бы объём данных по идее не проблема. Я тоже так раньше думал, что типа давайте мы сразу продумаем помоему штабирование. Но если у вас ноль продукта и у вас даже нету прорабонтых 5.000 видео и на которых вы уже что-то потестили и знаете, какая задержка, и вас она не устраивает. Ну, собственно, можно, конечно, что-то брать на вырост, но вы, ну, берёте новый продукт, соответственно, стек у вас там относительно будет новый, а постгрес, ну, как бы я, в принципе, поэтому писал, что почему я тоже раньше как бы думал иначе, сейчас точно пользуюсь с SQL мне очень нравится, потому что как бы очень много плюсов, особенно для тех, кто делает с нуля. особенно для неопрограммистов. Вот. А если вы хочете закопаться за какую-то новую технологию либо новый продукт, типа новую базу данных и так далее, ну, пожалуйста, просто знаете, что как минимум вы не всех разработчиков по ну то есть пользовась все базово знают, да, там, условно говоря, и куча документации, куча всего. Лмка вам поможет всегда, а вы в эмэмку постучитесь с запросом про какой-то акгрант. Ну, не всякая лмка вам поможет, скажем так. Ну, это я утрирую, но в целом, ну, но в целом, то есть разница получается, специализированная векторная база и постгрыз - это просто тупо скорость отдачи вектора, я правильно понимаю? Ну, я в этом в начале говорил. Для меня, э, специализированные векторные базы данных нужны, когда огромные объёмы и там либо нужна скорость, либо экономия на этот, ну, объёме самой базы, там, там, гигабайты, да, либо масштабирование в каком-то плане. Вот, ну у вас такой проект, но если пока вы говорите нет, ну тогда зачем?

Ещё раз здравствуйте. Хотел спросить вот такую вещь, допустим, а есть у нас уголовный кодекс, а я из него сделал рак систему, спросил, за что мне дадут от трёх до пяти. Он мне достал какое-то количество векторов, а, соответственно, я хочу дальше всю эту историю в режиме чата развивать. То есть пользователь задаёт следующий вопрос, то есть уже не от до 5, а от семи до 15. Вот, соответственно, нужно, а, чтобы система понимала, аэ, стоит ли искать новые данные в нашей ракбиблиотеке или же достаточно старых для ответа. Под эту штуку у меня какой-то оркестратор там условно написан, который предыдущий запрос а самаризирует с новым, конвертирует его во что-то более читаемое с учётом того, что пользователь может какую-то гадость написать непонятную. И соответственно, ну, микрозапрос идёт, отличается ли он от старого и, соответственно, да, нет. Вот. Но эта система себя пока что не очень эффективно показывает. Вот хотелось бы ещё какие-то лайфхаки услышать на тему того, как вот в чатовом режиме можно рак систему держать.

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

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