Нейросеть на базе знаний компании: как подключить через API

Нейросеть на базе знаний компании перестаёт быть игрушкой ровно в тот момент, когда её подключаешь через API, а не гоняешь вопросы вручную через обычный веб-чат. Я собираю такие системы клиентам не первый год: беру документы компании (прайсы, регламенты, FAQ, переписку из тикетов), подключаю их к модели через Claude API или OpenAI API и получаю бота, который отвечает по актуальным данным компании, а не сочиняет из общих знаний интернета. В статье разбираю архитектуру такого решения, разницу между провайдерами API, пошаговый процесс подключения, куда его встраивать и сколько это стоит на практике.

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

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

На одном из проектов у клиента, интернет-магазина стройматериалов на WooCommerce, менеджеры вручную искали характеристики товаров в прайсе на 400 позиций для каждого обращения в мессенджер. После подключения бота через API среднее время ответа упало с 20 минут до нескольких секунд, а менеджеры остались только на сложных случаях вроде расчёта доставки СДЭК под нестандартный габарит.

Второй плюс: документы компании не улетают в чужой личный аккаунт сотрудника, а обрабатываются через контролируемый API-ключ с логированием и ограничением доступа. Для компаний, которые работают с персональными данными клиентов, это не факультативная опция, а требование по 152-ФЗ: сами диалоги и контакты стоит хранить на серверах в России отдельно от внешних облачных сервисов, а не там, где физически стоит инфраструктура зарубежного провайдера чат-бота.

Архитектура RAG: как модель находит нужный кусок базы знаний

Модель не хранит документы компании внутри себя и не запоминает их между запросами. Каждый раз, когда пользователь задаёт вопрос, система сначала ищет релевантные фрагменты в базе знаний и только потом отправляет их вместе с вопросом в API. Такой подход называется RAG, retrieval augmented generation, генерация с подгрузкой найденных данных.

Схема на практике выглядит так:

• документы компании (PDF, Word, страницы сайта, выгрузка из CRM) режутся на фрагменты по 300-800 токенов;
• для каждого фрагмента считается эмбеддинг, числовой вектор смысла текста;
• векторы складываются в базу вроде pgvector, Qdrant или Pinecone;
• при вопросе пользователя система ищет 3-5 ближайших по смыслу фрагментов;
• найденные фрагменты подставляются в системный промпт модели вместе с инструкцией отвечать только по ним.

Для большинства проектов беру Postgres с расширением pgvector: он и так часто уже стоит в проекте под остальные данные, поэтому не тащу в инфраструктуру отдельный векторный сервис ради одной задачи. Отдельную базу вроде Qdrant ставлю, когда документов десятки тысяч и нужен быстрый поиск с фильтрами по метаданным, например по разделу базы знаний или дате документа.

Claude API, OpenAI API или локальная модель: что выбрать для базы знаний

Для чат-бота с базой знаний компании разница между Claude API и OpenAI API на практике в основном в том, как модель держит длинный системный промпт с найденным контекстом и насколько честно признаёт, что ответа в документах нет, вместо того чтобы досочинить правдоподобный, но неверный ответ.

Локальную модель через Ollama ставлю только если данные компании нельзя выгружать за периметр вообще, например для банковской или медицинской документации. В остальных случаях облачный API проще в поддержке и не требует отдельного сервера под GPU.

Пошаговое подключение нейросети с базой знаний компании

1. Собираю и размечаю документы

Свожу все источники в один формат: экспортирую FAQ с сайта, выгружаю прайс из 1С или CRM, добавляю регламенты из Google Docs. Убираю дубли и устаревшие версии, потому что модель одинаково доверяет и актуальному прайсу, и прошлогоднему, если оба лежат в базе, и разница в дате для неё не аргумент без явной инструкции.

2. Считаю эмбеддинги и заливаю в векторную базу

Пишу скрипт на Python, который режет документы на фрагменты, прогоняет их через модель эмбеддингов и складывает в таблицу с векторным индексом. Для 500‑1000 страниц документации это занимает от 20 минут до пары часов в зависимости от объёма и лимитов API.

3. Пишу системный промпт и логику запросов

Вот упрощённый пример запроса к Claude API с подстановкой найденного контекста:

import anthropic

client = anthropic.Anthropic(api_key="sk-ant-...")

def ask_with_context(question, context_chunks):
    context = "\n\n".join(context_chunks)
    system_prompt = (
        "Отвечай только на основе базы знаний компании ниже. "
        "Если ответа нет в контексте, скажи, что не знаешь.\n\n" + context
    )
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system=system_prompt,
        messages=[{"role": "user", "content": question}]
    )
    return response.content[0].text

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

4. Тестирую на реальных вопросах

Беру 30-50 реальных обращений клиентов из истории переписки и прогоняю через бота до запуска. На этом шаге обычно всплывают дыры в базе знаний: часть вопросов не покрыта документами вообще, и это повод дописать FAQ, а не тюнить промпт бесконечными правками.

Куда подключать: сайт, Telegram и CRM

Для сайтов на Tilda обычно добавляю виджет чата через кастомный скрипт в зону вставки кода: он шлёт вопрос на бэкенд, а бэкенд уже обращается к API с подстановкой контекста. Для Telegram собираю бота на aiogram, он использует ту же логику поиска по базе знаний, что и виджет на сайте, просто другой канал доставки сообщений.

Обновление базы знаний обычно завязываю на n8n: сценарий следит за изменением документа в Google Docs или таблицы с ценами и при правке автоматически пересчитывает эмбеддинги и обновляет векторную базу, без ручного запуска скрипта каждый раз, когда у компании меняются условия.

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

Сколько стоит подключение нейросети с базой знаний и сколько это занимает по времени

Цена зависит от объёма документов, количества каналов (сайт, Telegram, CRM) и того, нужна ли интеграция с внешними системами вроде склада, эквайринга T‑Bank или доставки СДЭК.

На рынке за похожий проект студии просят от 100 000 до 300 000 ₽ и растягивают срок на полтора-два месяца, потому что закладывают отдельного менеджера проекта и дизайн виджета с нуля. У меня без дизайнерских работ типовое подключение занимает от 10 до 15 рабочих дней, считая тестирование на реальных вопросах.

Частые вопросы

Сколько документов может обработать нейросеть с базой знаний компании?

Ограничение упирается не в модель, а в векторную базу и бюджет на эмбеддинги. Pgvector на обычном сервере спокойно держит десятки тысяч фрагментов, для сотен тысяч страниц беру специализированную векторную базу вроде Qdrant с шардированием.

Нужно ли дообучать модель под компанию?

Нет, RAG-подход не требует дообучения (fine-tuning): модель остаётся исходной, а под компанию настраивается только источник данных и системный промпт. Дообучение имеет смысл в редких случаях, когда нужно поменять сам стиль ответов модели, а не набор фактов.

Как часто обновлять базу знаний?

Зависит от того, как часто меняются цены и условия. Для интернет-магазина с динамическим прайсом настраиваю автоматическое обновление через n8n при каждом изменении таблицы, для регламентов и FAQ достаточно ручного запуска пересчёта раз в одну-две недели.

Безопасно ли передавать документы компании через API?

Запросы к Claude API и OpenAI API идут по защищённому соединению, и оба провайдера по условиям API не используют данные компании для обучения своих моделей. Тем не менее контакты и переписку клиентов храню на серверах в России отдельно от векторной базы с документами, это требование 152-ФЗ, а не прихоть.