RAG-агент для бизнеса: архитектура, промпты и оценка качества

Всем привет. Мы продолжаем говорить про production ready и агентов. Это третье видео в серии. В первых двух мы с вами обсуждали теоретически основные принципы построения надёжных production ready агентов. А сегодня мы будем смотреть это на практике.

И будем смотреть мы это на примере проекта "И консультант для бизнеса". Бизнесу такие консультанты нужны, чтобы обрабатывать большой поток входящих запросов, чтобы лиды не остывали, чтобы их можно было обрабатывать 24 на 7 и отвечать на основе всей своей базы знаний, ничего не забывать, а всё учитывать и давать полноценные, ёмкие ответы клиенту. Ну, давайте посмотрим, что у нас получилось вначале.

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

"Добрый день. Расскажи, каких ассистентов для бизнеса вы делали. Хочу подобрать что-то подходящее для своей компании."

Отправляем запрос. Бот производит поиск информации, соответствующий вопросу и рассказывает, что да, действительно, мы реализовали различных ассистентов. Среди примеров: интеллектуальные ассистенты для консультантов, менеджеры по продажам и ассистенты службы поддержки.

"О, замечательно. Подскажи, пожалуйста, а есть ли у вас успешные кейсы для медиакомпаний?"

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

Вот нам предложил записаться на консультацию, и мы соглашаемся. Он нас просит ввести наше имя, а мы говорим, что наше имя Сергей, email и предпочтительное описание запроса, да: "Консультация по внедрению ассистентов в бизнес-медиакомпании". Отправляем ему информацию, и он запрашивает нас подтверждение создания заявки: имя, описание, email. Да, все данные корректно были считаны. Мы подтверждаем заявку, он обрабатывает её решение.

"Заявка на консультацию успешно оформлена. Пожалуйста, дайте знать, если хотите уточнить время."

Да, действительно. Э-э, слушай, мне неудобно. Я бы хотел на конкретное время записаться. А, пускай это будет, э-э, через 3 дня в 10:00 утра. Да, он предлагает записаться на 10 марта, а на 10:00 утра. Действительно, всё корректно. У нас сегодня 7 марта. Мы подтверждаем заявку, операция подтверждается, и наша консультация назначена на 10 марта 2026 года в 10:00 утра.

"Мы напомним вам о встрече заранее."

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

Ну, давайте начнём с AI Driven Development методологии, которую мы применяли для разработки решения. Делали мы всё решение в кодовом агенте Cursor, разрабатывали по, в общем-то, AI Driven, Spectr-Driven подходу. И сейчас мы с вами его посмотрим уже непосредственно в Cursor. Ну, его принцип следующий, да? То есть вначале мы вписываем какую-то идею, дальше формируем техническое видение проекта системы вместе с кодовым агентом Cursor. Дальше создаём план задач, а, набор правил и соглашений для кодового агента и итеративно выполняем, а, по таск-листу наш проект до результата.

Давайте смотреть это в деле. Вот мы перешли в проекты. А-а, ну, проект открывается, да, с файла README. А здесь уже можно посмотреть полный, э, результат работы нашего проекта и разработки, который был сделан. А начинали мы его с проекта идеи, фиксировали её в отдельном MD-файле, а помечали, в общем-то, какие проблемы будет решать наш бот, что делать и для кого он нужен. После этого, а, пошагово проектировали это решение а с кодовым агентом Cursor.

Давайте посмотрим в режиме preview, да. Обсуждали, какие технологии нам пригодятся для реализации, а структуру проектов, которая должна быть создана, архитектурную диаграмму формировали, да, чтобы нам было понятно, из чего он будет состоять: Telegram, SAMBot, инструментарий, а, MTP-сервер для инструментов и внешние какие-то инструменты, хранилища и CRM-система. А инфраструктурную составляющую тоже прорабатывали, да, из чего будет состоять, из каких непосредственно уже технологий.

А инструментарий, на который будет снабжён у нас агент. А это у нас, видите, здесь пять инструментов: а поиск инструментов, э, информация о получении текущей даты. Да, помним, у нас он корректно обработал, а, запрос наш через 3 дня, да, он сходил и посмотрел текущую дату, аа поиск информации по клиенту, создание запроса, регистрация заявки, назначение встречи. Подробно разбирали параметры входные-выходные каждого инструмента, а, и, соответственно, прорабатывали сценарий работы в диаграммах последовательности наших ботов. И, мм, соответственно, как он будет конфигурироваться, из каких параметров он будет состоять конфиг. Видите, всё подробно настраивается, все параметры отдельно прорабатывали работу с языковыми моделями, через что, как мы будем взаимодействовать, аа какой у нас, соответственно, способ хранения версий и конфига, привязанного к моделям, и прорабатывали различные уровни middleware, да, то есть промежуточных слоёв, а, которые навешиваются, которыми оборачивается наш агент. А это слои безопасности, слои Human in the loop, да, когда требования подтверждения операций, контроль количества вызовов модели инструментов. Подробно разбирали, что нам нужно для нашего проекта. А отдельно RAG составляющую сегодня будем смотреть а с вами подробнее. И тоже мы прорабатывали аж три три пути, три такие архитектуры пайплайна. Их сегодня посмотрим и сравним качество. А как мы сравнивали качество? Тоже обсуждали, какие метрики. Ну, в общем, видите, здесь формируется полное такое видение, техническое видение проекта, а, в которой все основные моменты отражаются, в том числе модель данных, а, способы логирования, ну, сборки и деплоя нашего приложения. Это верхнеуровневый обзор. Ну, на самом деле, подробно про всё это мы с вами посмотрим и поговорим уже впоследствии.

А-а, сейчас хочется показать основную методологию, да, что вначале создаётся идея, потом проектируется вот такая подробная постановка техническая и создаётся дальше правило conventions для соглашения, да, по работе с этим проектом, с этими идеей, с этим видением. После чего был сформирован нами, а, соответственно, нами вместе с кодовым агентом Cursor тасклист, который состоял из девяти спринтов, да, от базового LLM-бота до уже финального агента и оценки его качества. Разрабатывали мы итерационно так, чтобы каждая итерация давала уже какой-то результат, который мы можем измерить, проверить, руками пощупать, да, от первого просто общения с языковой моделью. RAG-системы и контроля качества конкретной RAG-системы, дальше развитие пайплайнов, применение техник advanced RAG, внедрение агентной архитектуры, переход накрайние MCP, подключение безопасности инструментов и подтверждение операций. Ну и уже финальная оценка качества агента. Вот про это всё мы в сегодняшнем и следующем видео будем говорить.

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

Освоить навык такой AI-driven разработки AI-агентов вы можете на нашем интенсиве. И кодинг агентов Cursor, где мы обучаем создавать AI-агентов с нуля, от идеи до облака по AI-driven методологии. Строим живого агента со всеми основными компонентами, которые нужны. Ну а мы переходим дальше к архитектуре и стеку нашего приложения.

Архитектура агента LLM Start выглядит следующим образом. А-а, соответственно, это у нас под капотом архитектурно React-агент, да, который делает цикл, а-а, получения вопроса от пользователя, от пользователя, рассуждение, reasoning, аа, выполнение какого-то действия, то есть либо поиск информации в портфолио, либо поиск информации о клиенте, либо регистрация встречи, назначение встречи на конкретную дату. И также у него есть память, да, история переписки, который ему поступает в контекст вместе с системным промтом, правилами и там примерами своего поведения. Это в целом автономный агент, который в зависимости от того, как строится диалог, а выполняет те или иные инструменты и действия. А построен он на технологии LangChain 1.0. А эта технология была выбрана нами не случайно. А это вся экосистема LangChain идёт в ногу со временем. А сейчас у них даже уже выпущен хороший фреймворк Deep Agents, который они называют как "полноценный агент на стероидах, batteries included", а они говорят, а где есть полный набор всех необходимых middleware. Ну и LangChain 1.0. Он а достаточен для создания, а скажем, и ассистентов, и агентов, которые мне требуются очень большие объёмы контекста перерабатывать. Есть и длинные разговоры. А, то есть условно, если мы не строим там кодового, аналог кодового агента Cursor, то нам вполне подойдёт библиотека LangChain 1.0. И она очень сильна тем, что у неё довольно широкий из коробки набор вот различных middleware, о которых мы будем с вами позднее говорить. И эти middleware, они являются по сути вот, э, самой основой для расширения функций агента и могут встраиваться в различные, а, этапы выполнения агентного цикла, да, вот этого цикла Reasoning, Action. Аа до старта агента, до вызова моделей можно обернуть вызов моделей, вызов вызов каждого инструмента можно строить как-то свои операции после вызова модели, после вызова агентов, после вызова инструментов. а, перехватить каждый шаг, а, для того, чтобы, соответственно, там обработать, проконтролировать, профильтровать, а-а, вход или выход. То есть именно вот middleware превращает прототип в production систему.

Ну, и вот просто примеров несколько из документации LangChain, да: middleware по безопасности, по надёжности, а, для работы с контекстом, самаризация, редактирования контекста, для планирования, делегирования, да, задач, то есть выбор LLM, формирование todo-листов, работа с файловой системой, а, для выгрузки большого объёма контекста. То есть, в принципе, LangChain 1.0 позволяет строить уже современных, шагающих в ногу со временем, а, и агентов.

Ну, один из важнейших этапов при разработке агентов - это выбор языковой модели, которая будет мозгом а нашего агента. А здесь есть два аспекта. То есть надо обязательно понимать, что модель должна поддерживать function calling, tool calling, аа, чтобы оно было обучено принимать решения о вызове инструментов. Ну и она желательно, чтобы модель умела рассуждать. У неё были reasoning способности, она каждый раз прежде чем что-то сделать, подумала. А сейчас большинство моделей проприетарных, сильных, всё это уже умеют. Ну и даже большинство open-source моделей, а небольших тоже могут справиться с этими задачами. А также важно, да, разрабатывая приложение, позаботиться о том, чтобы можно было легко сменить модель без изменения, а в самом коде приложения. Мы для этого любим использовать OpenAI совместимые интерфейсы, а-а, либо напрямую, если мы не используем фреймворки, такие как LangChain, да, используем клиента OpenAI, либо если мы используем фреймворки, то выбираем, а, в них абстракции, которые работают с OpenAI интерфейсом под капотом. И это позволяет нам легко и просто, меняя лишь там конфиги, базовые урлы, название модели соответствующие, а в в конфигурационном файле менять работу агента с провайдерами, open-source моделями, а open-source системами инференса, такими как Alama, VLM и так далее. В общем, очень удобно сравнивать, получается, модели, не меняя а самого кода приложений.

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

Ну вот примерно, да, как это можно сделать. Просто есть YAML файл промта, где указывается модель, температура. Там можно указать ещё провайдер, который используется для вызова моделей, и, соответственно, отдельно файл, в котором лежит системный промт. Это удобно. Можно менять поведение на приложении там без пересборки там кода, а это атомарный конфиг. Удобно смотреть различия через git diff. И, соответственно, мы готовы к переходу на полноценные промт-менеджмент платформы там в будущем.

Ну, давайте посмотрим непосредственно на сам системный промт, как он выглядит. Выглядит он следующим образом. А системный пром состоит из блоков. Мы про них чуть позже поговорим. Ну, соответственно, вот это файл `system.txt`, где лежит сам системный промт, да? А вот вы видите здесь информация внизу о компании, да, есть примеры а работы нашего агента, как он должен отвечать на те или иные вопросы. То есть те самые few-shot examples, да, описание, а, инструментов, аа, инструкции, как ему себя вести, в каком случае, э, соответственно, вызывать, какой инструмент, какой у него в целом алгоритм ответа должен быть. А строго, что нужно отвечать только на основе данных из Research, чтобы минимизировать галлюцинации. И, соответственно, стартовый, да, самый важный блок, мы ему задаём его основную главную роль. И вот конфигурация самого промта на указана здесь рядышком в YAML файле.

Ну так это было сделано всё не случайно. То есть такая структура промта, она рекомендована, а компанией Entropic и OpenAI в их, э, статьях, да, по промт-инжинирингу и разметке промта. Ну вот они предлагают вводить порядок такой, да, то есть идентифицировать задачи, роль, цель, стиль, алгоритм решения указать в инструкциях, описание инструментов в разделе tools, да, там few-shot examples, а размещать дальше там в examples и там в конце размещать информацию, там дополнительный, в общем-то, контекст. Эта структура считается правильной, да? Ну почему, да? В первую очередь разместив на первом месте информацию, роль, цель, стиль, аа модели, это очень важно считать, кто я, отдельно от того, что делать. Ролью удерживаться будет точнее через весь контекст диалога, если она вот сверху вот таким образом размещена.

А следующий, да, принцип - это алгоритм вместо списка запретов. То есть вместо того, чтобы просто запрещать ей что-то делать, аа лучше предоставить ей конкретный алгоритм, а-а, ну, сказать, что ответ уже в истории. А вопрос компания использует этот инструмент. Если нашёл результаты, ответь. Не нашёл, предложи заявку. Нужна заявка, собери аргументы для вызова инструмента и вызови его. Модель рассуждает у нас последовательно, да, то есть они уже обучаются там все на примерах Chain of Thought, вот этих цепочек рассуждений. Поэтому, в принципе, даже рекомендуется алгоритм задавать. вот в виде таких цепочек if-then, а что ближе к этому процессу? А поэтому наш промт на самом деле не сразу был так сделан, а претерпевал изменения и к этому мы, в общем-то, там тоже пришли.

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

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

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

Ну, теперь немножко поговорим про инструменты. А мы их уже бегло с вами посмотрели, да? А и сегодня мы будем больше говорить про инструмент RAG Search, а-а, поиск, да, информации в базе знаний. Но также у нашего агента мы видели на демо, да, он вызывал и инструмент формирования заявки, и формирования, соответственно, встречи на конкретное время. А Search Client History он использовал внутри для поиска там информации дополнительно по истории обращения клиента. Аа инструменты тоже надо уметь правильно описывать. А, соответственно, вот из рекомендаций OpenAI и Entropic. А как лучше всего их описывать? Ну, потом переводим на следующие правила.

Ну, название должно быть глагол действия, да, там `create_request`, `rag_search`, читает, создаёт, ищет. А docstring, то есть описание, если мы инструмент пишем в коде, мы потом посмотрим, как он выглядит, да? То есть рядом с ним используем вот это: и когда вызывать, и когда не надо вызывать. Мы с вами обсуждали этот принцип. Описываем обязательно все поля, аргументы, которые он принимает на вход и которые он возвращает, да, в region функции. И, а, соответственно, если у нас есть какие-то ограничения, а-а, какие-то инструкции, мы можем прямо в этом docstring их указать. Пример: "не вызывай без имени клиента, request типа и описания". То есть это все описание инструментов. Чем лучше мы его а подготовим, тем понятнее будет нашему агенту, в какой момент, каким инструментом надо воспользоваться и как воспользоваться им правильно.

Ну, пример описания инструмента `rag_search` сейчас на экране, да. `rag_search`, у него есть параметр, а description, что это поисковый запрос, примеры какие можно сразу туда подставлять, да, в поискового запроса и общее описание, что это поиск документа компании LMT. Используй, когда вопрос о компании, услугах, кейсах, курсах, технологиях, не используй, когда приветствие, благодарности, передачи данных и возвращая JSON следующей структуры. Эта информация как бы описана а таким образом. А сам инструмент производит поиск у нас по портфолио PDF, услугам, кейсам. А-а, вот этот запрос при вызове, да, `rag_search` формирует сам агент. А, ну а режим уже поиска информации мы посмотрим с вами как раз-таки дальше.

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

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

Технологически, да, под капотом вот для создания, ну, скажем, там, proof of concept, прототипа, да, демонстрационной версии, которую мы вам показываем, мы использовали in-memory vector store для хранения векторного, ну, семантических векторов из экосистемы LangChain. А в целом его можно было использовать там и Chroma Vector Store, и Qdrant Vector Store, а, то есть для хранения же такого персистентного нашего индекса, но у нас данных не так много, а, поэтому мы их можем пересобирать каждый раз при старте. Для полнотекстового, да, там несемантического поиска индексации у нас используется BM25 Retriever, тоже из экосистемы LangChain. А для работы с моделями у нас используются embeddings для формирования тех самых векторов. А опять же OpenAI embeddings class, чтобы мы могли потом использовать любые модели любых провайдеров. Но альтернативно а был подключен Hugging Face embeddings, чтобы мы могли ещё запускать и скачивать себе вектор embedding модели локально и использовать их на своей машине. Всё это удобно переключалось в и переключается в файле. Таким образом удобно поменять конфигурацию, запустить пайплайн работу и протестировать его.

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

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

Давайте посмотрим на те самые данные, которыми мы оперировали при индексации, да. Это вот портфолио, соответственно. А таким образом оно описывается: один кейс на одну страницу. Информация о услугах, да, там по консалтингу, по AI разработке, по внедрению и обучению и для бизнеса по разработке и агентов, да. Ну вот, соответственно, вот такие документы у нас были.

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

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

Есть дополнительно описание инструмента в промте, когда вызывать, когда не вызывать, но также у нас все инструменты - это они, а, формируются их описание динамически. У нас есть мм соответственно наш файл аа рак, где у нас здесь вся информация в этом модуле сведена по непосредственно уже, а, работе с нашим рагом. Отдельный файл, да, для индексации. И нас интересует с вами файл to.Pp, P, где описан инструмент Rock search, соответственно, его описание аа следующее. Продивить поиск какой структуре возвращать результаты, то, что мы с вами в презентации, да, разбирали и описание непосредственно есть, а конкретно одного параметра у него кваре, что он должно себе содержать с примерами. Ну, а внутри уже непосредственно код, там произвести поиск документов, а, и сформировать структурированный ответ для агента, да, структурированный ответст через output. Ещё одно свойство, конечно, важное, да, для моделей, но которые умеют работать с инструментами, они умеют и поддерживать strк через topt, это уметь возвращать результаты и обрабатывать их в JSON формате. Ну, в данном случае у нас JSON возвращает наш инструмент. Вот такая функция в а коде питона, которая будет вызываться.

А как агент её получает? Давайте посмотрим на код создания самого, в общем-то, агента. Вот он. А здесь наш, а create lm start agent. И здесь у нас, а, последовательно, да, мы вначале там собираем конфиг промпта, системный промт, а модель вытаскиваем из конфига с параметрами. Дальше сформируем саму языковую LM модель чаi. Задаём ей модель температуру. Формируем массив инструментов. Ну, нас сейчас интересуют здесь вот два локальных инструмента, а, которые у нас непосредственно в этом проекте, да, а реализованы они в MCP-сервере, то есть, а, это RCK search и вот get current daytime, вспомогательный инструмент для получения, а, данных о времени. Дальше мы вот код с MCP мы сейчас с вами пропускаем, где мы подтягиваем дополнительный инструментарий для работы с нашей там CRM системой из MCP. Аа определяем чекпоинтер место, где мы будем хранить историю переписки, будем хранить её в памяти Memory Saver. Ну и дальше определяем набо набор midлве, а который тоже нам сейчас не сильно принципиальны для обсуждения рак составляющей. и вызываем метод create agent, а, в котором мы уже, а, передаём ему созданную нашу высшеязыковую модель, массив инструментов, системный промт, а, где мы храним контекст переписки и набор вот этих midleвя, а, расширений нашего агента. Вот таким образом мы построим своего основной граф своего агента, который впоследствии мы уже будем непосредственно вызывать аа и запускать, да, командой там стрима получения результата от агента. А вот так вот так вот выглядит непосредственно код самого агента.

И а мы с вами м хотели запустить нашего бота. Давайте мы его запустим теперь. Сделаем командочку Мойкран. А команда, да, а запускает нашего бота, запускает за процесс вначале, а конфигурации, да, какая модель используется, какой retrieval режим гибрид раun используется, да, какой провайдер, а какая-модель, какие у нас настройки семантического поиска и поиска полнотекстового, какая модель для кросс-энкодера используется, сколько у нас топрезультатов заращается после ранкера, а запускается процесс индексации, да, старт full реиндексинг. происходит у нас всей базы. Найдено четыре, соответственно, PDF-документа, разбиты на чанке. 154 чанка сформировано, по ним сформированы бединги, они загружены в векторную базу, произведён всё или индекс завершён. Аа дальше создаются все необходимые нам ретриверы. И процесс индексации завершается. А всё, наш бот. А дальше в него подгружаются все инструменты, которые у него существуют. Midlev. И log нам сообщает, что бот наш готов. для работы и демонстрации. Он создаст новый аэ сеанс диалога с нами, очистит всю историю и попросим его. Скажи, пожалуйста, а есть ли у вас успешные кейсы создания и ассистентов для агросектора? И спросим, есть ли успешные кейсы для аграриев. М, и да, он нам отвечает, что есть успешный кейс создание ассистента для агросектора, для компании. 5.000 плюс сотрудников. Вот информация вытащена из источника такого-то, да? Раньше мы эту информацию нам бот не показывал. У нас было отключено для режима работы с клиентами, да, поскольку им не хотимо им светить наши файлы, а вот для такого отладочного режима, своего режима, для работы, ну, это очень как бы полезно, а, её иметь и показывать.

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

Давайте посмотрим вживую. Так, вот мы перешли в Landsmit. А здесь, а, ну, на главной странице мы открываем вначале наш, а, соответственно, непосредственно проект. А вот AI Dialog Life Bot, который у нас с вами работает. И здесь у нас отображаются вот эти трейсы. То есть каждый запрос отправляем языковой модели. Он здесь отображается. Вот последний у нас был запрос. Да, скажи, пожалуйста, а есть ли у вас успешные кейсы? Аэ, создание ассистентов для агросектора. Нам информация поступила на вход. Мы видим, да, что весь этот цикл исполнения занял у нас, а, 5.000, а, токенов, потому что там история, наверно. Так, а, ну да, довольно большой был объём информации. Здесь истории у нас не было, но, в общем-то, в деньгах это совсем там незначительные какие-то, а, тысячные центов. И, а, в ответ модель вызывала инструмент RSARCH с запросом кейсы ассистенты, агросектор. Эзультат, а, вызова инструментов вернул ей вот такие вот а источники. Соответственно, а в Source у нас был портфолио, но оттуда было возвращено несколько чанков и ассистент главного агронома, интеллектуальный ассистент для консультантов, а, соответственно, дополнительной информации. И видим мы, соответственно, финальный потом ответ и ассистента, который был, а, выдан нам уже непосредственно нашим агентам всем. А вот такую информацию здесь мы, а, собирали, как бы получали. можно посмотреть отдельно output, соответственно, а-а, с дополнительными полями, да, где вот у нас ведётся подсчёт вызову количество моделей, инструментов и так далее. Но я даже вам хотел сейчас ещё показать на сам цикл, что здесь интересно. Можно посмотреть весь, а, вот этот вложенный там граф выполнения, а, либо в виде такого водопада, да, либо в виде диаграммы, а, такой пост таймлайна, да, и где можно посмотреть, сколько времени занимал каждый кусочек. То есть первый вызов модели, когда она принимала решение, да, что ей нужно вызвать, а, непосредственный инструмент ей, а, вот можно посмотреть, что на вход этой модели поступило. Описание инструментов rockarch, вот с тем самым нашим описанием, да, всех инструментов. В общем-то, такое же описание ей было предоставлено. И системный промт ей был предоставлен, вот наш системный промт, который мы с вами смотрели. И также, соответственно, запрос наш пользовательский. На выходе она приняла решение, что ей нужно вызвать такой-то инструмент с таким-то как бы непосредственно запросом. Внизу можно посмотреть на метанформацию и увидеть, да, что вот эти тулы - это на самом деле вот, ну, по сути, это же Jonструктура, где каждый инструмент был передан ей вот в списке инструментов, доступных следующим описанием. А-а, соответственно, дальше мы видим, а, вызов инструментов наших, а, tools. Мы видим вызов инструмента нашей Rockсёarch. Это же в нашем Python, да, коде, в нашем приложении был проведён вызов, поиск информации, и в таком формате возвращён результат. Ну, видим, даже вложено, как он выполнялся, да, какие операции там, а, в нём проходили уже непосредственно внутри, та выполнялся поиск, а, соответственно, по векторному, по БМ-25 с объединение результатов поиска. Ну, и в конечном итоге результат этого выполнения раксёрча был передан опять в а чат Open AI, нашу языковую модель. И видим, да, что вот у нас опять же всё приходит тоже описание инструментов, там системный промт к ней приходил, а плюс контекст переписки в неё пришёл наш запрос. Дальше запрос модели вызвать инструмент rсеch и ответ от этого инструмента. Ну и, соответственно, модель уже приняла решение, что ей больше никаких инструментов высывать не надо, отдала вот финальный ответ, который мы с вами увидели в боте. Вот он здесь. Причём видим здесь, да, здесь у нас как бы ничего не маскировалось. портфолио мы не маскировали никаким образом, а замаскировали это только на выходе уже непосредственно в боте с помощью вот дополнительных midleвеy, которые мы с вами будем, а потом разбирать в следующем видео.

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

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

Но для оценки а непосредственно метрик, э, мы используем для оценки рак пайплайна метрики от библиотеки Рагаз. Это метрика Faithfulness. Она определяет, что у нас там нет галлюцинации, да, что ответ сформирован на основе полученного контекста. Answer relevancy, что, соответственно, ответ он, а, соответствует заданному вопросу, то есть он по теме answer correctness, что в целом наш ответ совпадает с эталоном, ну, и с учётом а вытащенного контекста. И есть несколько метрик, которые направлены чисто на способность извлекать систему информации. Это контекст recall. нашли ли нужные документы, то есть достаточна ли полнота а всех документов, которые были найдены для того, чтобы сформировать ответ на заданный вопрос, и нет ли ени среди нет и среди них лишних какие-то избыточных документов. Для оценки вот этих метрик РАГАС использует подход LM judge. А то есть даже не для всех этих метрик нужны эталонные ответы. Для части из них они не требуются. Аз judge подход использовать другую языковую модель для того, чтобы сформировать суждения и выставить некую вот этот скор оценку конкретному аа ну эксперименту. Здесь по сути важно, чтобы использовать для этого модель, а которая из другого семейства моделей, поскольку там, ну, одна и та же семейство это принято считать, что может слишком как бы лояльно оценивать, а результаты работы моделей своего же семейства. Ну, например, если мы используем агенте, в агенте у нас Open AI, да, модельки, то там судьей может быть клод и наоборот.

А запуск эксперимента в самой нашей системе, в программном коде, он происходит из, а, вот, модуля Evoluation P, который был, а, нами написан там, сгенерирован с курсором. А, и состоит он из следующих этапов. Мы вначале м загруженый, да, ранее в Landsmit datasсеet. Мы посмотрим потом вживую, как он там выглядит. А мы, соответственно, его туда загрузили. Ему присвоили имя. И дальше, когда мы запускаем какой-то прогон эксперимента, да, когда мы сделали какое-то изменение нашего пайплайна, точечное изменение, а мы хотим проверить, как оно повлияет на финальное качество, мы запускаем уже непосредственно эксперимент. Для каждого вопроса из датасета у нас вызывается наш агент. А как в боте, да, он формирует, соответственно, ответ. И у нас ответ плюс найденные документы, а, которые были добавлены в контекст, они, а, сохраняются в лонгсмите и в трейсах, и там в результатах, получается, эксперимента. Дальше мы запускаем, а, потоковую, да, аа, вычисление метрик для каждой вот этого полученного, сгенерированного ответа. Считается вот набор метрик, который вот здесь выше мы с вами как бы смотрели, разбирали. И после этого мы привязываем вот эти оценки, сделанные, а, вычисленные нашим, а-а, Арогаз, а, модулем, обратно в Landsmit. Мы их загружаем, а, как, э, оценки вот конкретного трейса, конкретного эксперимента. И они впоследствии уже удобно хранятся и отображаются в той платформе Long Smith, где мы можем их между собой сравнивать, работать, строить дэшборды, оценивать качество.

Ну, давайте перейдём и посмотрим теперь на, в общем-то, результаты. Так, для этого нам с вами понадобится а открыть а нашего а-а проект. Давайте я вам покажу, как выглядит на самом деле вот сгенерированный датасет. Он здесь небольшой, синтезированный, всего восемь вопросов. А, соответственно, в нём содержится, а, groundof ответа и контекста, куда который должен быть, а, там в идеале получен для того, чтобы по заданному вопросу вот такой ответ был сформирован, да. Весь этот как бы цикл у нас был написан генерация синтеза файли модуля Dasset Synthizer. А, ну, в общем-то, алгоритм мы его с вами смотрели. А, был системный промт модельки задан, а, которая занималась, а, синтезом. Вот следующий. Ты эксперт по созданию вопросо ответных систем. Вопрос должен быть реалистичным, конкретным на русском языке, сформулирован, стиль простой. Для вопроса создавать краткий точный ответ на основе текста, а как будто бы он задаётся клиентом и так далее, да? То есть такие вот важные аспекты здесь были учитаны. Это должен быть вопрос, который мы за новыми клиентами, которые интересуются кейсами. Прежде чем сформулировать вопрос, представь себя на месте клиента, подумай, мог бы пользователь задать такой вопрос, достаточно ли у него сведений. Верни только валидное джисон. Ну, дополнительная там инструкция была. И да, вот таким проптом мы по сути шли по детесету и создавали отдельные пары вопросов-ответов. А-а, так дальше был сформирован вот этот вот gsonфайл и по команде, а там боте загрузить datсеet происходила его загрузка в lнmit. В ЛНсмите это выглядит следующим образом. У нас есть вкладка датасеты эксперименты и мы видим наш эксперимент AI Dialog о и наш datasсеet AI Dialx dataset. А вот он был загружен и создан в нашем коде. А здесь можно посмотреть экзамплы, примеры. Ну, то есть, по сути, те восемь аа строк, которые мы были нами синтезированы, что они из себя выглядят. Ну, здесь тот самый инпут и референсный output. Плюс дополнительно есть какая-то метадата, из какого источника он был получен.

Так, и самое интересное уже дальше это в запуске экспериментов. А запускали мы их, а-а, соответственно, три раза конфигурировали наш бот, а разными параметрами, а-а, и получали, соответственно, разные результаты. Ну вот параметры у нас у бота, да, какие есть оракретри, соответственно, три mode, либо семантический, либо гибридный, либо гибридный с реранкером. И настройки вот какого количества чанков получать на семантическом, на полнотекстовом поиске. А какую использовать Кроэнкоoder модель? Сколько получать после реранкера отдельно? А какие имбединг модели а можно и нужно использовать, да, для соответственно вычисления векторов? Какие использовать а языковые модели а для работы с нашим приложением? Ну мы види экспериментировали с разными Openроутерами и с Openем и с Вайвоксом, а провайдером. И соответственно отдельно есть настройки для эвалюuшена. Вот какая модель рогасом должна использоваться. Абединг модель какая? Ну, соответственно, там какой провайдер. А таким образом мы меняли эти параметры и сделали несколько экспериментов. Давайте посмотрим на их результаты. Что мы видим? У нас есть эксперимент рак сенtтик топ- оди. А мы запустили там самым первым. И, в общем-то, всего один чанкл выбирал, только сематический поиск использовался. И вот получили, соответственно, вот следующие результаты, да. Answer корректность 0,48. Answer similarity - это прямое сходство ответа эталонного со сгенерированным без джаджа. Просто векторная близость считается. И, соответственно, видим, что вот контекст, полнота найденной информации, их достоверность и точность, она самая низкая у этого эксперимента. А следующий эксперимент - это был у нас гибридный поиск, где у нас по пять чанков находилось, а у нас уже сильно подросли, а, соответственно, вот значения, да. получается контекст precision, контекст recall и достоверность найденной информации. А когда мы подключили, эти показатели, у нас контекст precision вырос ещё больше, поскольку ранкер как бы отсёк среди найденной все информации, те, которые не менее релевантны к заданному вопросу. А, ну давайте зайдём в внутрь каждого эксперимента. Здесь мы можем посмотреть, в общем-то, компактном режиме, да, а конкретно запуск, э, там каждого прогона увидеть здесь довольно, а, вот такие показатели, да, красные, когда мы всего по одному чанку вытаскивали, да, и система определяла, что этого чанка недостаточно для формирования ответа. Но поскольку тема наша довольно общая и система модель используется умная, да, то, в общем-то, она умудрялась даже найденной информации дать ответ, который там по по смыслу похож заданному а референсному groundтс ответу эталонному. И можно посмотреть похожие вещи вот, а и по аналогии в в другом эксперименте. Здесь мы видим, у нас уже меньше таких а проколов, да, контекста у нас недостаточно найдено. И это вот основное основной вообще триггер для оценки качества раксистем - это смотреть не только на answer similarрити, да, оценку, то есть сходство с эталоном, а который не учитывает, был сгенерирован ответ на основе найденной информации или он был выдан из параметрической памяти, она этого просто никак не посмотрит. Важно всегда смотреть на вот метрики, связанные с поиском, с контекстом, полнотой, точностью и правдоподобностью. И если они низкие, да, это признак, что здесь моделька где-то, а, что-то додумывала, может быть, сгаллюционировала, вообще на основе своей параметрической памяти ответила. Это надо учитывать. Если вот метрика answer correctрект, она в целом учитывает и то, и то, а, но в большей степени она считает, конечно, answer similarity, ей даётся больше приоритет а в совокупной метрике, чем метрикам, связанными с поиском. Поэтому они тоже могут быть не сильно наглядны. Но мы с вами не будем сейчас заниматься ручным анализом, а, вот этих всех датацетов, каждой конкретно эксперимента. Это делать нужно, полезно и интересно, но мы же с вами, а, всё-таки про ядрин говорим, технологию, поэтому мы перейдём в курсор.

И, мм, тут есть, на самом деле, два способа. А, один способ, аэ, сказать, с которого начну, это руками можно выгрузить, а, из ЛНсмита все результаты наших экспериментов, да. А, соответственно, там в CSV можно выгрузить вот каждый результат эксперимента полностью. Делается это в экспериментах. Мы можем выбрать все наши эксперименты, нажать кнопочку КМП сравнить и вот отсюда кнопочкой download SCSV выгрузить все по сути результаты каждого эксперимента с их метриками. Ну и в целом это удобная интерфейс для такого ручного сравнения. Вот таким образом мы выгрузили эту этот CS-файл. И дальше мы включили, на самом деле, а так мы включили нашку курсор и попросили его провести анализ, аэ, соответственно результатов, выступить экспертом, провести анализ э вот этих данных, которые здесь мы выгрузили. Нужен подробный отчёт. Объясни причины отличия результатов, объясничения метрик, исключительные, примечательные случаи, там, аномалии и так далее. А, и давайте посмотрим на результат анализа, который нам представил. Итак, а, соответственно, сразу ТldR сеtic топ 1 провален. Мы это видели, да, с recallл 0,25. Гибрид плюс ранкел. Реранкер лучший по качеству контекста. Критическая проблема была выявлена. Один вопрос не находит контекст ни в одном из трёх пайплайнов. А, описывается конфигурация экспериментов, которая она была запущена. А, соответственно, вот три эксперимента с нарастающей сложностью ретри стратегии. Сводная таблица метрик приведена, критично низкие подсвечено и лучшие результаты. А объясняется вот тот самый правильно, а, расчёт метрик, каким образом они рассчитываются, да? Вот корректность, то что я вам говорил, она совокупная, да, и по похожести answer similarity, и по а контекстрекола считается совпавшим фактом, а answer relevancy, answer similarity, как это рассчитывается, как считается context precision, context recall. Всё это здесь разбирается и проводится сравнительный анализ. Главный, да, момент подсвечивается, что сеtic находил релевантный контекст лишь для двух из восьми вопросов. В шести случаях единственный чанк оказывался нерелевантным. Переход гибрид топ-5 радикально исправляет ситуацию. Рекол вырастает до 0,875. БМ25 вот в том числе компенсирует случаи, где семантический поиск промахивается из-за электрической специфики. А ранкер улучшает prision, то есть точность, да, поскольку оба варианта вот этих гибридного поиска а извлекают одни и те же документы. Рекол у них одинаковый, но ранкер работает после извлечения. И, соответственно, его вклад - это переупорядовать найденные чанки и prision точность их вырастает. То есть в контексте не попадают ненужные чанки. Почему Answer relevancy Answer similarity почти не меняются? Эти метрики измеряют качество самого ответа lm, а не Retrieval. У нас там использовался ГПТ1. Она достаточно умна, чтобы давать семантически близкие ответы даже на неполном контексте. Отсюда высокий answer similarity. А даже при умеренном корректность, то есть при умеренном при умеренном найденном, а, вот этом чанках качестве их и разбор аномалий вот конкретного случая, когда у нас был запрос там связанный про Telegramбл, где мы не находилась никакая информация, но ответ давался. Ретрил провалился во всех трёх пайплайнах вероятные причины сематический разрыв. Запрос говорит и агенты Чан говорит формирование соглашений. БМ-25 тоже промахнулся. Чанк, возможно, разрезан на границе слов и потерял ключевые термины. Можем мы посмотреть непосредственно этот, давайте его посмотрим. О, вот он здесь. Ну и мы видим, на самом деле, чанк был вытащен, а, соответственно, как распользователь Telegramботы, да. Вот, вот такой чанг здесь был вытащен, и он был недостаточен для того, чтобы дать корректный ответ. Что делать? открыть PDF, найти тему пять, проверить, как она разрезана в индексе. Вероятно, чанк начинается с середины страницы, увеличить чанк Overlap, а от пересечения вот то самое чанков, чтобы заголовок тем попадал в оба соседних чанк. Альтернатива, ну, добавить ещё другие техники формирования, а, чанков. Одна из них гипотетил докумен формировать гипотетические документы вокруг чанка добавить Q1 как регрессионный тест pipeline, чтобы фиксировать момент, когда ретри начнёт его доходить. Ну отдельно вот прямо выделить этот тест. Так. Дальше. Аномалия 2. Оценка качества Falness ноль. Semantic топ не нашёл контекст. Лм ответила уверенно. Рогас не нашёл ни одного факта из этого ответа. А в контексте опасно, что звучит правдоподобно. ЛМ упомянуло реальное название, добавила деталь и всё это полностью не полностью выдумано, на самом деле системном промте частично было. Вот. А поэтому она как бы в целом выкрутилась и ответила достаточно хорошо. Ну таким образом, видите, можно разбирать аномалии, сформировать понятную, удобную сводку и получить рекомендации, что делать дальше, а как улучшать свой пайплайн.

Но мы с вами поговорили про оценку качества, и давайте переходить к завершению. Что мы разобрали с вами в этой части? видео. Посмотрели мы с вами, как вообще создавать дримы подходы, такие проекты последовательно, итерационно, да, чтобы они были, а, сопровождаемые, адекватные, понятные. Как создавать агента с памятью, как задавать системный промт, как описывать инструменты лучшей практики, как создать рак. Аа, разобрали три вариации пайплайна. А как проиндексировать, синтезировать датасеты для оценки качества, в том числе. как их мониторить, а заметь, посмотреть, а работу, стоимость, размеры в токенах и как измерять качество нашего, а агента в целом. В следующей части мы с вами поговорим про MCP инструменты, как строить MCP-сервер и подключать их к агенту, как внедрять техники Human in the Loop, да, для подтверждения критичных операций, а про техники отдельно безопасности, а, соответственно, защиты от промнъекции, фильтрации входной-выходной информации, защиты от всяких способов атак, а-а, и выхода нашего агента в какие-то бесконечные циклы. и проверим качество уже не только рак составляющей, а в целом всей траектории работы нашей агента, способность его правильно выбирать, нужные инструменты для конкретных случаев и ситуаций. Поэтому подписывайтесь, следите за выходами нового видео. Ну а больше информации про иагентов и кодинг мы рассказываем в нашем Telegram-канале. А по запросам внедрения и и в ваш бизнес, разработки и агентов обращайтесь в Telegram Смирнов Ий. А за услугами тренингов, курсов, корпоративных, личных переходите на сайт llmstart.ru. На сайте lmstart.ru можно ознакомиться не только с нашими кейсами и портфолио и услугами, но также выбрать а подходящий вам курс, а либо для быстрого старта и кодинга и агентов, либо для формирования полной траектории, да, развития по Driven Fullstке и по промышленной разработке prodдак ready и агентов. в том числе с продвинутыми техниками. Это всё у нас обёрнуто в комбопредложение, которое будет представлять для вас такую единую траекторию роста пофстре разработке и и агентов. Переходите, подписывайтесь. До новых встреч, друзья. M.