Don't learn AI Agents without Learning these Fundamentals

За последние несколько лет с ИИ произошло многое. Промпт-инжиниринг, контекст, окна, токены, эмбеддинги, RAG, векторные БД, MCPS, агенты, LangChain, LangGraph, Claude, Gemini и многое другое. Если вы чувствовали себя обделенным, это единственное видео, которое вам нужно посмотреть, чтобы наверстать упущенное. В этом видео мы предполагаем, что вы ничего не знаете, и пытаемся объяснить все эти концепции через один проект, чтобы к концу вы прошли путь от нуля до общего понимания всего, что происходит с ИИ. Мы начнем с основ ИИ, затем перейдем к RAG, векторным БД, LangChain, LangGraph, MCP, промпт-инжинирингу, и, наконец, соберем все вместе в полную систему. Давайте начнем с основ. Когда вы задаете вопрос модели ИИ, на него обычно отвечает подмножество ИИ, называемое большими языковыми моделями. Большие языковые модели стали популярны примерно тогда, когда в конце 2022 года был выпущен ChatGPT, когда мы начали видеть, как языковые модели увеличиваются в размерах из-за их очевидных преимуществ в производительности. Итак, давайте копнем немного глубже, чтобы понять, как большие языковые модели могут обрабатывать запросы, которые мы отправляем. Популярные LLM, такие как OpenASGPT, Claude от Anthropic и Gemini от Google, являются трансформерными моделями, обученными на больших наборах данных. Размер обучающих токенов может достигать десятков триллионов токенов, которые используются для обучения этих моделей. А обучающие данные включают данные из тысяч различных областей, таких как здравоохранение, право, программирование, наука и многое другое. Но когда мы работаем в TechCorp, 500 ГБ данных, которые у нас есть, не являются частью обучающих данных, которые использовались для обучения модели, что означает, что для того, чтобы мы могли использовать LLM для вопросов о внутренних документах TechCorp, нам нужна возможность передавать данные в LLM. Один из способов передать данные в модель — добавить их в историю разговора, которая действует как кратковременная память, где в течение всего разговора весь этот контекст хранится в памяти. И эта память называется контекстным окном. Контекстные окна измеряются в токенах, что составляет примерно 3/4 слова для английского текста. Контекстное окно обычно ограничено по размеру, и верхний предел зависит от модели. Некоторые модели, такие как XAI GO 4, имеют 256 000 токенов, в то время как Claude Opus 4 от Anthropic имеет 200 000 токенов, а Gemini 2.5 Pro от Google — 1 миллион токенов. Таким образом, как вы можете видеть, общий верхний предел того, сколько контекста может храниться для каждой модели, может варьироваться. Хотя контекстное окно играет важную роль в хранении их в памяти, существуют практические ограничения в том, как LLM обрабатывает содержимое контекстного окна. Например, если бы я попросил вас запомнить цифры числа Пи 3.141592653589791 и попросил вас продиктовать их, некоторым из вас могло бы быть трудно запомнить столько чисел сразу, что похоже на то, как работает контекстное окно LLM. Таким образом, здесь кроются текущие ограничения LLM. Сколько контекста оно может удерживать в данный момент? Это может варьироваться от модели к модели. Например, многие модели nano, mini и flash могут иметь очень маленькие контекстные окна размером от 2000 до 4000 токенов, что составляет примерно от 1500 до 3000 слов. И наоборот, более крупные модели, такие как GPT4.1 и Gemini 2.5 Pro, предлагают контекстные окна до 1 миллиона токенов, что эквивалентно примерно 7500 словам или 50 000 строкам кода. Таким образом, как вы можете видеть, выбор правильной модели для задачи может быть очень важным. Например, если вы скачали роман в формате txt и хотели изменить сценарий, выбор модели, предлагающей большое контекстное окно, был бы лучшим. И наоборот, если вы работаете с небольшим документом и вам требуется очень низкая задержка, то есть более быстрые ответы, лучше использовать варианты flash и nano. Вот еще один угол зрения на память в LLM. Допустим, я задам вам этот вопрос. Салли и Боб владеют яблочной фермой. У Салли 14 яблок. Яблоки часто бывают красными. 12 — хорошее число. У Боба нет красных яблок, но у него есть два зеленых яблока. Зеленые яблоки часто невкусные. Сколько всего яблок у них? Это может потребовать от вас немного подумать над проблемой, чтобы получить окончательный ответ, который составляет 16. Это потому, что контекст здесь включает информацию, которая совершенно не имеет отношения к вопросу, который заключается в подсчете общего количества яблок, которое у них есть. Тот факт, что яблоки красные или зеленые, или каковы их вкусовые качества, не имеет никакого отношения к общему количеству яблок, которое у них есть, потому что они либо имеют яблоко, либо нет. Теперь, когда мы понимаем, что предоставляет контекстное окно, 500 ГБ документов TechCorp, это создает немедленную проблему. Даже самое большое контекстное окно, такое как 1 миллион токенов Gemini 2.5 Pro, может вместить только около 50 файлов типичных деловых документов одновременно. Нам нужна модель ИИ, которая понимает все 500 гигабайт, но она может видеть только крошечную часть в данный момент. Здесь вступают в игру эмбеддинги, и их абсолютно важно понять. Эмбеддинги трансформируют способ, которым мы думаем об информации. Вместо хранения текста в виде слов, мы преобразуем смысл в числа. Предложения "политика отпусков сотрудников" и "руководство по отгулам персонала" используют совершенно разные слова, но они означают по сути одно и то же. Эмбеддинги улавливают это семантическое сходство. И вот как это работает. Модель эмбеддингов берет текст и преобразует его в вектор. Обычно это 1536 чисел, которые представляют смысл. Схожие концепции в итоге имеют схожие числовые закономерности, например, "отпуск" и "праздник" будут иметь векторы, математически близкие друг к другу. Для TechCorp это означает, что мы можем находить релевантные документы на основе того, что кто-то имеет в виду, а не только на основе точного слова, которое он использовал. Когда сотрудник спрашивает: "Могу ли я носить джинсы на работу?", наша система найдет политику дресс-кода, даже если в ней никогда не упоминается слово "джинсы". Теперь, когда мы понимаем, как работают LLM и эмбеддинги, нам понадобится система, которая свяжет все воедино. В нашем случае TechCorp нуждается в чат-боте, где клиенты могут задавать вопросы о политике компании, информации о продуктах и проблемах поддержки. Чат-бот должен помнить историю разговоров, получать доступ к базе знаний компании и обрабатывать сложные многошаговые взаимодействия. Вашим первым инстинктом может быть использование SDK OpenAI для создания быстрого интерфейса чата. Но вы быстро поймете, что есть огромные недостающие части. Хранение сообщений чата, поддержание контекста разговора, подключение к внутренней базе знаний TechCorp и обработка возможности того, что компания может перейти от OpenAI к Anthropic или Google в будущем. И теперь то, что казалось простым проектом, становится огромной задачей. Хотя вы можете написать свою собственную реализацию для их подключения, уже существует хорошо зарекомендовавший себя уровень абстракции под названием Langchain. Langchain — это уровень абстракции, который помогает вам создавать ИИ-агентов с минимальным кодом. Он решает все эти проблемы, используя готовые компоненты и стандартизированные интерфейсы. Но сначала давайте поймем ключевое различие между LLM и агентом. Когда вы напрямую используете большие языковые модели, такие как GBT, Claude и Gemini, вы используете их как статичный мозг, который может отвечать на вопросы на основе своих обучающих данных. Агент, с другой стороны, обладает автономией, памятью и инструментами для выполнения любой задачи, которую он считает необходимой для выполнения вашего запроса. Для сценария поддержки клиентов TechCorp представьте, что клиент спрашивает: "Какова политика вашей компании в отношении возврата моего продукта, который прибыл поврежденным?" Агент самостоятельно определит, как ответить на этот запрос, автономно, вместо традиционного программного обеспечения, которое требует условных операторов, определяющих, как должна выполняться программа. Langchain поставляется с обширными готовыми компонентами, которые выполняют тяжелую работу для чат-бота TechCorp. Модели чата Langchain обеспечивают прямой доступ к поставщикам LLM. Вместо написания пользовательского кода интеграции API вы можете настроить OpenAI с помощью открытой скобки model = GPT3 turbo. Поэтому, если требования изменятся и потребуется использовать Anthropic, вы просто измените одну строку LLM = chat_anthropic(model = claude_3_sonnet). Эта же модель применяется ко всем другим возможностям, которые нужны TechCorp. Управление памятью использует memory_saver для автоматического хранения и извлечения истории чата, что означает отсутствие необходимости создавать собственную схему базы данных или управление сессиями. Интеграция векторной базы данных работает через стандартизированные интерфейсы. Независимо от того, выберете ли вы Pine Cone или Chroma DB, Langchain предоставляет согласованные API, и мы рассмотрим, что такое векторная база данных, в следующих нескольких главах. Для текстовых эмбеддингов он использует OpenAI embeddings или аналогичные компоненты для преобразования документов TechCorp в векторное представление. Процесс эмбеддинга становится одним вызовом функции вместо ручного управления подключениями к API и преобразованиями данных. Наконец, интеграция инструментов позволяет агенту получать доступ к внешним системам. Поэтому, если вам нужно запросить базу данных клиентов TechCorp, вы можете просто создать инструмент, который агент может вызвать, когда он определит, что требуется информация, специфичная для клиента. Без Langchain вам пришлось бы создавать всю эту инфраструктуру самостоятельно. Управление API для нескольких поставщиков LLM, векторные базы данных, SDK, конвейеры эмбеддингов, логика семантического поиска, управление состоянием, система памяти и маршрутизация инструментов. Сложность растет экспоненциально. Библиотека компонентов Langchain включает модули, такие как подключения к API Anthropic для чата, операции с векторной базой данных Chroma, эмбеддинги OpenAI для преобразования текста в векторы, memory_saver для управления историей чата, определения пользовательских инструментов для интеграции с внешними системами. Агент оркестрирует эти компоненты на основе контекста разговора. Поэтому, когда мы говорим о TechCorp, в зависимости от того, какой вопрос задан, агент теперь будет использовать предоставленные инструменты, такие как векторные базы данных, а также контекст, который он построил из памяти разговора и системного промпта, написанного на уровне API, автономно обрабатывать ваш запрос, и вы можете расширить возможности агента за пределы этого примера, используя другие готовые инструменты, которые предлагает Langchain, такие как доступ к пользовательским базам данных, поиск в Интернете, доступ к локальной файловой системе и многое другое. Теперь, когда мы рассмотрели концептуальные элементы Langchain, давайте посмотрим, как это выглядит на практическом уровне. Мы можем взглянуть на эту лабораторию, специально предназначенную для того, как использовать Langchain. Итак, давайте начнем с лабораторий. В этой лаборатории мы исследуем, как совершать ваши первые вызовы API ИИ. Миссия здесь — провести вас от абсолютного нуля до возможности подключаться, вызывать и понимать ответы от API OpenAI всего за несколько последовательных шагов. Мы начинаем с проверки нашей среды. На этом этапе нас просят активировать виртуальную среду. Проверить, установлен ли Python. Убедиться, что библиотека OpenAI доступна, и подтвердить, что наши API-ключи установлены. Это важно, потому что без этой основы ничего другого не будет работать. Как только проверка пройдет успешно, лаборатория подтвердит, что среда готова. Далее мы уделим время пониманию того, что такое OpenAI. Здесь нас знакомят с компанией, стоящей за ChatGPT, и их семейством моделей ИИ, включая GPT4, GPT4.1 Mini и GPT 3.5. В повествовании подчеркивается, что мы будем работать с библиотекой Python OpenAI, которая действует как мост между нашим кодом и сервером OpenAI. С установленным контекстом мы переходим к задаче 1. В этой задаче нас просят открыть скрипт Python и завершить недостающие импорты. В частности, нам нужно импортировать библиотеку OpenAI и библиотеку OS. После завершения этих строк мы запускаем скрипт, чтобы убедиться, что библиотеки правильно установлены и готовы к использованию. Если все правильно, программа подтвердит, что импорт прошел успешно. Отсюда мы переходим к аутентификации и настройке клиента. Здесь лаборатория объясняет важность API-клиента, API-ключа и базового URL. API-ключ работает как пароль, который идентифицирует нас и предоставляет доступ, а базовый URL определяет местоположение сервера, куда отправляются запросы. Это подготавливает нас к задаче 2. В задаче 2 мы открываем другой скрипт Python и нас просят инициализировать клиент, вставив правильные переменные среды. Это включает в себя обеспечение того, чтобы мы передали OpenAI API key и OpenAI API base. Как только эти значения будут заполнены, мы запускаем скрипт, чтобы проверить, что клиент был правильно инициализирован. Если все сделано правильно, скрипт подтвердит подключение к серверам OpenAI. После завершения настройки мы переходим к сути лаборатории — совершению вызова API. Прежде чем приступить к этому, мы узнаем, что такое завершения чата. Это разговорный API OpenAI, где мы отправляем сообщения и получаем сообщения, как в чате. Лаборатория объясняет три роли в разговоре: System, User и Assistant, и как выглядит формат запроса в Python. Это подводит нас к задаче 3. Здесь мы открываем скрипт, раскомментируем строки, определяющие модель, роль и контент, а затем настраиваем его. Таким образом, ИИ представляет себя. Как только мы запустим скрипт, если все правильно, ИИ должен ответить введением. Это первый реальный вызов модели. Далее нас направляют к пониманию структуры объекта ответа. Лаборатория разбивает путь ответа, показывая, как мы углубляемся в response, choices, message content, чтобы извлечь фактический текст, возвращенный ИИ. Хотя объект ответа содержит другие поля, такие как usage, statistics и timestamps, в большинстве случаев нам действительно нужен только поле content. Это подводит нас к задаче 4, где нас просят обновить скрипт, чтобы извлечь ответ ИИ, используя точный путь. Запуск скрипта здесь подтверждает, что мы можем успешно захватить и отобразить текст, который возвращает ИИ. Как только мы освоим совершение вызовов и извлечение ответов, лаборатория переходит к токенам и затратам. Мы узнаем, что токены — это части текста, используемые моделью, и каждый запрос потребляет токены. Токены промпта — это то, что мы отправляем. Токены завершения — это то, что ИИ отправляет обратно, а общие токены — это сумма обоих. Важно отметить, что выходные токены дороже входных. Поэтому краткость может сэкономить деньги. Наконец, в задаче 5 нас просят извлечь значения использования токенов, промпт, завершение и общие токены из ответа. Скрипт уже настроен для расчета затрат. Поэтому, как только мы завершим извлечение и запустим его, мы сможем точно увидеть, сколько стоил вызов API. Лаборатория завершается поздравлением. На данный момент мы проверили нашу среду, подключились к OpenAI, совершили реальные вызовы API, извлекли ответы и рассчитали затраты. Ключевой вывод — запомнить, как перемещаться по объекту ответа с помощью response.content. Некоторые более тонкие моменты и детали, такие как изучение полей использования или эксперименты с различными моделями, оставлены для вашего самостоятельного изучения. Но к этому моменту у вас должна быть прочная основа для работы с API ИИ, и вы готовы к тому, что будет дальше в предстоящих лабораториях. Итак, давайте начнем с лабораторий. В этой лаборатории мы исследуем Langchain и поймем, как он делает работу с несколькими поставщиками ИИ проще и быстрее. Ключевая идея здесь заключается в том, что вместо того, чтобы быть привязанным к SDK одного поставщика и переписывать код при каждом переключении, Langchain предлагает один интерфейс, который работает везде. С его помощью вы можете перейти от OpenAI к Gemini от Google или Gro от XAI, изменив всего одно слово. Мы начинаем с проверки среды. На этом этапе нас просят запустить скрипт, который проверяет, установлены ли Langchain и его зависимости, проверяет наши API-ключи и базовый URL, а также подтверждает, что у нас есть доступ к различным поставщикам моделей. Как только эта проверка пройдет, мы готовы начать экспериментировать. Первый тест сравнивает традиционный подход SDK OpenAI с Langchain. Нам приходится писать 10 или более строк шаблонного кода, чтобы просто совершить вызов API. Если мы хотим переключиться на другого поставщика, нам придется переписать все это. С Langchain та же логика сокращается до трех строк. А переключение поставщиков так же просто, как изменение имени модели. В этой задаче нас просят завершить обе версии в скрипте, а затем запустить их бок о бок. Именно здесь мы действительно видим 70% сокращение кода. Вторая задача демонстрирует поддержку мультимоделей. Здесь нас просят настроить три поставщика: Open GPT4, Gemini от Google и Gro от XAS, все с одинаковым классом и структурой. После настройки мы можем запустить один и тот же промпт через все из них и сравнить их ответы. Это особенно мощно, когда вам нужно провести A/B тестирование или сбалансировать затраты, потому что вы можете мгновенно оценить несколько моделей, не меняя структуру кода. В третьей задаче нас знакомят с шаблонами промптов. Вместо написания отдельных жестко закодированных промптов для каждого варианта, мы создаем один многоразовый шаблон с заполнителями. Затем мы можем динамически заполнять переменные, как f-строки в Python. Это устраняет кошмар поддержания сотен слегка отличающихся файлов промптов. После завершения шаблона мы тестируем его с несколькими входными данными, чтобы увидеть, как одна и та же структура генерирует различные ответы. Четвертая задача идет дальше, вводя парсеры вывода. Часто ответы ИИ — это просто свободный текст, но то, что действительно нужно нашему коду, — это структурированные объекты. Здесь нас просят добавить парсеры, которые могут преобразовывать ответы в списки или JSON-объекты. Таким образом, вместо того, чтобы иметь дело с неструктурированными предложениями, мы можем получить доступ к чистым спискам Python или словарям, которые наше приложение может использовать напрямую. Наконец, мы доходим до задачи 5, которая посвящена композиции цепочек. Langchain позволяет нам соединять компоненты с помощью оператора конвейера. Подобно конвейерам Unix, вместо написания нескольких переменных для каждого шага, создания промпта, отправки его модели, получения ответа и парсинга результата, мы просто объединяем все вместе. Одной строкой мы можем связать промпты, модели и парсеры, а затем вызвать цепочку, чтобы получить структурированный вывод. Это гораздо более чистый и масштабируемый способ создания конвейеров ИИ. К концу этой лаборатории мы узнали, как Langchain сокращает шаблонный код, обеспечивает гибкость мультимоделей, создает многоразовые шаблоны, парсит структурированные выводы и объединяет все вместе с элегантным цепочечным соединением. Некоторые более тонкие детали, такие как эксперименты с более сложными настройками парсера или цепочки дополнительных шагов, оставлены для вашего самостоятельного изучения. Теперь мы переходим к технике, но это не техника в смысле создания приложения Langchain, как мы только что сделали. Нет, мы говорим о технике, которая включает в себя, как вы отправляете свой промпт агенту, которого мы только что создали. Другими словами, промпт-инжиниринг. Когда вы отправляете промпт в качестве входных данных для ИИ-ассистента TechCorp, который мы только что создали, качество вашего промпта напрямую влияет на качество получаемых ответов. Хотя ИИ-агенты, безусловно, могут обрабатывать широкий спектр промптов, понимание техник промптинга помогает вам более эффективно общаться с системой TechCorp. Например, если вы промптите агента с вопросом "Какова политика?", он может извлечь много деталей, которые не имеют отношения к делу. Отправка более конкретного промпта, такого как "Какова политика компании в отношении удаленной работы для международных сотрудников?", приведет к более точному результату от агента. И то же самое относится к определению роли при описании роли агента. Например, вы можете описательно написать подробный промпт, такой как "Вы эксперт по поддержке клиентов TechCorp". Когда вас спрашивают о политике компании, вы должны всегда отвечать маркированными списками для удобства чтения. Как вы видите, возможность контролировать поведение агента может напрямую выиграть от хорошо написанного промпта. Этот тип техники называется промпт-инжинирингом. И существуют различные техники промптинга, такие как zero-shot, one-shot, few-shot и chain-of-thought prompting, каждая из которых имеет свой сценарий использования для задачи. Например, zero-shot prompting означает, что мы просим ИИ выполнить задачу, не предоставляя никаких примеров. Поэтому, если вы отправляете промпт "Напишите политику конфиденциальности данных для наших европейских клиентов", вы, по сути, полагаетесь исключительно на существующую базу знаний ИИ для написания документа о политике данных. Поскольку в промпте мы не даем никаких примеров того, какими они должны быть. One-shot и few-shot prompting похожи на zero-shot, но в этом случае мы предоставляем примеры того, как агент должен отвечать, непосредственно в промпте. Например, вы можете сказать: "Вот как мы форматируем наши документы о политике. Теперь напишите политику конфиденциальности данных, следуя той же структуре, потому что вы предоставили шаблон". ИИ следует вашим конкретным предпочтениям в форматировании и стиле более последовательно. И наоборот, few-shot learning — это акт обучения со стороны LLM, где, даже если LLM, возможно, не видела точных обучающих данных для обработки вашего уникального запроса, она способна продемонстрировать способность выполнить ваш запрос на основе предоставленных аналогичных примеров. И, наконец, chain-of-thought prompting — это стиль промптинга, при котором вы предоставляете модели последовательность шагов для обдумывания того, как решить конкретную проблему. Например, вместо того, чтобы промптить ИИ-агента "исправьте нашу политику хранения данных", вы можете вместо этого использовать chain-of-thought prompting, чтобы сказать: "Вот как исправить политику хранения данных. Проанализируйте текущие требования GDPR к периодам хранения данных. Затем проанализируйте нашу существующую политику на предмет конкретных пробелов. Затем исследуйте лучшие отраслевые практики для аналогичных компаний. И, наконец, составьте конкретные рекомендации с шагами по внедрению. Теперь исправьте нашу политику в отношении клиентов". Как вы видите, предоставление того, как LLM должна пройти и разбить конкретный запрос на части, как должна быть исправлена политика хранения данных, дает точный план того, как LLM затем должна исправить политику в отношении клиентов, что в данном случае мы не явно говорим агенту, как исправить политику для этого, но это дает шаги рассуждения для модели, чтобы исправить соответственно. Итак, в этой лаборатории мы освоим промпт-инжиниринг с использованием Langchain. Основная проблема, решаемая здесь, заключается в том, что ИИ иногда может давать расплывчатые или непоследовательные ответы или неправильно следовать инструкциям. Решение состоит в использовании структурированных техник промптинга: zero-shot, one-shot, few-shot и chain-of-thought. Каждый из которых по-разному контролирует поведение ИИ. Мы начинаем с проверки среды. Предоставленный скрипт проверяет, установлены ли Langchain и его интеграции с OpenAI, подтверждает, что API-ключ и базовый URL установлены, и гарантирует, что утилиты шаблонов промптов доступны. Как только эта проверка пройдет, мы готовы перейти к задачам. Первая задача знакомит нас с zero-shot prompting. В этом упражнении нас просят сравнить, что происходит, когда мы даем расплывчатую инструкцию, и когда мы пишем очень конкретный промпт. Например, простое указание ИИ написать политику приводит к длинному общему эссе. Но когда мы указываем "Напишите политику конфиденциальности объемом 200 слов, соответствующую GDPR, для европейских клиентов с 30-дневным периодом хранения", ответ становится сфокусированным, полезным и соответствующим ограничениям. Это демонстрирует, почему конкретность имеет решающее значение в zero-shot промптах. Вторая задача переводит нас к one-shot prompting. Здесь мы предоставляем один пример для ИИ, которому нужно следовать, почти как показ одного шаблона. Например, если мы дадим ИИ один пример политики возврата с пятью структурированными разделами, мы можем затем попросить его создать политику удаленной работы, и он повторит тот же стиль и структуру. Это показывает, как один пример может задать тон и обеспечить последовательность во многих выходных данных. Далее, в задаче 3, мы расширяем это с помощью few-shot prompting. Вместо одного примера мы предоставляем несколько примеров, чтобы ИИ мог научиться не только формату, но и тону, закономерностям и стилю. Например, предоставление трех примеров эмфатических ответов поддержки учит модель последовательно обрабатывать проблемы поддержки клиентов. Как только примеры будут на месте, ИИ сможет генерировать новые ответы, которые следуют тому же тону и структуре, что делает его особенно мощным для таких сценариев, как обслуживание клиентов. В задаче 4 нас знакомят с chain-of-thought prompting. Эта техника побуждает ИИ показывать свои рассуждения шаг за шагом. Вместо расплывчатого однострочного ответа, ИИ разбивает проблему на шаги и систематически работает над ней. Это приводит к более четким, более надежным и более точным выходным данным, особенно для сложных задач рассуждения. Наконец, задача 5 объединяет все эти техники в прямом сравнении. Мы запускаем одну и ту же проблему через zero-shot, one-shot, few-shot и chain-of-thought промпты, чтобы увидеть разницу. Каждый подход имеет свои сильные стороны. Zero-shot — быстрый. One-shot обеспечивает форматирование. Few-shot обеспечивает тон и последовательность, а chain-of-thought превосходен в детальных рассуждениях. Результат показывает, что выбор правильной техники может значительно улучшить результаты в зависимости от задачи. К концу этой лаборатории мы не только узнали, что такое каждый метод промптинга, но и увидели их в действии. Ключевой вывод заключается в том, что правильная техника может сделать ваши промпты в 10 раз более эффективными. Некоторые из этих упражнений оставлены для вашего самостоятельного изучения и совершенствования. Но теперь у вас есть основа для принятия решения о том, нужна ли вам скорость, структура, стиль или рассуждение в ваших ответах ИИ. На этом заканчивается это повествование. И с ним вы теперь готовы перейти к следующей лаборатории по векторным базам данных и семантическому поиску. Давайте быстро подведем итоги того, что мы только что построили. Мы узнали, что такое LLM и как LLM используют содержимое контекстного окна. После изучения LLM мы хотели решить бизнес-требования TechCorp по поиску в 500 ГБ данных. Для этого мы определили, что эмбеддинги — это хороший способ поиска огромного набора документов. После этого мы рассмотрели Langchain и его функции, которые заключаются в том, что они позволяют нам легко создавать генерирующие приложения, такие как чат-бот TechCorp. Итак, теперь, когда у нас есть приложение Langchain, нам нужно иметь возможность искать в этих больших наборах документов. Допустим, в 500 ГБ документов ваша компания имеет документ под названием "Справочник сотрудника", который охватывает такие политики, как отгулы, дресс-код и использование оборудования. Сотрудники могут задавать такие термины, как "политика отпусков", но пропускать "руководство по отгулам". Хотя это распространенные вопросы, которые люди обычно задают, создание базы данных на основе этого требования может быть сложным. В традиционном подходе, где данные хранятся в структурированной базе данных, такой как SQL, вам обычно требуется выполнить некоторый поиск сходства, например, "выбрать все из содержимого документов, похожего на отпуск или политику отпусков" с подстановочным знаком до и после, чтобы найти детали о вопросах, касающихся праздников. Чтобы расширить набор результатов, вы можете увеличить область действия, добавив VA или VAC space P. Однако недостатком этого подхода является то, что он возлагает на человека, ищущего данные, ответственность за правильное форматирование поискового термина. Но что, если бы был другой способ хранения данных? Что, если бы вместо хранения по значению мы хранили смысл этих слов? Таким образом, когда вы ищете в базе данных, отправляя сам вопрос, например, "Могу ли я взять отгул в праздник", на основе смысла этих слов, содержащихся в вопросе, база данных возвращает только релевантные данные. Это дух того, что пытаются решить векторные базы данных: хранение данных по эмбеддингам. Таким образом, вместо поиска по значению, мы теперь можем искать по смыслу. Популярные реализации векторных баз данных включают Pinecone и Chroma. Эти платформы разработаны для масштабирования эмбеддингов и обеспечения эффективного извлечения на основе семантического сходства. И это также отличные сценарии для быстрого прототипирования. Хотя концептуально это кажется простым, настройка этого требует некоторого накладного расхода. И вы можете спросить: "Можем ли мы просто загрузить справочник сотрудника в базу данных, как мы только что сделали для базы данных SQL?" Не совсем. И вот почему. В случае с базой данных SQL бремя возлагается на пользователя, ищущего данные, для структурирования базы данных. Но с векторными базами данных бремя возлагается на вас, кто настраивает базу данных, поскольку вы пытаетесь облегчить поиск данных для кого-то. И вы можете представить, почему такой метод становится чрезвычайно популярным в сочетании с большими языковыми моделями в ИИ, поскольку вам не нужно отдельно обучать LLM, как искать вашу базу данных. Вместо этого LLM может свободно искать на основе смысла и быть уверенной, что ваша база данных вернет необходимые релевантные данные. Итак, давайте рассмотрим некоторые ключевые концепции, лежащие в основе настройки базовой векторной базы данных. Начнем с эмбеддингов. Эмбеддинг — это действительно ключевая концепция, которая позволяет перейти от значения к смыслу. В SQL мы храним значения, содержащиеся в справочнике сотрудника, как прямое значение. Но в векторной базе данных вам нужно выполнить некоторую дополнительную работу заранее, чтобы преобразовать значение в семантические смыслы. И эти смыслы хранятся в так называемых эмбеддингах. Например, слова "праздник" и "отпуск" должны семантически иметь общее пространство, поскольку смысл этих слов близок друг к другу. Поэтому, прежде чем предложение "сотрудник не должен брать отгул в праздничные дни" будет добавлено в базу данных, система пропускает его через модель эмбеддингов, и модель эмбеддингов преобразует это предложение в длинный вектор чисел, и когда вы ищете в базе данных, вы фактически сравниваете этот точный вектор. Таким образом, когда кто-то позже спрашивает "Могу ли я взять отпуск во время праздника", даже если формулировка немного отличается, база данных все равно может обслужить запрос. И это фундаментальное изменение. Вместо поиска по точному словесному выражению, мы теперь ищем по смыслу. Другая важная концепция — размерность. И вы можете спросить: "Почему я должен беспокоиться о размерности? Разве я не могу просто загрузить слова в эмбеддинг и сохранить их в базе данных?" Есть еще один аспект в эмбеддингах, о котором вам нужно подумать, и это размерность. Обычно слово имеет не одно значение для изучения. Например, слово "отпуск" может иметь разные семантические значения в зависимости от контекста, в котором оно используется. И захват всех этих тонкостей, таких как тон, формальность и другие особенности, может придать этим словам богатство. Обычно используемые сегодня размеры — 1536 измерений, что является хорошим сочетанием, не создавая слишком большой нагрузки по размеру, но при этом обеспечивая достаточный контекст для глубины каждого поиска. После того, как эмбеддинг сохранен с правильной размерностью, есть два других основных аспекта, которые нам нужно рассмотреть при работе с векторными базами данных. И это сторона извлечения. То есть, теперь, когда мы храним смысл этих слов, мы должны взять на себя бремя извлечения эмбеддингов. Поскольку мы не выполняем поиск, как в SQL с запросом WHERE, нам нужно принять решение о том, что технически будет считаться совпадением и насколько. Это делается путем рассмотрения оценки и перекрытия фрагментов. И если вы на данном этапе задаетесь вопросом: "Это кажется большим количеством настроек, чтобы просто использовать векторную базу данных". И это серьезный компромисс, который вы должны учитывать при использовании векторной базы данных, а именно то, что, хотя правильно настроенная векторная база данных делает поиск намного более гибким, правильная настройка векторной базы данных часто добавляет сложности на начальном этапе. Итак, с учетом этого, оценка — это порог, который вы устанавливаете для того, насколько похожими должны быть результаты, чтобы считаться надлежащим совпадением. Например, слово "Флорида" может иметь некоторое сходство со словом "отпуск", поскольку туда часто ездят в отпуск. Но вопрос "Могу ли я взять свой рабочий ноутбук во Флориду?" сильно отличается от "Разрешает ли моя компания отпуск во Флориду?". Поскольку один спрашивает о политике в области ИТ-юрисдикции, а другой — о политике отпусков. Таким образом, установка порогового значения оценки на основе вопроса может помочь вам ограничить низкие сходства, чтобы они считались совпадением. Хорошо, есть еще один аспект — перекрытие фрагментов. В SQL мы привыкли хранить вещи построчно, но в векторных базах данных все выглядит немного иначе. Когда мы храним значения в векторных базах данных, они часто разбиваются на фрагменты при вводе в базу данных. Поэтому, когда мы разбиваем весь справочник сотрудника на фрагменты, возможно, что смысл также разбивается вместе с ним. Вот почему мы допускаем перекрытие фрагментов, чтобы контекст переливался, оставляя достаточно запаса для правильной работы поиска. В этом приложении мы будем создавать движок семантического поиска шаг за шагом. История начинается с TechDoc Inc., где пользователи ищут документацию 10 000 раз в день. Но более половины этих поисков терпят неудачу. Почему? Потому что традиционный поиск по ключевым словам не может связать "сброс пароля" с "процессом восстановления пароля". Наша миссия — исправить это, создав систему поиска, которая понимает смысл, а не только слова. Мы начинаем с настройки среды. На этом этапе нас просят установить библиотеки, которые делают векторный поиск возможным. Sentence Transformers для эмбеддингов. Langchain для оркестрации. ChromaDB для векторной базы данных и несколько утилитарных библиотек, таких как numpy. После установки мы проверяем настройку с помощью предоставленного скрипта. Если все проверено, мы готовы двигаться дальше. Далее мы уделим время пониманию эмбеддингов. Это основа семантического поиска. Вместо того, чтобы рассматривать тексты как слова, эмбеддинг преобразует текст в числовые векторы. Схожие смыслы оказываются близко друг к другу в этом математическом пространстве. Это означает, что "забыл пароль" и "восстановление учетной записи" выглядят очень по-разному в словах, но почти идентично в векторе 4. Это магия, которая позволяет нашему поисковому движку преуспеть там, где терпит неудачу поиск по ключевым словам. Это подводит нас к задаче номер один, где мы применяем эмбеддинги на практике. Мы открываем скрипт, инициализируем модель miniLM, кодируем как запросы, так и документы, а затем вычисляем сходство с помощью косинусного сходства. Запуск скрипта демонстрирует, как поиск "забыл пароль" успешно соответствует "восстановлению пароля", показывая семантическое понимание в реальном времени. После того, как мы поймем эмбеддинги, мы переходим к сегментации документов. Большие документы нельзя эмбеддировать сразу. Поэтому нам нужно разделить их на более мелкие фрагменты, но если мы режем слишком грубо, мы теряем контекст. Вот почему перекрывающиеся фрагменты важны. Они сохраняют смыслы между границами. Например, установка размера фрагмента в 500 символов с перекрытием в 100 символов может улучшить точность извлечения почти на 40%. Langchain помогает нам делать это разумно. В задаче номер два мы применяем это на практике, редактируя скрипт для импорта рекурсивного текстового разделителя символов Langchain и установки параметров сегментации. Запуск скрипта подтверждает, что наши документы теперь разделены на перекрывающиеся части, готовые к хранению. Следующая концепция, которую мы исследуем, — это векторные хранилища. Сами по себе эмбеддинги — это просто числа. Нам нужна система для эффективного хранения и поиска среди них. Здесь вступает в игру Chroma. Это готовая к производству векторная база данных, которая может обрабатывать миллионы эмбеддингов, выполнять поиск сходства за миллисекунды и поддерживать фильтрацию метаданных. В задаче номер три нас просят создать векторное хранилище с помощью Chroma DB. Мы импортируем необходимые классы, настраиваем модель эмбеддингов и затем запускаем скрипт. После подтверждения у нас есть рабочее векторное хранилище, которое может принимать документы и извлекать их семантически. Наконец, мы объединяем все вместе с помощью семантического поиска. Здесь мы реализуем полный конвейер: преобразуем запрос пользователя в эмбеддинг, ищем в хранилище Chroma, извлекаем наиболее релевантные фрагменты документов и возвращаем их пользователю. Например, запрос, такой как "политика работы из дома", теперь будет правильно выводить руководство по удаленной работе. В задаче 4 мы настраиваем запрос, устанавливаем количество возвращаемых верхних результатов и устанавливаем порог для оценок сходства. Запуск скрипта проверяет наш поисковый движок от начала до конца. Лаборатория завершается кратким обзором. Мы начали с неисправной системы поиска по ключевым словам, где 60% поисков терпели неудачу. По пути мы узнали об эмбеддингах, умной сегментации документов, векторных хранилищах и семантическом поиске. В итоге мы создали готовый к производству поисковый движок с 95% успешностью. Некоторые более глубокие эксперименты, такие как настройка размеров фрагментов, тестирование различных моделей эмбеддингов и добавление фильтров метаданных, оставлены для вашего самостоятельного изучения. Итак, возможно ли, что вместо поиска по всему 500 ГБ документов, ИИ-ассистент сможет вместить их в свое контекстное окно и генерировать вывод? Это называется RAG, или Retrieval Augmented Generation (генерация с дополненным извлечением). Допустим, ваша компания использовала ИИ-ассистента для ответа на этот вопрос: "Какова наша политика удаленной работы для международных сотрудников?" Чтобы понять, как работает RAG, нам нужно разбить его на три простых шага: Retrieval (извлечение), Augmented (дополнение) и Generation (генерация). Начиная с извлечения, так же, как мы преобразуем документ в векторные эмбеддинги для их хранения в базе данных, мы выполняем тот же шаг для вопроса: "Какова наша политика удаленной работы для международных сотрудников?". Как только будет сгенерирован векторный эмбеддинг для этого вопроса, эмбеддинг этого вопроса сравнивается с эмбеддингами документов. Этот тип поиска называется семантическим поиском, где вместо поиска по статическим ключевым словам для поиска релевантного контента используется смысл и контекст запроса для сопоставления с существующим набором данных. Переходя к дополнению, RAG относится к процессу, при котором извлеченные данные вставляются в промпт во время выполнения. И вы можете подумать: "Почему это так особенного?" Обычно ИИ-ассистенты полагаются на то, что они узнали во время предварительного обучения, что является статичным знанием, которое может устареть. Вместо этого наша цель — чтобы ИИ-ассистент полагался на актуальную информацию, хранящуюся в векторной базе данных. В случае RAG результаты семантического поиска добавляются к промпту, который, по сути, служит дополненными знаниями. Таким образом, для вашей компании ИИ-ассистент получает детали из документов компании, которые являются реальными, актуальными и частными данными. И все это может произойти без необходимости дообучать или изменять большую языковую модель с пользовательскими данными. Последний шаг RAG — генерация. Это шаг, на котором ИИ-ассистент генерирует ответ, учитывая семантически релевантные данные, извлеченные из векторной базы данных. Таким образом, первоначальный промпт, который гласит: "Какова наша политика удаленной работы для международных сотрудников?", ИИ-ассистент теперь продемонстрирует свое понимание базы знаний вашей компании, используя документы, связанные с удаленной работой и политикой. И поскольку первоначальный промпт указывает критерий "международные сотрудники", шаг генерации будет использовать свое собственное рассуждение, чтобы разобраться с предоставленными данными, чтобы наилучшим образом ответить на вопрос. Теперь RAG — это очень мощная система, которая может мгновенно улучшить глубину знаний за пределами ее обучающих данных. Но, как и любая другая система, обучение калибровке — это приобретенный навык, который нужно освоить, чтобы получить наилучшие результаты. Настройка системы RAG будет отличаться от одной системы к другой, потому что она сильно зависит от набора данных, который вы пытаетесь хранить. Например, юридические документы потребуют различных стратегий сегментации, чем документ с транскриптами поддержки клиентов. Это связано с тем, что юридические документы часто имеют длинные структурированные абзацы, которые необходимо сохранить нетронутыми. В то время как разговорные транскрипты могут быть вполне приемлемы с сегментацией на уровне предложений с высоким перекрытием для сохранения контекста. В этой лаборатории мы выводим нашу систему семантического поиска на новый уровень, добавляя генерацию с помощью ИИ. До сих пор мы могли находить релевантные документы с высокой точностью. Например, сопоставляя "политику удаленной работы" при поиске "работы из дома". Но генеральный директор хочет большего. Вместо извлечения документа система должна фактически отвечать на вопросы пользователя напрямую. Что-то вроде "Да, вы можете работать три дня из дома", а не просто показывать PDF. Мы начинаем с настройки среды. На этом этапе нас просят активировать среду Python и установить ключевые библиотеки. К ним относятся Chroma DB для векторного хранения, Sentence Transformers для эмбеддингов в Langchain с интеграциями для OpenAI и Hugging Face. После установки мы проверяем все с помощью предоставленного скрипта, чтобы убедиться, что фреймворк RAG готов. Далее мы переходим к задаче номер один: настройка векторного хранилища. Здесь мы инициализируем клиент ChromaDB, создаем нашу коллекцию с именем TechCorpRAG и настраиваем модель эмбеддингов all-MiniLM-L6-v2. Здесь мы получаем нашу систему памяти. Место, где все документы нашей компании будут храниться в виде векторов, чтобы мы могли искать их семантически. В задаче номер два фокус смещается на обработку документов и сегментацию. В отличие от нашей предыдущей лаборатории, где мы разбивали текст на фрагменты фиксированного размера по символам, здесь мы переходим к сегментации на основе абзацев с умным перекрытием. Цель — сохранить смысл, чтобы каждый фрагмент содержал полные мысли. Это имеет решающее значение для RAG, потому что, когда ИИ генерирует ответы, качество зависит от наличия связных фрагментов контекста. Оттуда мы переходим к задаче номер три: интеграция LLM. Здесь мы подключаем модель OpenAI GPT4.1 Mini. API-ключ и базовый URL уже предварительно настроены для нас. Нам просто нужно установить параметры генерации, такие как температура, максимальное количество токенов и значения top_p. После интеграции мы можем протестировать простую генерацию текста перед наложением шагов извлечения и дополнения. Задача номер четыре вводит промпт-инжиниринг для RAG. Нас просят построить структурированный шаблон промпта, который всегда гарантирует включение контекста. Системный промпт четко указывает, что ответы должны поступать только из извлеченных документов. Если информация отсутствует в контексте, ИИ должен ответить: "У меня нет этой информации в предоставленных документах". Это сохраняет наши ответы фактическими и предотвращает галлюцинации. Наконец, мы достигаем задачи номер пять: полный конвейер RAG. Здесь мы связываем все вместе. Поток заключается в следующем: эмбеддинг запроса пользователя, поиск в Chroma, извлечение трех верхних фрагментов, построение контекстно-зависимого промпта и генерация ответа с использованием LLM. Финальный штрих — атрибуция источника. Каждый ответ указывает на документ, из которого он был получен. Это превращает систему в полноценный готовый к производству Q&A движок. В конце мы празднуем мастерство RAG. То, что начиналось как простой поиск документов, превратилось в мощную систему, которая извлекает, дополняет и генерирует ответы. Это та же архитектура, которая обеспечивает работу таких инструментов, как ChatGPT, Claude и Gemini. Некоторые части, такие как эксперименты с различными стратегиями сегментации, уточнение промптов, оставлены для вашего самостоятельного изучения. Но к этому моменту вы построили полную систему RAG, которая отвечает на вопросы с контекстом, точностью и уверенностью. Теперь, когда мы рассмотрели концептуальные элементы RAG, давайте посмотрим, как это выглядит на практическом уровне. Чтобы лучше понять это, мы можем взглянуть на эту лабораторию, специально предназначенную для того, как использовать RAG. Теперь мы рассмотрели основные концепции простого приложения чата, которое позволяет нам общаться с документами, используя векторные базы данных и RAG. Большинство бизнес-кейсов в реальном мире могут быть немного сложнее. Например, в случае TechCorp бизнес-требования могут распространяться на более сложные требования, такие как возможность подключения агента к системе управления человеческими ресурсами для извлечения документов сотрудников для перекрестной проверки и предоставления персонализированных ответов. Однако Langchain имеет ограничения. Когда бизнес-требования становятся более сложными, такими как многошаговые рабочие процессы, условное ветвление или итеративные процессы, вам нужно что-то более сложное для лучшей оркестрации. Вот где LangGraph становится необходимым. LangGraph расширяет Langchain для обработки более сложных многошаговых рабочих процессов, которые выходят за рамки простых взаимодействий "вопрос-ответ". Например, если клиент спрашивает: "Мне нужно понять нашу политику конфиденциальности данных для клиентов из ЕС". Поскольку мы предполагаем, что внутри базы данных объемом 500 ГБ содержатся сведения о нормативных актах ЕС, нам нужно создать систему, которая может анализировать политики конфиденциальности данных TechCorp для клиентов из ЕС, обеспечивая соответствие GDPR, местным нормативным актам и стандартам компании. В традиционной разработке программного обеспечения вам нужно написать код, который может последовательно и условно вызывать различные разделы кода для обработки этого запроса. С LangGraph это становится графом, где каждый узел обрабатывает определенную ответственность. Например, узел 1: поиск и сбор документов о политике конфиденциальности. Узел 2: извлечение и очистка содержимого документа. Узел 3: оценка соответствия GDPR с использованием анализа LLM. Узел 4: перекрестная проверка местных нормативных актов ЕС. И узел 5: выявление пробелов в соответствии и генерация рекомендаций. Узел — это отдельная единица вычислений. Так что думайте о функции, которую вы можете вызвать. Как только все узлы будут созданы в LangGraph, вам нужно будет соединить их, и это соединение называется ребром. Ребра в LangGraph определяют поток выполнения. Например, после того, как узел 1 собирает документы, ребро направляет к узлу 2 для извлечения содержимого. И после того, как узел 3 оценивает соответствие, условное ребро либо направляет к узлу 4 для дополнительного анализа, либо переходит к узлу 5 для генерации отчета. И еще одна финальная концепция, которую нужно помнить, помимо узлов и ребер, — это общее состояние между каждым узлом. Это возможно с помощью графа состояния, который, по сути, хранит информацию на протяжении всего рабочего процесса. Например, класс ComplianceState типа dict, topic string, documents list of string, current_document optional string, compliance_score optional integer, gaps list of string, recommendation list of string может использоваться для узлов, которые мы определили ранее. По мере прогрессирования рабочего процесса каждый узел обновляет соответствующие переменные состояния. Узел 1 заполняет documents найденными файлами политики. Узел 2 обрабатывает отдельные документы и обновляет current_document. Узел 3 рассчитывает compliance_score. Узел 4 выявляет пробелы. Узел 5 генерирует recommendation. Граф состояния оркестрирует выполнение на основе настроенного потока. Если узел 3 определяет, что compliance_score ниже 75%, условное ребро направляет обратно к узлу 1 для сбора дополнительных документов. Если оценка превышает 75%, выполнение переходит к узлу 5 для окончательной генерации отчета. Как вы видите, это создает мощные возможности: циклы для итеративного анализа, условное ветвление на основе промежуточных результатов, постоянное состояние, которое сохраняет контекст на протяжении всего рабочего процесса. Таким образом, для ассистента по соответствию TechCorp LangGraph является незаменимым инструментом для автоматизации рабочих процессов. Итак, давайте начнем с лабораторий. В этой лаборатории мы погружаемся в LangGraph, фреймворк, предназначенный для создания состоятельных многошаговых рабочих процессов ИИ. В отличие от простых цепочек, LangGraph дает нам точный контроль над перемещением данных, позволяя создавать ветвящуюся логику, циклы и точки принятия решений. К концу этого путешествия мы создадим полноценного исследовательского ассистента, который сможет разумно использовать несколько инструментов. Мы начинаем с настройки среды. В этой настройке мы активируем виртуальную среду Python и устанавливаем необходимые библиотеки. Сам LangGraph, Langchain и интеграция с OpenAI. Как только все будет установлено, мы запустим скрипт проверки, чтобы убедиться, что наша настройка готова. С готовой средой мы начинаем с малого. Задача номер один знакомит нас с основными импортами. Мы импортируем StateGraph и TypedDict для определения данных, которые перемещаются по рабочему процессу. Затем мы добавляем простое поле состояния для сообщений. Это основа. StateGraph хранит рабочий процесс и отмечает завершение, а состояние хранит общие данные. В задаче номер два мы создаем наши первые узлы. Узлы — это просто функции Python, которые принимают состояние в качестве входных данных и возвращают частичные обновления. В данном случае мы определяем узел приветствия и узел улучшения. После подключения один узел выводит базовое приветствие, а следующий узел улучшает его с некоторой изюминкой. Это демонстрирует, как состояние накапливается шаг за шагом. Задача номер три посвящена ребрам. Соединениям между узлами. Здесь мы используем add_nodes и add_edges для подключения узлов приветствия к узлу улучшения. С этим мы построили наш первый мини-рабочий процесс. Данные перемещаются из одной функции в другую. Состояние обновляется по пути. В задаче номер четыре мы идем дальше с многошаговым потоком. Мы добавляем новые узлы, такие как шаг черновика и шаг проверки. Соединяем их и видим, как данные перемещаются через несколько этапов. Каждый шаг сохраняет состояние, добавляет детали и передает их дальше. Это имитирует реальные конвейеры, где контент набрасывается, составляется и полируется. Задача номер пять вводит условную маршрутизацию. Вместо фиксированного потока система теперь решает динамически. Например, если запрос короткий, он идет одним путем. Если подробный, он идет другим. Маршрутизатор проверяет состояние и возвращает имя следующего узла, делая рабочие процессы гибкими и адаптивными. Затем идет задача номер шесть: интеграция инструментов. Здесь мы добавляем калькулятор. Маршрутизатор проверяет, является ли запрос

связанное с математикой. Если да, то он направляется к узлу калькулятора, который вычисляет ответ. Это наш первый взгляд на то, как Langraph позволяет нам интегрировать специализированные инструменты непосредственно в рабочие процессы. Наконец, задача номер семь объединяет все в исследовательского агента. Мы объединяем калькулятор с инструментом веб-поиска, таким как duck.go. В зависимости от запроса система решает, выполнять ли вычисление, запускать ли веб-поиск или обрабатывать текст как обычно. Это динамическая оркестровка инструментов, основа современных ИИ-агентов. К концу этой лабораторной работы мы прошли путь от простых импортов до полностью функционального ассистента по исследованиям. Мы увидели, как создавать узлы, соединять их, проектировать многошаговые потоки, добавлять логику маршрутизации и интегрировать инструменты. Некоторые из более глубоких экспериментов, такие как объединение более продвинутых инструментов или уточнение логики маршрутизатора, оставлены вам для самостоятельного изучения. Теперь, когда мы рассмотрели Langchain и Langraph и поняли, как технические бизнес-требования могут быть удовлетворены за счет использования готовых инструментов, которые он предлагает, есть еще один финальный элемент, который стал популярным с момента выпуска Anthropics в ноябре 2022 года, под названием MCP или Model Context Protocol. Ассистент по работе с документами Techorp AI хорошо работает для внутренней базы знаний, но сотрудникам может потребоваться доступ к внешним системам, таким как база данных клиентов, системы поддержки, программное обеспечение для управления запасами и другие сторонние API. А написание пользовательских интеграций для всех этих API-соединений займет огромное количество времени. MCP функционирует как API, но с критическими отличиями, которые делают его идеальным для ИИ-агентов. Традиционные API предоставляют конечные точки, которые требуют от вас понимания деталей реализации, что приводит к жестким интеграциям, привязанным к конкретным системам. MCP не просто предоставляет инструменты. Он предоставляет самоописывающиеся интерфейсы, которые ИИ-агенты могут понимать и использовать автономно. Ключевое преимущество здесь заключается в том, что, в отличие от традиционных API, MCP возлагает бремя на ИИ-агента, а не на разработчика. Таким образом, когда вы запускаете сервер MCP, запускается экземпляр и устанавливается соединение с вашим ИИ-агентом. Например, ассистент по работе с документами Techorp может легко иметь эти серверы MCP для обеспечения мощной интеграции. Допустим, MCP базы данных клиентов. Когда кто-то спрашивает: «Каков статус заказа 1 2 3 4?» ИИ использует MCP для запроса системы управления заказами TechCorb, извлекает текущий статус и предоставляет полный ответ. Та же логика применяется к билетам поддержки, базам данных инвентаризации и системе уведомлений, упомянутым ранее, где мы можем просто подключиться к существующим интеграциям серверов MCP, чтобы позволить агенту расширить свои возможности. Например, мы можем создать очень простой код сервера MCP, который выглядит примерно так. Здесь у нас есть fast MCP customer DB, который запускает сервер MCP с именем customer DB в инструменте MCB, который предоставляет функцию клиентам MCP. ИИ может вызывать как функцию API, параметры и типы возвращаемых значений, которые сообщают клиенту MCP, какие входные данные требуются и какой тип вывода ожидать. Наконец, переменная customers, которая является поддельной базой данных в данном случае, хранится в памяти, но в случае вашей компании вы можете подключить ее к SQL-базе данных, MongoDB или любой другой пользовательской базе данных, на которой вы можете хранить информацию о клиентах. Теперь, глядя на этот код, вы можете запутаться в том, что такое MCP на самом деле, поскольку обычно говорят о нем как о простом plug-and-play, и вы правы, думая так. Разница здесь в том, что этот код сервера MCP, который написан, нужно писать только один раз, и это не обязательно должны быть вы. Другими словами, сообщество разработчиков MCP могло написать пользовательские серверы MCP для других популярных инструментов, таких как GitHub, GitLab или SQL-базы данных, и вы можете просто использовать их напрямую на своем агенте, не написав код самостоятельно. Вот откуда берется сила MCP. В этой лабораторной работе мы углубляемся в MCP, Model Context Protocol, и учимся расширять Langraph внешними инструментами. Думайте о MCP как об универсальном порте, таком как USB, который позволяет ИИ-системам подключаться к любому инструменту, базе данных или API стандартизированным способом. С его помощью наши агенты Langraph могут выходить за рамки встроенной логики и беспрепятственно интегрировать внешние службы. Мы начинаем с этапа настройки среды. На этом этапе мы активируем нашу виртуальную среду и устанавливаем ключевые пакеты. Lang graph для фреймворка рабочего процесса, Langchain для основных абстракций и Langchain OpenAI для интеграции моделей. Настройка также подготавливает fast MCP, фреймворк, который мы будем использовать для создания серверов MCP. После установки мы проверяем, изучив предоставленный скрипт, убедившись, что все готово для разработки MCP. Далее мы получаем концептуальный обзор архитектуры MCP. Здесь в лаборатории объясняется, что протокол MCP действует как мост между ИИ-ассистентом, построенным с помощью Langraph, и внешними инструментами. Поток работает следующим образом. Сервер MCP предоставляет инструменты и схемы. Langraph интегрируется с ними, и запросы маршрутизируются интеллектуально. Соглашение об именовании MCP server tool обеспечивает ясность при работе с несколькими инструментами. Полезная аналогия — сравнение MCP с USB-устройствами. Протокол — это порт. Сервер — это устройство. Инструменты — это его функции. А Langraph — это компьютер, который их использует. Это подводит нас к задаче номер один, основам MCP. Здесь нас просят создать наш самый первый сервер MCP. Задача включает инициализацию сервера под названием calculator, определение функции как инструмента с декоратором @mcp.tool и запуск его с помощью транспорта SCDIO. Это показывает, насколько просто предоставить структурированную функцию как внешний инструмент, который Langraph может затем использовать. В задаче номер два мы интегрируем MCP с Langraph. Задача здесь — подключить сервер калькулятора к агенту. Это включает настройку клиента, получение инструментов с сервера, создание агента React, который может решать, когда вызывать калькулятор, выбранный при необходимости. Далее, задача номер три масштабирует вещи с несколькими серверами MCP. Вместо простого калькулятора мы добавляем еще один сервер, в данном случае — службу погоды. Теперь Langraph оркестрирует между обоими. Система извлекает доступные инструменты, создает агента с доступом к обоим серверам и интеллектуально маршрутизирует запросы. Если пользователь задает математический вопрос, отвечает калькулятор. Если он спрашивает о погоде, отвечает инструмент погоды. Именно здесь мы видим истинную силу MCP. Несколько серверов работают вместе под единым ИИ-агентом. Лабораторная работа завершается празднованием мастерства MCP. К настоящему времени мы создали серверы MCP, интегрировали их с Langraph и оркестровали несколько инструментов. Ключевые выводы заключаются в том, что MCP универсален. Он может подключить любой инструмент к любому ИИ. Маршрутизация — это то, что дает ему силу. Дизайн расширяем, поэтому мы можем добавлять серверы в любое время. Некоторые более глубокие исследования, такие как предоставление баз данных, API или файловых систем через MCP, оставлены вам для самостоятельного изучения. На этом завершается это повествование. Далее мы продолжим путешествие, экспериментируя с предоставлением ресурсов, потоками утверждения с участием человека и, в конечном итоге, развертыванием готовых к производству пакетов MCP. Теперь, когда мы собрали все эти части вместе, такие как контекстные окна, векторные базы данных, Langchain, Langraph, MCP и инженерия подсказок, TechCorp теперь способен выполнять сложный поиск документов, который перешел от ручного поиска, который мог занимать до 30 минут, до менее чем 30 секунд с использованием нашего ИИ-агента. И мы также имеем более высокую точность, используя контекстно-зависимый семантический поиск, такой как RAG. И, наконец, пользовательский интерфейс чат-приложения позволяет пользователям получать большее удовлетворение от работы с инструментом, который может отслеживать историю разговоров и лучше понимать интуицию в целом. И доступность этого составляет 24/7, пока приложение работает. И это только начало. Представьте себе наложение прогнозной аналитики, проактивных агентов по соблюдению нормативных требований и автоматизации рабочих процессов, которые не просто отвечают на вопросы, а активно решают проблемы до того, как сотрудники успеют их задать. Переход от статических документов к живым интеллектуальным системам знаменует собой поворотный момент не только для Tech Corp, но и для того, как любой другой бизнес может раскрыть полную ценность своих знаний, используя агентов.