Transcription
За последние несколько лет с ИИ произошло многое. Промпт-инжиниринг, контекст, окна, токены, эмбеддинги, 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 open bracket model = claw 3 sonnet. Этот же шаблон применяется ко всем другим возможностям, которые нужны TechCorp. Управление памятью использует Memory Saver для автоматического хранения и извлечения истории чата, что означает отсутствие необходимости создавать собственную схему базы данных или управление сессиями. Интеграция векторных баз данных работает через стандартизированные интерфейсы. Независимо от того, выберете ли вы Pine Cone или Chroma DB, Langchain предоставляет согласованные API, и мы рассмотрим, что такое векторная база данных, в следующих нескольких главах. Для текстовых эмбеддингов он использует OpenAI Embeddings или аналогичные компоненты для преобразования документов TechCorp в векторное представление. Процесс эмбеддинга становится вызовом одной функции вместо ручного управления соединениями API и преобразованиями данных. Наконец, интеграция инструментов позволяет агенту получать доступ к внешним системам. Таким образом, если вам нужно запросить базу данных клиентов TechCorp, вы можете просто создать инструмент, который агент может вызвать, когда определит, что требуется информация, специфичная для клиента. Без Langchain вам пришлось бы создавать всю эту инфраструктуру самостоятельно. Управление API для нескольких поставщиков LLM, векторные базы данных, SDK, конвейеры эмбеддингов, логика семантического поиска, управление состоянием, система памяти и маршрутизация инструментов. Сложность растет экспоненциально. Библиотека компонентов Langchain включает модули, такие как соединения API chat Anthropic. Операции с векторной базой данных Chroma, OpenAI Embeddings для преобразования текста в векторы, Memory Saver для управления историей чата, пользовательские определения инструментов для интеграции внешних систем. Агент оркестрирует эти компоненты на основе контекста разговора. Таким образом, когда мы говорим о TechCorp, в зависимости от заданного вопроса, агент теперь будет использовать предоставленные инструменты, такие как векторные базы данных, а также контекст, который он построил из памяти разговора и системного промпта, написанного на уровне API, автономно обрабатывать ваш запрос, и вы можете расширить возможности агента за пределы этого примера, используя другие готовые инструменты, которые предлагает Langchain, такие как доступ к пользовательским базам данных, поиск в Интернете, доступ к локальной файловой системе и многое другое. Теперь, когда мы рассмотрели концептуальные элементы Langchain, давайте посмотрим, как это выглядит на практическом уровне. Мы можем взглянуть на эту лабораторию, специально предназначенную для того, как использовать Langchain. Итак, давайте начнем с лабораторий. В этой лаборатории мы исследуем, как совершать ваши первые вызовы API ИИ. Миссия здесь — провести вас от абсолютного нуля до возможности подключаться, вызывать и понимать ответы от API OpenAI всего за несколько прогрессивных шагов. Мы начинаем с проверки нашей среды. На этом этапе нас просят активировать виртуальную среду. Проверить, установлен ли Python. Убедиться, что библиотека OpenAI доступна, и подтвердить, что наши API-ключи установлены. Это важно, потому что без этой основы ничего другого не будет работать. После успешного выполнения проверки лаборатория подтвердит, что среда готова. Далее мы уделим время пониманию того, что такое OpenAI. Здесь нас знакомят с компанией, стоящей за ChatGPT, и их семейством моделей ИИ, включая GBT4, GBT4.1 Mini и GBT 3.5. В повествовании подчеркивается, что мы будем работать с библиотекой Python OpenAI, которая действует как мост между нашим кодом и сервером OpenAI. С установленным контекстом мы переходим к задаче 1. В этой задаче нас просят открыть скрипт Python и завершить недостающие импорты. В частности, нам нужно импортировать библиотеку OpenAI и библиотеку OS. После завершения этих строк мы запускаем скрипт, чтобы убедиться, что библиотеки правильно установлены и готовы к использованию. Если все правильно, программа подтвердит, что импорт прошел успешно. Отсюда мы переходим к аутентификации и настройке клиента. Здесь лаборатория объясняет важность API-клиента, API-ключа и базового URL. API-ключ работает как пароль, который идентифицирует нас и предоставляет доступ, а базовый URL определяет местоположение сервера, куда отправляются запросы. Это подготавливает нас к задаче 2. В задаче 2 мы открываем другой скрипт Python и нас просят инициализировать клиент, введя правильные переменные среды. Это включает в себя обеспечение того, чтобы мы передали ключ API OpenAI и базовый URL API OpenAI. После заполнения этих значений мы запускаем скрипт, чтобы проверить, что клиент был правильно инициализирован. Если все сделано правильно, скрипт подтвердит подключение к серверам 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% сокращение кода. Вторая задача демонстрирует поддержку мультимоделей. Здесь нас просят настроить три поставщика: Open GPT4, Gemini от Google и XAS Gro, все с одинаковым классом и структурой. После настройки мы можем запустить один и тот же промпт через все из них и сравнить их ответы. Это особенно мощно, когда вам нужно провести 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. Это магия, которая позволяет нашему поисковому движку преуспеть там, где терпит неудачу поиск по ключевым словам. Это приводит нас к задаче номер один, где мы применяем эмбеддинги на практике. Мы открываем скрипт, инициализируем модель mini LM, кодируем как запросы, так и документы, а затем вычисляем сходство с помощью косинусного сходства. Запуск скрипта демонстрирует, как поиск "забыл пароль" успешно совпадает с "восстановлением пароля", показывая семантическое понимание в реальном времени. Как только мы поймем эмбеддинги, мы перейдем к фрагментации документов. Большие документы нельзя встроить сразу. Поэтому нам нужно разделить их на более мелкие фрагменты, но если мы режем слишком грубо, мы теряем контекст. Вот почему перекрывающиеся фрагменты важны. Они сохраняют смыслы между границами. Например, установка размера фрагмента 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. Создаем нашу коллекцию с именем TechCorp RAG и настраиваем модель эмбеддингов 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 имеет ограничения. Когда бизнес-требования становятся более сложными, такими как многошаговые рабочие процессы, условное ветвление или итеративные процессы, вам нужно что-то более сложное для лучшей оркестрации. Вот где Langraph становится необходимым. Langraph расширяет Langchain для обработки более сложных многошаговых рабочих процессов, которые выходят за рамки простых взаимодействий "вопрос-ответ". Например, если клиент спрашивает: "Мне нужно понять нашу политику конфиденциальности данных для клиентов из ЕС". Поскольку мы предполагаем, что внутри базы данных объемом 500 ГБ содержатся сведения о нормативных актах ЕС, нам нужно создать систему, которая может анализировать политику конфиденциальности данных TechCorp для клиентов из ЕС, обеспечивая соответствие GDPR, местным нормативным актам и стандартам компании. В традиционной разработке программного обеспечения вам нужно написать код, который может последовательно и условно вызывать различные разделы кода для обработки этого запроса. С Langgraph это становится графом, где каждый узел отвечает за определенную ответственность. Например, узел 1: поиск и сбор документов о политике конфиденциальности. Узел 2: извлечение и очистка содержимого документа. Узел 3: оценка соответствия GDPR с использованием анализа LLM. Узел 4: перекрестная проверка местных нормативных актов ЕС. И узел 5: выявление пробелов в соответствии и генерация рекомендаций. Узел — это отдельная единица вычислений. Так что думайте о функции, которую вы можете вызвать. Как только у вас будут созданы все узлы в Langgraph, вам нужно будет их соединить, и это соединение называется ребром. Ребра в Langgraph определяют поток выполнения. Например, после того, как узел 1 соберет документы, ребро направит к узлу 2 для извлечения содержимого. И после того, как узел 3 оценит соответствие, условное ребро либо направит к узлу 4 для дополнительного анализа, либо перейдет к узлу 5 для генерации отчета. И еще одна конечная концепция, которую следует помнить, помимо узлов и ребер, — это общий ресурс между каждым узлом. Это возможно благодаря использованию графа состояния, который по сути хранит информацию на протяжении всего рабочего процесса. Например, класс ComplianceState тип dict тема string документы list of string текущий документ optional string оценка соответствия optional integer пробелы list of string рекомендации list of string могут использоваться для узлов, которые мы определили ранее. По мере прогрессирования рабочего процесса каждый узел обновляет соответствующие переменные состояния. Узел 1 заполняет документы найденными файлами политики. Узел 2 обрабатывает отдельные документы и обновляет текущий документ. Узел 3 рассчитывает оценку соответствия. Узел 4 выявляет пробелы. Узел 5 генерирует рекомендации. Граф состояния оркестрирует выполнение на основе настроенного потока. Если узел 3 определяет, что оценка соответствия ниже 75%, условное ребро направляет обратно к узлу 1 для сбора дополнительных документов. Если оценка превышает 75%, выполнение переходит к узлу 5 для генерации окончательного отчета. Как вы можете видеть, это создает мощные возможности: циклы для итеративного анализа, условное ветвление на основе промежуточных результатов, постоянное состояние, которое сохраняет контекст на протяжении всего рабочего процесса. Таким образом, для ассистента по соблюдению нормативных требований TechCorp Langraph является важным инструментом для автоматизации рабочих процессов. Итак, давайте начнем с лабораторий. В этой лаборатории мы погружаемся в Langraph, фреймворк, предназначенный для построения многошаговых рабочих процессов ИИ с сохранением состояния. В отличие от простых цепочек, Langraph дает нам точный контроль над тем, как перемещаются данные, позволяя нам создавать ветвящуюся логику, циклы и точки принятия решений. К концу этого путешествия мы построим полноценного исследовательского ассистента, который сможет интеллектуально использовать несколько инструментов. Мы начинаем с настройки среды. На этом этапе мы активируем виртуальную среду Python и устанавливаем необходимые библиотеки. Сам Langraph, Langchain и интеграция с OpenAI. После установки мы запускаем скрипт проверки, чтобы убедиться, что наша настройка готова. С готовой средой мы начинаем с малого. Задача номер один знакомит нас с необходимыми импортами. Мы импортируем StateGraph и END, а также TypedDict для определения данных, которые перемещаются по рабочему процессу. Затем мы добавляем простое поле состояния для сообщений. Это основа. StateGraph содержит рабочий процесс и отмечает завершение, а состояние содержит общие данные. В задаче номер два мы создаем наши первые узлы. Узлы — это просто функции Python, которые принимают состояние в качестве входных данных и возвращают частичные обновления. В данном случае мы определяем узел приветствия и узел улучшения. После подключения один узел выводит базовое приветствие, а следующий узел улучшает его с некоторой изюминкой. Это демонстрирует, как состояние накапливается шаг за шагом. Задача номер три — о ребрах. Соединения между узлами. Здесь мы используем add_nodes и add_edges для подключения узлов приветствия к узлу улучшения. С этим мы построили наш первый мини-рабочий процесс. Данные перемещаются из одной функции в другую. Состояние обновляется по пути. В задаче номер четыре мы идем дальше с многошаговым потоком. Мы добавляем новые узлы, такие как шаг черновика и шаг обзора. Соединяем их и видим, как данные перемещаются через несколько этапов. Каждый шаг сохраняет состояние, добавляет детали и передает их дальше. Это имитирует реальные конвейеры, где контент набрасывается, черновик создается и полируется. Задача номер пять вводит условную маршрутизацию. Вместо фиксированного потока система теперь решает динамически. Например, если запрос короткий, он маршрутизируется одним путем. Если подробный, он маршрутизируется другим. Маршрутизатор проверяет состояние и возвращает имя следующего узла, делая рабочие процессы гибкими и адаптивными. Затем идет задача номер шесть: интеграция инструментов. Здесь мы добавляем калькулятор. Маршрутизатор проверяет, является ли запрос
связанные с математикой. Если да, то он направляется к узлу калькулятора, который вычисляет ответ. Это наш первый взгляд на то, как Langraph позволяет нам интегрировать специализированные инструменты непосредственно в рабочие процессы. Наконец, задача номер семь объединяет все в исследовательского агента. Мы объединяем калькулятор с инструментом веб-поиска, таким как duck.go. В зависимости от запроса система решает, выполнять ли вычисление, выполнять ли веб-поиск или обрабатывать ли текст обычным образом. Это динамическая оркестрация инструментов, основа современных ИИ-агентов. К концу этой лабораторной работы мы прошли путь от простых импортов до полностью функционального помощника по исследованиям. Мы увидели, как создавать узлы, соединять их, проектировать многошаговые потоки, добавлять логику маршрутизации и интегрировать инструменты. Некоторые из более глубоких экспериментов, такие как объединение более продвинутых инструментов или уточнение логики маршрутизатора, оставлены вам для самостоятельного изучения. Теперь, когда мы рассмотрели Langchain и Langraph и поняли, как технологические бизнес-требования могут быть удовлетворены за счет использования предлагаемых им готовых инструментов, есть еще один финальный элемент, который популярен с момента выпуска Anthropics в ноябре 2022 года, под названием MCP или протокол контекста модели. Ассистент по работе с документами 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, протокол контекста модели, и учимся расширять 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 и инженерия подсказок, Techorp теперь способен выполнять сложный поиск по документам, который перешел от ручного поиска, который мог занимать до 30 минут, до менее чем 30 секунд с использованием нашего ИИ-агента. И у нас также более высокая точность при использовании семантического поиска с учетом контекста, такого как использование RAG. И, наконец, пользовательский интерфейс чат-приложения позволяет пользователям получать большее удовлетворение от работы с инструментом, который может отслеживать историю разговоров и в целом лучше интуитивно понимать. И доступность этого составляет 24/7, пока приложение работает. И это только начало. Представьте себе наложение прогнозной аналитики, проактивных агентов по соблюдению нормативных требований и автоматизации рабочих процессов, которые не просто отвечают на вопросы, а активно решают проблемы до того, как сотрудники смогут их задать. Переход от статических документов к живым интеллектуальным системам знаменует собой поворотный момент не только для Tech Corp, но и для того, как любой другой бизнес может раскрыть полную ценность своих знаний с помощью агентов.