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

Всем привет, с вами Низамов Илья. Когда программист 1С начинает искать нейросети для 1С, первое желание понятное: взять одну большую модель вроде GPT-4o и звать её на всё подряд, на генерацию кода, на чат-бота, на разбор сканов, на классификацию номенклатуры. Для демки это работает прекрасно. А потом фича уходит в прод, поток запросов растёт, и выясняется: одна модель на всё обходится дорого, работает медленно и упирается в лимиты. Настоящий навык не в том, чтобы знать самую мощную нейросеть, а в том, чтобы под каждый тип задачи 1С подобрать модель нужного класса и размера.

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

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

Задача 1: диалог и генерация текста (чат-бот, ответы на вопросы)

Это единственный тип задачи, где житейское «бери самую большую модель» действительно близко к истине. Для свободного диалога, ответов на вопросы, генерации текста нужна сильная универсальная LLM: в облаке это GPT-4o, GigaChat-2 или Claude за максимальное качество, на своём сервере: крупная открытая модель вроде Qwen3-235B или gpt-oss-120b, если данные не должны покидать периметр компании. Железо под такую модель я разбираю отдельно: как поднять инференс в гайде по vLLM на RTX 3090 и Tesla V100 и какую видеокарту вообще брать в сравнении GPU для инференса LLM.

Выбор между облаком и локалью, тема отдельная и большая, со своими компромиссами по цене, скорости и требованиям к данным. Чтобы не повторять её здесь, отправлю к разбору ИИ для 1С в 2026: облачные vs локальные модели, там таблица сценариев и экономика на потоке. Здесь важно зафиксировать одно: диалог, как раз тот случай, где размер модели напрямую конвертируется в качество, и экономить на нём обычно себе дороже.

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

Задача 2: генерация и объяснение кода (запросы 1С, BSL, Python)

Для написания и объяснения кода подходят либо модели, специально заточенные под код, либо сильные универсальные. Отдельная категория: рассуждающие (reasoning) модели класса DeepSeek-R1: они особенно полезны для отладочных вопросов вроде «почему этот запрос 1С возвращает не то, что я жду», модель проговаривает цепочку рассуждений и находит неочевидные причины.

Но у рассуждающих моделей есть конкретная ловушка, о которой облачные сервисы обычно молчат, потому что чистят это за вас. Локально такая модель возвращает ответ вместе со служебным блоком размышлений в тегах <think>...</think>. Если этот блок не вырезать перед тем, как показать результат пользователю или сохранить в базу, в ответ попадёт весь внутренний монолог модели. Лечится одной регуляркой:

import re
answer_only = re.sub(r"<think>.*?</think>", "", raw_response, flags=re.DOTALL).strip()

Ещё один практический приём. Для повторяющихся задач в духе «оптимизируй запрос» или «приведи код к стилю» одиночный вызов модели работает хуже, чем цикл: сгенерировали, проверили результат, если не сошлось, попросили переделать. Здесь есть неочевидная тонкость: обязательно нормализуйте вывод модели перед сравнением. Иначе цикл будет делать лишние итерации на пустом месте: из-за разницы в форматировании (лишние пробелы, регистр, кавычки) две по сути одинаковые версии будут считаться разными, и модель начнёт «исправлять» то, что уже верно.

Кстати, если такой цикл довести до предела и подключить к нему не абстрактную «красоту» кода, а реальный план выполнения из базы, получится куда более надёжная схема: об этом кейсе, где ИИ гоняет 1С-запрос по циклу с обратной связью от рабочей базы, а не верит на слово, я подробно рассказываю в статье «ИИ для 1С в 2026». А если задача не «переписать запрос покрасивее», а точная агрегация по большим таблицам, вроде «сколько мы продали товара X по месяцам за три года», модель на лету может и наврать в цифрах: там лучше не доверять генерации SQL/1С-запроса вслепую, а завести отдельный TextToSQL-пайплайн с проверкой результата. Разбираю этот подход в статье «LLM и 1С: TextToSQL и Pandas для точных запросов к большим таблицам».

И про версии моделей отдельно. Ландшафт код-моделей меняется буквально каждый месяц: номера версий Qwen, DeepSeek, GigaChat сдвигаются быстрее, чем успевают устаревать статьи. Поэтому не привязывайтесь к конкретному имени модели в коде намертво, держите его в настройке, как в примере с фабрикой ниже, чтобы обновление до новой версии было заменой одной строки, а не переписыванием пайплайна. Конкретное имя в этой статье: иллюстрация подхода, а не рекомендация «ставьте именно это и навсегда».

Задача 3: эмбеддинги и поиск (RAG, семантический поиск по документации 1С)

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

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

def get_embeddings(provider: str):
    if provider == "openai":
        return OpenAIEmbeddings(model="text-embedding-3-large")
    if provider == "local":
        return HuggingFaceEmbeddings(
            model_name="BAAI/bge-m3",
            encode_kwargs={"normalize_embeddings": True},
        )
    raise ValueError(provider)

Обратите внимание на normalize_embeddings=True для локальной модели: без нормализации векторов косинусная близость будет считаться некорректно, и поиск начнёт выдавать мусор. Мелочь, на которой легко потерять час.

Задача 4: реранкинг как второй проход поиска, который часто забывают

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

Посмотрите на виджете, что происходит без реранкера: наверх всплывают лексически похожие, но не отвечающие документы, «Договор поставки, общие условия» и «Отсрочка по налоговым платежам». Оба содержат нужные слова, но ответа на вопрос в них нет. Нужный регламент по отсрочке оказывается на пятом месте и в LLM просто не попадает. Реранкер это чинит.

В проде есть два хороших варианта. Первый, классический кросс-энкодер BAAI/bge-reranker-v2-m3: инициализируется парой строк, дружит с CPU, отдаёт нормализованные оценки релевантности, по которым легко отсекать по порогу. Второй, более свежий подход, Qwen3-Reranker, поднятый через vLLM как эндпоинт генеративного скоринга. Идея красивая: реранкер здесь это полноценная LLM, которую спрашивают «да/нет, релевантен ли документ», а в качестве оценки берут не текст ответа, а вероятность токена «да»:

# Идея генеративного реранкера: модель отвечает "да"/"нет",
# и используется не текст ответа, а вероятность токена "да".
prompt = f"<Instruct>: Оцени релевантность\n<Query>: {query}\n<Document>: {doc}"
# score = P(token "yes") из logprob — чем выше, тем релевантнее

Реранкинг полезен не только в классическом RAG. Если вы строите MCP-сервер для 1С и инструмент возвращает много результатов, тот же второй проход помогает отдать модели наиболее релевантные, а не первые попавшиеся. А как реранкер встраивается в общую архитектуру корпоративного бота, разбираю в статье про архитектуры внедрения ИИ в 1С.

Задача 5: классификация и извлечение полей (не всегда нужна LLM в проде)

Это самая недооценённая часть. Классификация входящих обращений, категоризация номенклатуры, разметка свободных текстовых полей: всё это высокочастотные, чувствительные к задержке задачи. И тут инстинкт «вызову GPT-4o на каждую строку» подводит сильнее всего: на потоке это и медленно, и дорого.

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

class Classification(BaseModel):
    # На старте список пуст → Optional[str]; далее — Literal из найденных.
    category: Optional[Literal[*known_categories]]  # растёт по мере вызовов
    new_category: Optional[str] = None  # модель предлагает новую, если ни одна не подошла

Второй шаг: дистилляция. Полученную разметку скармливаем маленькой классической модели (FastText) и обучаем её. И вот тут разница в цифрах становится драматичной: FastText грузится за ~50 мс, предсказание занимает десятки микросекунд на строку, а сама модель после квантизации весит около 14 МБ. На реальной товарной базе автоподбор гиперпараметров поднял точность с 0.865 до 0.933, то есть маленькая модель не только быстрее, но и вполне точна. Большая LLM в этой схеме работает один раз, как «учитель», а не как рантайм.

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

Отдельно, неочевидный бонус к скорости. Держите системный промпт идентичным от вызова к вызову: растущий список категорий передавайте не текстом в промпте, а как enum в JSON-схеме структурированного вывода. Тогда локальный движок инференса (Ollama, vLLM) переиспользует KV-кэш общего префикса между вызовами, это заметно ускоряет массовую разметку. Если менять текст промпта на каждой итерации, кэш префикса каждый раз инвалидируется, и вы теряете этот выигрыш на ровном месте.

Задача 6: работа с изображениями и сканами (OCR, VLM)

Для структурированных сканов, накладных, паспортов, актов, есть два пути. Первый: VLM (vision-language model) читает текст прямо с картинки, без отдельного пайплайна OCR и разметки макета. Это гибко и удобно, когда документы разнородные. Второй: классическая связка OCR + YOLO, часто быстрее и дешевле на очень больших объёмах документов известной, устоявшейся формы. Практичный подход: держать бэкенд VLM конфигурируемым, чтобы Ollama работал для локального прогона, OpenRouter для быстрого старта на облачных моделях, а self-hosted vLLM для нагруженного прода. Как устроен сервис распознавания сканов целиком, отдельный разбор про распознавание документов нейросетью в 1С.

Порог выбора между этими путями снова объём и типовость. Если форм немного и они стабильны (одни и те же накладные от одних и тех же контрагентов), обучить YOLO находить нужные зоны и прогнать OCR окупается: пайплайн получается быстрым и предсказуемым. Если же на вход идут разнородные документы, у которых заранее не известна структура, возня с разметкой макетов под каждый тип не оправдана, VLM, читающая изображение целиком, сэкономит куда больше инженерного времени, даже если стоит дороже за один документ. Как и во всех предыдущих задачах, ответ определяется не тем, «какая модель умнее», а профилем вашей нагрузки.

Сводная таблица: задача → тип модели

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

Все эти подходы, от эмбеддингов и реранкеров до дистилляции и VLM, мы разбираем на реальном коде в курсе «ИИ для 1С»: не «посмотрите, как красиво отвечает бот», а как собрать это так, чтобы оно жило в проде и не разорило вас на токенах.