Разработчики, которых просят «прикрутить ИИ» к внутренней системе компании, обычно сталкиваются не с моделью, а с интеграцией: как подключить LLM к CRM, базе документов или заявкам так, чтобы это не сломалось на первом же edge-кейсе. Разберём рабочую схему на практике.
Зачем бизнесу ИИ во внутренних системах
Три задачи чаще всего просят автоматизировать:
- Обработка заявок и документов. Заявка приходит в свободной форме (письмо, сообщение в мессенджере, PDF) — нужно вытащить структурированные данные и записать в учётную систему.
- Ответы по базе знаний компании. Сотрудник или клиент задаёт вопрос — нужен ответ по внутренним документам, а не общие фразы модели.
- Аналитика и дашборды. Руководителю нужна сводка на естественном языке поверх сырых данных из CRM или БД.
Во всех трёх случаях чистый вызов LLM API не решает задачу — нужна прослойка вокруг модели.
Базовая архитектура: RAG вместо дообучения
Для задач «ответить по документам компании» почти всегда правильнее RAG (Retrieval-Augmented Generation), а не дообучение модели:
- Документы разбиваются на чанки и превращаются в эмбеддинги (векторное представление текста).
- Эмбеддинги кладутся в векторную БД (pgvector, Qdrant, Weaviate — выбор зависит от нагрузки и того, что уже есть в стеке).
- На вопрос пользователя ищутся релевантные чанки, они добавляются в промпт как контекст.
- Модель отвечает, опираясь на найденный контекст, а не на «память» весов.
Плюс такого подхода — документы можно обновлять без переобучения модели, и модель не выдумывает факты, которых нет в базе (или выдумывает заметно реже, если промпт явно просит отвечать только по контексту).
Структурированный вывод для интеграции с учётными системами
Когда нужно не поговорить, а записать данные в CRM или таблицу, LLM должна возвращать строго типизированный JSON, а не текст. У большинства провайдеров (OpenAI, Anthropic, локальные модели через vLLM/Ollama) есть режим structured output или function calling — модель обязана вернуть объект, соответствующий JSON-схеме. Это снимает половину проблем с парсингом «почти правильного» текста.
Практический момент: даже со structured output нужна валидация на своей стороне (Zod/Pydantic и аналоги) — модель может вернуть валидный JSON, но с неверным значением поля (например, придуманным ID контрагента), и это должно ловиться до записи в БД.
Где действительно нужен человек в цикле
Для заявок с финансовыми последствиями (закупки, платежи, изменение цен) правильная схема — не «ИИ решает», а «ИИ готовит, человек подтверждает». Модель разбирает заявку, извлекает поля, сопоставляет с номенклатурой — и выводит на утверждение, а не проводит документ сама. Это снижает риск и делает систему объяснимой: видно, что предложила модель и что подтвердил человек.
Что учитывать при выборе: облако или локальная модель
Если в данных есть коммерческая тайна или персональные данные клиентов, отправка каждого запроса во внешний API может быть неприемлема по политике безопасности компании. Альтернатива — локальная модель (Qwen, Llama, gpt-oss) на своём сервере через vLLM или Ollama. Компромисс: локальные модели такого размера, который помещается на разумное железо, обычно уступают топовым облачным по качеству сложных рассуждений, но для задач вида «извлечь поля» или «ответить по документам» разница часто некритична.
Итог
Рабочая связка для внедрения ИИ во внутренние системы — это не «вызвать API модели», а: RAG для работы со знаниями компании, structured output с валидацией для записи данных, и человек в цикле там, где цена ошибки высока. Мы в ITOQ занимаемся именно такими внедрениями под ключ — от чат-ботов и автоматизации заявок до интеграции нейросетей с Битрикс24 и другими CRM, разбираем похожие кейсы в блоге на itoq.ru/blog.
Комментариев: 0