Don't learn AI Agents without Learning these Fundamentals

За последние несколько лет с ИИ произошло многое. Промпт-инжиниринг, контекст, окна, токены, эмбеддинги, RAG, векторные БД, MCPS, агенты, LangChain, LangGraph, Claude, Gemini и многое другое. Если вы чувствовали себя обделенным, это единственное видео, которое вам нужно посмотреть, чтобы наверстать упущенное. В этом видео мы предполагаем, что вы ничего не знаете, и пытаемся объяснить все эти концепции через один проект, чтобы к концу вы перешли от нуля к общему пониманию всего, что происходит с ИИ. Мы начнем с основ ИИ, затем перейдем к RAG, векторным БД, LangChain, LangGraph, MCP, промпт-инжинирингу и, наконец, соберем все вместе в полную систему.

Давайте начнем с основ. Когда вы задаете вопрос модели ИИ, на него обычно отвечает подмножество ИИ, называемое большими языковыми моделями. Большие языковые модели стали популярны примерно тогда, когда в конце 2022 года был выпущен ChatGPT, когда мы начали видеть, как языковые модели увеличиваются в размерах из-за их очевидных преимуществ в производительности. Итак, давайте копнем немного глубже, чтобы понять, как большие языковые модели могут обрабатывать запросы, которые мы отправляем. Популярные LLM, такие как OpenASGPT, Anthropic's Claude и Google's Gemini, являются трансформерными моделями, обученными на больших наборах данных. Размер обучающих токенов может достигать десятков триллионов токенов, которые используются для обучения этих моделей. А обучающие данные включают данные из тысяч различных областей, таких как здравоохранение, право, программирование, наука и многое другое. Но когда мы работаем в 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 и агентом. Когда вы напрямую используете большие языковые модели, такие как GPT, Claude и Gemini, вы используете их как статичный мозг, который может отвечать на вопросы на основе своих обучающих данных. Агент, с другой стороны, обладает автономией, памятью и инструментами для выполнения любой задачи, которую он считает необходимой для выполнения вашего запроса. Для сценария поддержки клиентов TechCorp представьте, что клиент спрашивает: "Какова политика вашей компании в отношении возврата моего продукта, который прибыл поврежденным?" Агент самостоятельно определит, как ответить на этот запрос, автономно, вместо традиционного программного обеспечения, которое требует условных операторов, определяющих, как должна выполняться программа.

LangChain поставляется с обширными готовыми компонентами, которые берут на себя основную работу для чат-бота TechCorp. Модели чата LangChain обеспечивают прямой доступ к поставщикам LLM. Вместо написания пользовательского кода интеграции API вы можете настроить OpenAI с помощью `model=GPT3 turbo`. Таким образом, если требования изменятся на использование Anthropic вместо этого, вы просто измените одну строку: `LLM = ChatAnthropic(model="claude-3-sonnet")`. Этот же шаблон применяется ко всем другим возможностям, которые нужны TechCorp. Управление памятью использует `MemorySaver` для автоматического сохранения и извлечения истории чата, что означает отсутствие необходимости создавать собственную схему базы данных или управление сеансами. Интеграция векторной базы данных работает через стандартизированные интерфейсы. Независимо от того, выберете ли вы Pinecone или ChromaDB, LangChain предоставляет согласованные API, и мы рассмотрим, что такое векторная база данных, в следующих нескольких главах. Для текстовых эмбеддингов он использует OpenAI Embeddings или аналогичные компоненты для преобразования документов TechCorp в векторное представление. Процесс эмбеддинга становится вызовом одной функции вместо ручного управления соединениями API и преобразованиями данных. Наконец, интеграция инструментов позволяет агенту получать доступ к внешним системам. Таким образом, если вам нужно запросить базу данных клиентов TechCorp, вы можете просто создать инструмент, который агент может вызвать, когда определит, что требуется информация, специфичная для клиента. Без LangChain вам пришлось бы создавать всю эту инфраструктуру самостоятельно: управление API для нескольких поставщиков LLM, векторные базы данных, SDK, конвейеры эмбеддингов, логику семантического поиска, управление состоянием, систему памяти и маршрутизацию инструментов. Сложность растет экспоненциально. Библиотека компонентов LangChain включает модули, такие как соединения API Anthropic для чата, операции векторной базы данных ChromaDB, эмбеддинги OpenAI для преобразования текста в векторы, MemorySaver для управления историей чата, определения пользовательских инструментов для интеграции с внешними системами. Агент оркестрирует эти компоненты на основе контекста разговора. Таким образом, когда мы говорим о 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, где мы отправляем сообщения и получаем сообщения, как в чате. Лаборатория объясняет три роли в разговоре: система, пользователь и ассистент, и как выглядит формат запроса в Python. Это подводит нас к задаче 3. Здесь мы открываем скрипт, раскомментируем строки, определяющие модель, роль и контент, а затем настраиваем его. Таким образом, ИИ представляет себя. Как только мы запустим скрипт, если все правильно, ИИ должен ответить введением. Это первый реальный вызов модели. Далее мы переходим к пониманию структуры объекта ответа. Лаборатория разбивает путь ответа, показывая, как мы углубляемся в ответ, выборы, содержимое сообщения, чтобы извлечь фактический текст, возвращаемый ИИ. Хотя объект ответа содержит другие поля, такие как использование, статистика и временные метки, в большинстве случаев нам действительно нужно поле содержимого. Это подводит нас к задаче 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% сокращение кода. Вторая задача демонстрирует поддержку мультимоделей. Здесь нам предлагается настроить три поставщика: OpenGPT4, Gemini от Google и Gro от XAI, все с одним и тем же классом и структурой. После настройки мы можем запустить один и тот же промпт через все из них и сравнить их ответы. Это особенно мощно, когда вам нужно провести 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, вам обычно требуется выполнить некоторый поиск по сходству, например, `SELECT * FROM documents WHERE content LIKE '%vacation%' OR content LIKE '%vacation policy%'` с подстановочным знаком до и после, чтобы найти детали о вопросах, касающихся праздников. Чтобы расширить набор результатов, вы можете увеличить область действия, добавив `VA` или `VAC space P`. Однако недостатком этого подхода является то, что он возлагает на человека, ищущего данные, ответственность за правильное форматирование поискового запроса. Но что, если бы был другой способ хранения данных? Что, если бы вместо хранения по значению мы хранили смысл этих слов? Таким образом, когда вы ищете в базе данных, отправляя сам вопрос: "Могу ли я взять отгул в праздник?", на основе смысла слов, содержащихся в вопросе, база данных возвращает только релевантные данные. Это суть того, что пытаются решить векторные базы данных: хранение данных по эмбеддингам. Таким образом, вместо поиска по значению, мы теперь можем искать по смыслу. Популярные реализации векторных баз данных включают Pinecone и Chroma. Эти платформы разработаны для обработки эмбеддингов в масштабе и обеспечивают эффективное извлечение на основе семантического сходства. И это также отличные сценарии использования для быстрого прототипирования.

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

Другая важная концепция — размерность. И вы можете спросить: "Почему я должен беспокоиться о размерности? Разве я не могу просто загрузить слова в эмбеддинг и сохранить их в базе данных?" Есть еще один аспект эмбеддинга, о котором вам нужно подумать, и это размерность. Обычно слово не имеет одного значения для изучения. Например, слово "отпуск" может иметь разные семантические значения в зависимости от контекста, в котором оно используется. И захват всех этих тонкостей, таких как тон, формальность и другие особенности, может придать этим словам богатство. Обычно используемые сегодня размеры — 1536 измерений, что является хорошим сочетанием, не создавая слишком большой нагрузки по размеру, но при этом обеспечивая достаточный контекст для глубины каждого поиска. Как только эмбеддинг сохранен с правильной размерностью, есть два других основных аспекта, которые нам нужно учитывать при работе с векторными базами данных. И это сторона извлечения. То есть, теперь, когда мы храним смысл этих слов, мы должны взять на себя бремя извлечения эмбеддингов. Поскольку мы не выполняем поиск, как в SQL, с помощью запроса `WHERE`, нам нужно принять решение о том, что технически будет считаться совпадением и насколько. Это делается путем рассмотрения оценки и перекрытия фрагментов. И если вы сейчас задаетесь вопросом: "Кажется, это много настройки, чтобы использовать векторную базу данных", то это серьезный компромисс, который вы должны учитывать при использовании векторной базы данных, а именно то, что, хотя правильно настроенная векторная база данных делает поиск намного более гибким, правильная настройка векторной базы данных часто добавляет сложность на начальном этапе. Поэтому, имея это в виду, оценка — это порог, который вы устанавливаете для того, насколько похожими должны быть результаты, чтобы считаться правильным совпадением. Например, слово "Флорида" может иметь некоторое сходство со словом "отпуск", поскольку люди часто туда ездят в отпуск. Но вопрос "Могу ли я взять свой рабочий ноутбук во Флориду?" сильно отличается от "Разрешает ли моя компания отпуск во Флориду?". Поскольку один спрашивает о политике в области ИТ-юрисдикции, а другой — о политике отпусков. Таким образом, установка порогового значения оценки на основе вопроса может помочь вам ограничить низкие сходства, которые считаются совпадением.

Хорошо, есть еще один финальный аспект, который называется перекрытием фрагментов. В SQL мы привыкли хранить вещи построчно, но в векторных базах данных все выглядит немного иначе. Когда мы храним значения в векторных базах данных, они часто разбиваются на фрагменты при вводе в базу данных. Таким образом, когда мы разбиваем весь справочник сотрудника на фрагменты, возможно, что смысл также разбивается вместе с ним. Вот почему мы допускаем перекрытие фрагментов, чтобы контекст переливался, оставляя достаточно поля для правильной работы поиска. В этом приложении мы будем создавать движок семантического поиска шаг за шагом. История начинается с TechDoc Inc., где пользователи ищут документацию 10 000 раз в день. Но более половины этих поисков терпят неудачу. Почему? Потому что традиционный поиск по ключевым словам не может связать "сбросить пароль" с "процессом восстановления пароля". Наша миссия — исправить это, создав систему поиска, которая понимает смысл, а не только слова. Мы начинаем с настройки среды. На этом этапе нам предлагается установить библиотеки, которые делают векторный поиск возможным: Sentence Transformers для эмбеддингов, LangChain для оркестрации, ChromaDB для векторной базы данных и несколько утилит, таких как NumPy. После установки мы проверяем настройку с помощью предоставленного скрипта. Если все проверено, мы готовы двигаться дальше. Далее мы уделим время пониманию эмбеддингов. Это основа семантического поиска. Вместо того, чтобы рассматривать тексты как слова, эмбеддинг преобразует текст в числовые векторы. Схожие смыслы оказываются близко друг к другу в этом математическом пространстве. Это означает, что "забыл пароль" и "восстановление учетной записи" выглядят очень по-разному в словах, но почти идентично в векторе. Это магия, которая позволяет нашему поисковому движку преуспеть там, где поиск по ключевым словам терпит неудачу. Это подводит нас к задаче номер один, где мы применяем эмбеддинги на практике. Мы открываем скрипт, инициализируем модель MiniLM, кодируем как запросы, так и документы, а затем вычисляем сходство с помощью косинусного сходства. Запуск скрипта демонстрирует, как поиск "забыл пароль" успешно совпадает с "восстановлением пароля", показывая семантическое понимание в реальном времени.

Как только мы поймем эмбеддинги, мы перейдем к сегментации документов. Большие документы нельзя эмбеддировать сразу. Поэтому нам нужно разделить их на более мелкие фрагменты, но если мы режем слишком грубо, мы теряем контекст. Вот почему перекрывающиеся фрагменты важны. Они сохраняют смыслы между границами. Например, установка размера фрагмента в 500 символов с перекрытием в 100 символов может улучшить точность извлечения почти на 40%. LangChain помогает нам делать это разумно. В задаче номер два мы применяем это на практике, редактируя скрипт для импорта рекурсивного текстового разделителя символов LangChain и установки параметров сегментации. Запуск скрипта подтверждает, что наши документы теперь разделены на перекрывающиеся части, готовые к хранению. Следующая концепция, которую мы исследуем, — это векторные хранилища. Сами по себе эмбеддинги — это просто числа. Нам нужна система для их эффективного хранения и поиска. Вот где вступает в игру Chroma. Это готовая к производству векторная база данных, которая может обрабатывать миллионы эмбеддингов, выполнять поиск по сходству за миллисекунды и поддерживать фильтрацию метаданных. В задаче номер три нам предлагается создать векторное хранилище с помощью ChromaDB. Мы импортируем необходимые классы, настраиваем модель эмбеддингов и затем запускаем скрипт. После подтверждения у нас есть рабочее векторное хранилище, которое может принимать документы и извлекать их семантически. Наконец, мы объединяем все вместе с помощью семантического поиска. Здесь мы реализуем полный конвейер: преобразуем запрос пользователя в эмбеддинг, ищем в хранилище Chroma, извлекаем наиболее релевантные фрагменты документов и возвращаем их пользователю. Например, запрос, такой как "политика работы из дома", теперь правильно выведет руководство по удаленной работе. В задаче 4 мы настраиваем запрос, устанавливаем количество возвращаемых верхних результатов и устанавливаем порог для оценок сходства. Запуск скрипта проверяет наш поисковый движок от начала до конца. Лаборатория завершается подведением итогов. Мы начали с неисправной системы поиска по ключевым словам, где 60% поисков терпели неудачу. По пути мы узнали об эмбеддингах, умной сегментации документов, векторных хранилищах и семантическом поиске. В конце мы создали готовый к производству поисковый движок с 95% успешностью. Некоторые более глубокие эксперименты, такие как настройка размеров фрагментов, тестирование различных моделей эмбеддингов и добавление фильтров метаданных, оставлены для вашего самостоятельного изучения.

Итак, возможно ли, чтобы вместо поиска по всему 500 ГБ документов ИИ-ассистент мог поместить их в свое контекстное окно и генерировать вывод? Это называется RAG, или Retrieval Augmented Generation (генерация с дополненным извлечением). Допустим, ваша компания использовала ИИ-ассистента для ответа на этот вопрос: "Какова наша политика удаленной работы для международных сотрудников?" Чтобы понять, как работает RAG, нам нужно разбить ее на три простых шага: Retrieval (извлечение), Augmented (дополнение) и Generation (генерация). Начиная с извлечения, точно так же, как мы преобразуем документ в векторные эмбеддинги для их хранения в базе данных, мы выполняем тот же шаг для вопроса: "Какова наша политика удаленной работы для международных сотрудников?". Как только сгенерирован эмбеддинг этого вопроса, эмбеддинг этого вопроса сравнивается с эмбеддингами документов. Этот тип поиска называется семантическим поиском, где вместо поиска по статическим ключевым словам для поиска релевантного контента используется смысл и контекст запроса для сопоставления с существующим набором данных. Переходя к дополнению, RAG относится к процессу, при котором извлеченные данные вставляются в промпт во время выполнения. И вы можете подумать: "Почему это так особенного?" Обычно ИИ-ассистенты полагаются на то, что они узнали во время предварительного обучения, что является статичным знанием, которое может устареть. Вместо этого наша цель — чтобы ИИ-ассистент полагался на актуальную информацию, хранящуюся в векторной базе данных. В случае RAG результаты семантического поиска добавляются к промпту, который, по сути, служит дополненным знанием. Таким образом, для вашей компании ИИ-ассистенту предоставляются детали из документов компании, которые являются реальными, актуальными и частными данными. И все это может произойти без необходимости дообучать или изменять большую языковую модель с пользовательскими данными. Последний шаг RAG — генерация. Это шаг, на котором ИИ-ассистент генерирует ответ, учитывая семантически релевантные данные, извлеченные из векторной базы данных. Таким образом, первоначальный промпт, который гласит: "Какова наша политика удаленной работы для международных сотрудников?", ИИ-ассистент теперь продемонстрирует свое понимание базы знаний вашей компании, используя документы, относящиеся к удаленной работе и политике. И поскольку первоначальный промпт указывает критерий "международные сотрудники", шаг генерации будет использовать свое собственное рассуждение, чтобы разобраться с предоставленными данными, чтобы наилучшим образом ответить на вопрос.

Теперь RAG — это очень мощная система, которая может мгновенно улучшить глубину знаний за пределами ее обучающих данных. Но, как и любая другая система, обучение калибровке — это приобретенный навык, который необходимо освоить, чтобы получить наилучшие результаты. Настройка системы RAG будет отличаться от одной системы к другой, потому что она сильно зависит от набора данных, который вы пытаетесь хранить. Например, юридические документы потребуют различных стратегий сегментации, чем документ с транскриптами поддержки клиентов. Это связано с тем, что юридические документы часто имеют длинные структурированные абзацы, которые необходимо сохранить нетронутыми. В то время как разговорные транскрипты могут быть вполне приемлемы с сегментацией на уровне предложений с высоким перекрытием для сохранения контекста. В этой лаборатории мы выводим нашу систему семантического поиска на новый уровень, добавляя генерацию с помощью ИИ. До сих пор мы могли находить релевантные документы с высокой точностью. Например, сопоставляя "политику удаленной работы" при поиске "работы из дома". Но генеральный директор хочет большего. Вместо извлечения документа система должна фактически отвечать на вопросы пользователя напрямую. Что-то вроде: "Да, вы можете работать три дня из дома", а не просто показывать PDF. Мы начинаем с настройки среды. На этом этапе нам предлагается активировать среду Python и установить ключевые библиотеки. К ним относятся ChromaDB для векторного хранения, Sentence Transformers для эмбеддингов в LangChain с интеграциями для OpenAI и Hugging Face. После установки мы проверяем все с помощью предоставленного скрипта, чтобы убедиться, что фреймворк RAG готов. Далее мы переходим к задаче номер один, настройке векторного хранилища. Здесь мы инициализируем клиент ChromaDB, создаем нашу коллекцию `techcorp_rag` и настраиваем модель эмбеддингов `all-MiniLM-L6-v2`. Здесь мы получаем нашу систему памяти. Место, где все документы нашей компании будут храниться в виде векторов, чтобы мы могли искать их семантически. В задаче номер два фокус смещается на обработку и сегментацию документов. В отличие от нашей предыдущей лаборатории, где мы разбивали текст на фрагменты фиксированного размера по символам, здесь мы переходим к сегментации на основе абзацев с умными перекрытиями. Цель — сохранить смысл, чтобы каждый фрагмент содержал полные мысли. Это имеет решающее значение для RAG, потому что, когда ИИ генерирует ответы, качество зависит от наличия связных фрагментов контекста. Оттуда мы переходим к задаче номер три, интеграции LLM. Здесь мы подключаем модель OpenAI `GPT-4.1-Mini`. API-ключ и базовый URL уже предварительно настроены для нас. Нам просто нужно установить параметры генерации, такие как температура, максимальное количество токенов и значения top_p. После интеграции мы можем протестировать простую генерацию текста, прежде чем накладывать этапы извлечения и дополнения. Задача номер четыре вводит промпт-инжиниринг для RAG. Нам предлагается создать структурированный шаблон промпта, который всегда гарантирует включение контекста. Системный промпт четко указывает, что ответы должны поступать только из извлеченных документов. Если информация отсутствует в контексте, ИИ должен ответить: "У меня нет этой информации в предоставленных документах". Это сохраняет наши ответы фактическими и предотвращает галлюцинации. Наконец, мы доходим до задачи номер пять, полного конвейера RAG. Здесь мы связываем все вместе. Поток заключается в следующем: эмбеддинг запроса пользователя, поиск в Chroma, извлечение трех верхних фрагментов, создание контекстно-зависимого промпта и генерация ответа с использованием LLM. Финальный штрих — атрибуция источника. Каждый ответ указывает на документ, из которого он был получен. Это превращает систему в полноценный готовый к производству Q&A движок. В конце мы отмечаем мастерство RAG. То, что начиналось как простой поиск документов, превратилось в мощную систему, которая извлекает, дополняет и генерирует ответы. Это та же архитектура, которая лежит в основе таких инструментов, как ChatGPT, Claude и Gemini. Некоторые части, такие как эксперименты с различными стратегиями сегментации, уточнение промптов, оставлены для вашего самостоятельного изучения.

Теперь, когда мы рассмотрели концептуальные элементы 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 для генерации отчета. И одна последняя концепция, которую следует помнить, помимо узлов и ребер, — это общий состояние между каждым узлом. Это возможно с использованием графа состояний, который по сути хранит информацию на протяжении всего рабочего процесса. Например, `class ComplianceState(TypedDict): topic: str documents: List[str] current_document: Optional[str] compliance_score: Optional[int] gaps: List[str] recommendation: List[str]` может использоваться для узлов, которые мы определили ранее. По мере прогрессирования рабочего процесса каждый узел обновляет соответствующие переменные состояния. Узел 1 заполняет `documents` найденными файлами политики. Узел 2 обрабатывает отдельные документы и обновляет `current_document`. Узел 3 рассчитывает `compliance_score`. Узел 4 выявляет `gaps`. Узел 5 генерирует `recommendation`. Граф состояний оркестрирует выполнение на основе настроенного потока. Если узел 3 определяет, что оценка соответствия ниже 75%, условное ребро направляет обратно к узлу 1 для сбора дополнительных документов. Если оценка превышает 75%, выполнение переходит к узлу 5 для окончательной генерации отчета. Как видите, это создает мощные возможности: циклы для итеративного анализа, условное ветвление на основе промежуточных результатов, постоянное состояние, которое сохраняет контекст на протяжении всего рабочего процесса. Таким образом, для помощника по соответствию TechCorp LangGraph является важным инструментом для автоматизации рабочих процессов.

Итак, давайте начнем с лабораторий. В этой лаборатории мы погружаемся в LangGraph, фреймворк, предназначенный для создания состоятельных многошаговых рабочих процессов ИИ. В отличие от простых цепочек, LangGraph дает нам точный контроль над тем, как перемещаются данные, позволяя нам создавать ветвящуюся логику, циклы и точки принятия решений. К концу этого путешествия мы построим полноценного исследовательского ассистента, который сможет разумно использовать несколько инструментов. Мы начинаем с настройки среды. На этом этапе мы активируем виртуальную среду Python и устанавливаем необходимые библиотеки: сам LangGraph, LangChain и интеграцию с OpenAI. Как только все установлено, мы запускаем скрипт проверки, чтобы убедиться, что наша настройка готова. С готовой средой мы начинаем с малого. Задача номер один знакомит нас с необходимыми импортами. Мы импортируем `StateGraph` и `END` и `TypedDict` для определения данных, которые перемещаются по рабочему процессу. Затем мы добавляем простое поле состояния для сообщений. Это основа. `StateGraph` содержит рабочий процесс и отмечает завершение, а состояние содержит общие данные. В задаче номер два мы создаем наши первые узлы. Узлы — это просто функции Python, которые принимают состояние в качестве входных данных и возвращают частичные обновления. В данном случае мы определяем узел приветствия и узел улучшения. После соединения один узел выводит базовое приветствие, а следующий узел улучшает его с некоторой изюминкой. Это демонстрирует, как состояние накапливается шаг за шагом. Задача номер три посвящена ребрам. Соединения между узлами. Здесь мы используем `add_node` и `add_edge`, чтобы соединить узел приветствия с узлом улучшения. С этим мы построили наш первый мини-рабочий процесс. Данные перемещаются из одной функции в другую. Состояние обновляется по пути. В задаче номер четыре мы идем дальше с многошаговым потоком. Мы добавляем новые узлы, такие как шаг черновика и шаг проверки. Соединяем их и видим, как данные перемещаются через несколько этапов. Каждый шаг сохраняет состояние, добавляет детали и передает их дальше. Это имитирует реальные конвейеры, где контент набрасывается, составляется и полируется. Задача номер пять вводит условную маршрутизацию. Вместо фиксированного потока система теперь решает динамически. Например, если запрос короткий, он маршрутизируется одним путем. Если подробный, он маршрутизируется другим. Маршрутизатор проверяет состояние и возвращает имя следующего узла, делая рабочие процессы гибкими и адаптивными. Затем идет задача номер шесть, интеграция инструментов. Здесь мы добавляем калькулятор. Маршрутизатор проверяет, является ли запрос

связанные с математикой. Если так, то он направляется к узлу калькулятора, который вычисляет ответ. Это наш первый взгляд на то, как 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 на самом деле, поскольку обычно о нем говорят как о простом "подключи и работай", и вы правы, думая так. Разница здесь в том, что этот код сервера 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, но и для того, как любой другой бизнес может раскрыть полную ценность своих знаний с помощью агентов.