Как технически устроен AI-бот: API, LangChain и векторные базы

Бизнес всё чаще требует «прикрутить ИИ» к своим процессам, ожидая магии из коробки. Многие компании начинают с того, что нанимают разработчика, который за пару дней подключает API ChatGPT к корпоративному Telegram-боту. Первые тесты вызывают восторг, но когда решение выкатывают на реальных клиентов или сотрудников, начинается хаос.

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

Чтобы ИИ-ассистент работал как швейцарские часы, отвечал строго по вашей корпоративной базе знаний и выполнял реальные задачи, одной нейросети недостаточно. Для этого используется комплексная архитектура на базе RAG (Retrieval-Augmented Generation) и AI-агентов.

Иллюзия простого бота: фундаментальные ограничения LLM

Базовые языковые модели (LLM), такие как GPT-4o, Claude 3.5 или Llama 3, обучаются на массивах данных из интернета. У них есть два критических ограничения для бизнеса:

1. Замороженные знания: Модель ничего не знает о событиях, произошедших после окончания ее обучения.
2. Отсутствие приватного контекста: Нейросеть не имеет доступа к вашим прайс-листам, внутренней CRM, истории переписок с конкретным клиентом и NDA-документам.

Если вы спросите базовую LLM: «Какие у нас условия доставки насосов серии X-200 в Сургут?», она либо честно извинится, либо сгенерирует правдоподобную ложь на основе усредненной информации из сети. И то, и другое недопустимо в B2B-продажах.

Анатомия современного AI-решения: 4 главных компонента

Чтобы решить проблему изоляции LLM от реального мира, была разработана архитектура RAG. Ее суть заключается в том, что перед тем как нейросеть сгенерирует ответ, система динамически подкладывает ей нужную информацию. Разберем эту архитектуру по слоям.

1. Ядро интеллекта (LLM API)

Это «мозг» системы, отвечающий за понимание естественного языка, логику и генерацию связного текста. В зависимости от требований к безопасности и бюджету, бизнес выбирает:

• Облачные API (OpenAI, Anthropic): Самые умные модели, требующие передачи данных на внешние серверы. Идеально подходят для маркетинга, техподдержки и задач, где нет строгих ограничений на передачу коммерческой тайны.
• Локальные модели (Open Source): Llama 3, Qwen или Mistral, развернутые на собственных серверах компании (On-Premise). Это единственный выход для финтеха, медицины и корпораций с жесткими правилами безопасности (Data Privacy).

2. Векторизация и Chunking (Подготовка данных)

Нейросети не могут просто «прочитать» все ваши PDF-файлы в момент ответа - это долго и дорого (контекстное окно стоит денег). Поэтому корпоративная база знаний предварительно нарезается на небольшие смысловые куски (чанки) по 500-1000 токенов.

Каждый чанк пропускается через специальную Embedding-модель (например, text-embedding-3-small), которая превращает текст в многомерный математический вектор (массив чисел). В этом векторном пространстве тексты с похожим смыслом находятся рядом.

3. Векторные базы данных (Память)

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

• Pinecone или Weaviate: Облачные (SaaS) решения. Быстро настраиваются, отлично подходят для стартапов и MVP, когда не хочется тратить время на администрирование инфраструктуры.
• Milvus или Qdrant: Мощные Open Source базы. Способны хранить миллиарды векторов. Выбор Enterprise-сегмента.
• pgvector (расширение для PostgreSQL): Если ваша инфраструктура уже плотно сидит на Postgres, это расширение позволяет хранить векторы рядом с реляционными данными. Отличный компромисс между удобством и производительностью.

4. LangChain / LlamaIndex (Оркестратор)

LangChain - это фреймворк (на Python или TypeScript), который связывает базу данных, LLM и ваши внутренние API в единый конвейер. Если LLM - это мозг, а векторная база - память, то LangChain - это «руководитель проекта», который управляет логикой и потоком данных.

Пайплайн RAG на практике: путь одного запроса

Давайте посмотрим, что происходит за доли секунды, когда клиент задает сложный вопрос в ваш корпоративный ИИ-интерфейс.

1. Запрос: Клиент пишет: «Сколько стоит доставка насоса в Сургут и есть ли он на складе?».
2. Перефразирование (Query Expansion): LangChain может переписать запрос, чтобы векторный поиск сработал точнее. Например, добавив синонимы.
3. Семантический поиск: Запрос переводится в вектор и сравнивается с базой знаний. Система находит 5 наиболее релевантных кусков текста (информация по тарифам в ХМАО).
4. Re-ranking (Пересортировка): Продвинутые архитектуры используют вторичные модели (Cross-encoders) для оценки найденных кусков и отсева мусора, оставляя только 2 самых точных фрагмента.
5. Вызов инструментов (Tool Calling): LangChain видит, что клиент спросил про остатки. Он делает SQL-запрос или обращается к API 1С, чтобы узнать фактическое наличие товара на складе прямо сейчас.
6. Склейка (Augmentation): Формируется огромный скрытый промпт для LLM: «Ты менеджер компании. Ответь клиенту, используя ТОЛЬКО эти документы [текст про доставку] и эти данные из системы [насос есть, 12 шт].»
7. Генерация ответа: LLM получает этот промпт, связывает факты и пишет красивый ответ: «Добрый день! Насос сейчас в наличии на складе (12 штук). Доставка в Сургут займет 3 рабочих дня, стоимость 1500 рублей.»

AI-Агенты (Agents): когда бот начинает действовать

Классический RAG умеет только отвечать на вопросы, извлекая данные из базы. Но современный бизнес требует автономности. Здесь на сцену выходят AI-агенты (с использованием фреймворков вроде LangGraph).

Агентам можно дать доступ к инструментам. Если клиент пишет «Оформи доставку на завтра», агент может самостоятельно:

• Проверить доступное время в календаре через API.
• Создать сделку или задачу в Битрикс24.
• Отправить email-подтверждение через SendGrid.
• Запросить у клиента недостающие данные для договора.

Распространенные ошибки при проектировании архитектуры

При самостоятельной разработке компании часто наступают на одни и те же грабли, которые убивают конверсию и доверие пользователей:

• Плохой парсинг документов: Если просто «скормить» системе PDF со сложной версткой, таблицами и колонтитулами, чанки получатся рваными. ИИ не сможет извлечь смысл из разбитой посередине таблицы. Таблицы требуют отдельного алгоритма извлечения.
• Отсутствие гибридного поиска: Векторный поиск плох в поиске точных артикулов (например, "SN-4982X"). Для e-commerce необходимо совмещать векторный поиск с классическим полнотекстовым поиском (BM25).
• Слишком длинный контекст: Попытка передать в LLM сразу 50 страниц найденного текста приводит к эффекту «потери в середине» (Lost in the Middle) - модель забывает данные, расположенные в центре промпта.

Резюме: когда вам действительно нужна такая архитектура?

Если вам нужно просто переписывать тексты писем для рассылки, вам достаточно подписки на ChatGPT. Но если ваша цель - автоматизировать первую линию продаж, создать умного онбординг-бота для новых сотрудников или запустить саппорт, который разбирается в ваших регламентах лучше живых людей, без RAG-архитектуры и оркестраторов не обойтись.

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