Как внедрить ИИ в 1С: 3 архитектуры с примерами

Внедрить ИИ в 1С: не одна задача, а как минимум три разных системы. У каждой свои сценарии, стоимость, срок запуска и то, за чем придётся следить потом. Чат-бот, который отвечает на вопросы по регламентам, ИИ-агент, который сам создаёт документы в 1С, и локальный ИИ-сервер, который держит данные внутри периметра. Это три непохожие архитектуры, и самая частая причина, по которой пилот с ИИ в 1С буксует: выбрали не ту архитектуру под задачу. Собрали сложного агента там, где хватало поиска по документам, или упёрлись в облачный API там, где данные нельзя выпускать наружу.

У каждой из трёх архитектур свой режим отказа. RAG уверенно отвечает мимо документа, агент по ошибке меняет данные в 1С, локальный сервер простаивает без обслуживания. Понимать эти режимы заранее и значит выбрать архитектуру осознанно, а не переделывать пилот с нуля через месяц.

Статей про «внедрение ИИ в 1С» в поиске много, но в топе обычно два уровня. Либо общие маркетинговые тексты про машинное обучение и роботизацию без единой схемы или строчки кода, либо перечень готовых облачных сервисов, которые можно подключить. Ни один из вариантов не отвечает на инженерный вопрос, из чего это физически собрать и когда какой вариант брать. Дальше как раз про это: без воды, с диаграммами и рабочим кодом из проектов, а не абстрактных примеров про повышение эффективности на N%.

Ниже три рабочие архитектуры внедрения ИИ в 1С: что это, когда какую брать, из каких компонентов она собирается и короткий пример кода. Без полных реализаций, построчный разбор есть в курсе «ИИ для 1С», а здесь важно увидеть форму каждой системы и понять, чем они отличаются. Если нужен верхнеуровневый обзор всей ниши, начните с обзорной статьи «ИИ для 1С: что реально работает».

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

Архитектура 1: RAG-чатбот по базе знаний

Самая простая и дешёвая точка входа. RAG (retrieval-augmented generation, «генерация с поиском») не меняет ничего в 1С, он отвечает на вопросы по вашим документам: регламентам, инструкциям, описанию того, «как у нас устроено». Схема потока данных выглядит так:

Пользователь (Telegram / веб) → FastAPI → { поиск в Qdrant (dense-эмбеддинги + BM25 по тем же чанкам)
                                             → LLM (стрим ответа по найденному контексту) }
                                          → Langfuse (трассировка и оценка качества)

Компоненты здесь именно те, что стоят в реальных проектах: тонкий сервис на FastAPI как точка входа, Qdrant как векторная база для поиска по знаниям, языковая модель, которая формулирует ответ строго по найденным фрагментам, и Langfuse для трассировки. По её логам видно, какой контекст модель получила и что ответила, а значит есть на чём улучшать качество. Модель при этом может быть любой: облачный API, российский GigaChat или локальная модель через Ollama, компонент взаимозаменяем.

Смысл RAG в одной фразе: модель отвечает не «из головы», а по вашим документам. На практике голого поиска по эмбеддингам обычно мало. В наших проектах поиск гибридный: один запрос уходит в Qdrant как dense-вектор, второй тем же текстом идёт в BM25 по тем же чанкам, а результаты объединяются и по желанию дожимаются реранкером. BM25 ловит точные термины и номера документов, которые эмбеддинги иногда смазывают, поэтому вместе методы закрывают слабые места друг друга. К каждому найденному фрагменту цепляем имя файла и номер страницы, тогда ответ можно проверить в оригинале, а не верить модели на слово:

async def rag_answer(question: str, llm, top_k: int = 10) -> str:
    results = await search_documents(question, top_k=top_k)  # Qdrant: dense + BM25

    context = "\n\n---\n\n".join(
        f"[Источник: {r.filename}, стр. {r.start_page}]\n{r.content}"
        for r in results
    )
    system = (
        "Отвечай на вопросы пользователя, опираясь ТОЛЬКО на контекст ниже. "
        "Если в контексте нет ответа — честно скажи об этом.\n\n"
        f"Контекст:\n{context}"
    )
    answer = ""
    async for chunk in llm.astream([SystemMessage(content=system), HumanMessage(content=question)]):
        answer += chunk.content
    return answer

Инструкция «отвечай только на основе контекста» не украшение, а страховка от выдумок: модель должна опираться на найденные документы, а не додумывать. Ответ отдаётся стримом, токен за токеном, так чат не молчит секундами, пока модель думает, а сразу показывает первые слова.

Отдельная головная боль это сами документы, а не модель. Регламенты и инструкции часто лежат сканами или свёрстаны в PDF так, что обычный текстовый парсер вытаскивает из колонок и таблиц кашу. Рабочий обход: рендерить каждую страницу в изображение и прогонять через vision-модель (VLM, локально через Ollama или через облачный API), которая возвращает чистый Markdown. Уже его режут на чанки и кладут в индекс. Это отдельный конвейер перед самим RAG, но без него база знаний засоряется мусором ещё на входе, и никакой реранкер это потом не исправит. Вся реальная инженерия RAG прячется именно здесь и в качестве поиска, а не в вызове модели: как порезать документы на фрагменты, чтобы смысл не разрывался на середине абзаца, сколько фрагментов подать, чтобы модель не утонула в шуме, и как быть уверенным, что дела не портит смена модели эмбеддингов. Это отдельная большая тема, здесь достаточно понять, что RAG читает и отвечает, но не действует.

Когда брать: внутренний вопросно-ответный бот по базе знаний, поиск по регламентам и политикам, онбординг сотрудников, первая линия поддержки. Всё, где нужно не менять 1С, а отвечать по тому, что в ней и вокруг неё уже описано. Это же почти всегда правильная первая архитектура для тех, кто вообще только начинает с ИИ.

Стоимость и поддержка: дешевле всего собрать и содержать, запускается за дни. Обратная сторона: он умеет только отвечать, выполнить действие в 1С RAG не может по определению. Как только от системы захотят «а создай мне документ», этой архитектуры уже мало.

Архитектура 2: ИИ-агент с доступом к 1С через инструменты

Когда ИИ должен не отвечать, а действовать: создать документ, проверить остаток на складе в реальном времени, посмотреть статус заказа, нужен агент с инструментами. В отличие от чат-бота, агент не просто генерирует текст. Он в цикле решает, какой инструмент вызвать, читает результат и решает, ответить пользователю или сделать ещё один вызов. Схема:

Пользователь → ИИ-агент (LangGraph, цикл agent ↔ tools) → HTTP-сервис 1С / MCP-сервер
                                                          → реальные объекты 1С (справочники, документы)

Ядро это цикл «агент ↔ инструменты». Его удобно строить на LangGraph: модель получает список инструментов, выбирает нужный, граф исполняет вызов, результат возвращается модели, и так до тех пор, пока задача не закрыта. Полный рабочий пример такого цикла с ToolNode и tools_condition разобран в отдельной статье, ИИ-агент на LangGraph для 1С. Здесь код не повторяем, чтобы две статьи не конкурировали за один и тот же запрос.

Подключить агента к 1С можно двумя способами. Первый: обычный HTTP-сервис 1С, вы публикуете методы («найти номенклатуру», «создать заявку») и вызываете их как инструменты агента. Второй: MCP-сервер. Если вы хотите, чтобы теми же методами 1С мог пользоваться не только ваш агент, но и Claude, Cursor или ChatGPT без отдельной обвязки под каждого, оберните их в MCP. Как устроен MCP-сервер поверх 1С, в статье MCP-сервер для 1С.

Есть и третий, более узкий случай: агенту нужно не выполнить операцию, а ответить на произвольный аналитический вопрос по большой плоской таблице, «сколько мы продали товара X по регионам за квартал», и таких разрезов слишком много, чтобы на каждый писать отдельный инструмент. Тогда вместо набора HTTP-методов агенту дают возможность самому сгенерировать SQL или код на Pandas по выгруженным данным. Разбор этого подхода и его ловушек (модель придумывает несуществующие поля) в статье LLM и 1С: TextToSQL и Pandas для точных запросов к большим таблицам.

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

Стоимость и поддержка: здесь и уходит основная инженерная работа. Разница между «отвечает» и «действует» это разница между неверным ответом и неверным документом в базе. Поэтому нужно аккуратно раздать права инструментам: что агент вообще имеет право записать, а что только читать. Опасные операции стоит либо закрывать подтверждением человека, либо делать так, чтобы повторный вызов не плодил дубли документов. Отдельная работа: обработать пустые и некорректные ответы 1С, агент должен понимать, что «ничего не найдено» и «сервис недоступен» это разные ситуации, и не выдавать пользователю выдуманный результат вместо честного «не нашёл». Всё это дороже RAG и по разработке, и по сопровождению, но только так ИИ получает возможность действовать, а не только рассказывать.

Архитектура 3: локальный ИИ-сервер (данные не покидают периметр)

Первые две архитектуры отвечают на вопрос «что делает ИИ». Третья отвечает на другой: «где физически крутится модель». Если данные нельзя отправлять во внешний облачный API, ответ один: своя модель на своём железе.

1С / агент / чат-бот → внутренняя сеть → GPU-сервер (vLLM / Ollama, локальная модель)
                                        → без внешних API-вызовов

Клиентом тут выступает любая из первых двух архитектур: тот же RAG-чатбот или тот же агент, только обращаются они не в облако, а внутрь своей сети, на GPU-сервер с локальной моделью. Для обслуживания модели обычно берут vLLM (когда важен поток и параллельные запросы: он хорошо утилизирует видеокарту на пачке одновременных обращений) или Ollama (проще поднять для старта и для единичных запросов). Важный момент: локальный сервер не отменяет ни RAG, ни агента, он их не заменяет, а подкладывает под них другую модель. Код чат-бота или агента при переезде в локаль почти не меняется, меняется адрес, куда уходит запрос. Наружу при этом не уходит ни один запрос, это и есть главная причина городить локальный сервер.

По железу в реальных внедрениях встречаются сборки на RTX 3090 и смешанные конфигурации со старыми Tesla V100. И здесь есть задокументированная ловушка: в vLLM версии 0.20 отвалилась поддержка архитектуры Volta (sm_70), то есть тех самых V100. Номера версий и список поддерживаемого железа дрейфуют, так что перед закупкой сверяйтесь с актуальным. Полный разбор подбора и настройки железа в отдельных материалах: установка vLLM на RTX 3090 и Tesla V100 и сравнение видеокарт для LLM, здесь мы это не переписываем.

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

Стоимость и поддержка: самая высокая цена входа, надо купить и настроить GPU. Зато низкая предельная стоимость запроса и полный контроль. Экономика проста: облако дешевле на старте и на малом потоке, но каждый запрос стоит денег; своё железо требует вложений сразу, зато на потоке в тысячи запросов в день окупается и дальше почти не растёт в цене. Расплата за контроль: операционная нагрузка полностью на вас, драйверы, обновления моделей, мониторинг, дежурство, когда сервер упал. Выбор между облаком и локалью подробно (с калькулятором) разобран в обзорной статье.

Можно ли совмещать эти три архитектуры?

Да, и на практике зрелые внедрения так и устроены. Это не четыре разных проекта, а слои одной системы: RAG отвечает за слой знаний, агент за слой действий, а локальный сервер определяет, где крутится модель под обоими слоями. Типичная взрослая конфигурация это RAG для ответов по документации плюс агент с инструментами для операций в 1С, и оба при необходимости работают на локальной модели ради приватности.

Разберём на одном сценарии. Менеджер спрашивает ассистента: «по какому регламенту оформляется возврат и создай возврат по заказу №1024». Первая половина вопроса про знание: система идёт в RAG, находит регламент и отвечает. Вторая про действие: тот же ассистент передаёт задачу агенту, который через инструмент 1С заводит документ возврата. Если компания работает с чувствительными данными, обе модели, и та, что отвечает по регламенту, и та, что рассуждает в агенте, крутятся на локальном сервере, и ни один запрос не уходит наружу. Три архитектуры, одна система.

Начинать при этом почти всегда стоит с одного слоя: собрать RAG-чатбот, а агента и локальный сервер добавлять по мере того, как задача перерастает ответы. Попытка сразу построить всё три слоя, верный способ увязнуть на старте.

Сравнительная таблица

Коротко, чем три архитектуры отличаются по ключевым критериям:

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

Главный вывод: «лучшей архитектуры вообще» не бывает, есть лучшая под конкретный критерий. Если важен быстрый старт, это RAG; если нужны действия, агент; если данные нельзя выпускать наружу, локальный сервер поверх любой из первых двух.

Чтобы не выбирать на глаз, ответьте на два вопроса, подскажу отправную архитектуру под вашу задачу:

С чего начать

Если раньше вы с ИИ в 1С не работали, начните с RAG-чатбота: самая низкая инженерная сложность и результат за дни. Дальше по мере роста задачи добавляется агент, а требования к приватности выводят на локальный сервер. Все три архитектуры собраны и разобраны построчно, от FastAPI-сервиса и LangGraph-агента до деплоя локального ИИ-сервера, в курсе «ИИ для 1С». Там же готовые проекты, которые можно взять за основу своего внедрения.

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