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

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

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

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

Нейросеть для 1С: готовый сервис или своя модель?

Коробочные сервисы подключаются за вечер: платите подписку и получаете ассистента в интерфейсе, который отвечает на вопросы по данным или заполняет описание номенклатуры. Разработчик там не нужен, но и за пределы того, что придумал вендор, вы не выйдете, а данные (наименования номенклатуры, тексты документов, переписка с клиентами) уходят на сторону вендора.

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

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

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

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

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

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

Задача 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С: что реально работает». А если задача не «переписать запрос покрасивее», а точная агрегация по большим таблицам, вроде «сколько мы продали товара X по месяцам за три года», модель на лету может и наврать в цифрах: там лучше не доверять генерации SQL/1С-запроса вслепую, а завести отдельный TextToSQL-пайплайн с проверкой результата. Разбираю этот подход в статье «LLM и 1С: TextToSQL и Pandas для точных запросов к большим таблицам».

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

И ещё: сильная модель без контекста платформы всё равно ошибается на 1С. Почему так и как это чинится — в разборе вайбкодинга в 1С.

Задача 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С? Что мерить вместо рейтингов

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

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

Как мы меряем: методика вместо ощущений

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

Первое решение: единица измерения не модель, а связка «агентная оболочка + модель + инструменты». Работу делает не модель сама по себе, и вклад оболочки виден сразу: одна и та же модель на одной задаче даёт разный результат в зависимости от того, дали ли ей генераторы XML-выгрузки и доступ к живой базе. Поэтому прогон записывается как «оболочка × модель × обвязка», а не именем модели.

Второе решение: кандидат сдаёт артефакт, а не рассуждения. Он получает пустой каталог со скелетом конфигурации и должен оставить в нём полную XML-выгрузку. План, объяснения и промежуточные попытки на балл не влияют, оценивается то, что грузится в платформу и работает.

Задача сейчас одна: HTTP-API выпуска и проверки JWT-токенов внутри 1С. Общий модуль СервисТокенов, HTTP-сервис с тремя эндпоинтами, подпись HS256. Она выбрана не случайно: готового HMAC в платформе нет, его собирают руками на БуферДвоичныхДанных по RFC 2104, а рядом лежит ещё несколько ловушек. Нужен base64url, а не base64; аудитория сравнивается с учётом регистра (crm и CRM это разные аудитории); при незаданном сроке жизни токен не выпускается вовсе, а не подставляется умолчание.

Оценка идёт уровнями, и первые два из них это ворота: не прошёл, итог ноль независимо от того, как красиво написан код.

Отдельный слой, без которого числам верить нельзя, это калибровка в обе стороны. Метрика, которую ни разу не видели ошибающейся, ничего не доказывает, поэтому задача попадает в стенд только после трёх проверок. Эталонная реализация обязана взять ровно 100 из 100: если эталон валит собственные тесты, неправы тесты. Дальше в копию эталона по одному вносятся 16 намеренных дефектов, и каждый обязан провалить именно те шаги, которые назван провалить, не больше и не меньше. И наконец шесть заведомо негодных сдач (пустой каталог, битый XML, битый BSL, переименованный сервис) обязаны дать честный ноль с внятным вердиктом, а не обрушить оценщик, оставив в отчёте пустоту, которую потом примут за ноль.

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

Лидерборд: что показали прогоны

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

Первое, что видно: задача не различает сильные связки. Opus берёт её на сто и с обвязкой, и без, то есть верх шкалы она не меряет вовсе, для этого нужны задачи сложнее. Второе: обвязка сильной модели не помогает, а по времени вредит. Тот же результат, но вдвое дольше и на доллар дороже, потому что генераторы XML экономят возню с форматом, которой у opus и так нет, зато добавляют ходов на чтение документации самих генераторов.

Третье и самое поучительное: между 31 и 100 у одной модели лежит одна строка кода. Sonnet написал безупречный контракт, все объекты и сигнатуры на месте, L1 сто процентов, конфигурация загрузилась и скомпилировалась. И при этом каждый HTTP-запрос возвращал 500:

// компилируется, но падает при исполнении:
Ответ.УстановитьТелоИзСтроки(СериализоватьJSON(Данные), КодировкаТекста.UTF8, Ложь);

// как надо: третий параметр это значение перечисления, а не булево
Ответ.УстановитьТелоИзСтроки(
    СервисТокенов.ЗначениеВJSON(Данные),
    КодировкаТекста.UTF8,
    ИспользованиеByteOrderMark.НеИспользовать);

Синтаксический контроль эту строку пропустил, проверка контракта не могла увидеть её в принципе. Поймали только настоящие HTTP-запросы к работающей базе. Цена ошибки: 69 баллов из ста. Ровно поэтому в статье выше я и настаиваю мерить долю доведённых до конца задач, а не качество отдельного ответа.

Там же видно, чего стоит экономия на модели. Голый прогон sonnet обошёлся в $12.46 и 43 минуты при 156 ходах и дал 23.8 балла, а opus взял сто за $6.93 и 26 минут. Модель дешевле за токен вышла вдвое дороже за результат, просто потому что ходила кругами.

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

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

В сдаче связки со справкой и живой базой нет ни того, ни другого. Handler записан верно, потому что XML собран генератором, а не руками. Вместо выдуманного метода стоит ПолучитьДвоичныеДанныеИзБуфераДвоичныхДанных, и в транскрипте видно, откуда он взялся: модель искала в справке платформы «получить двоичные данные из строки без потока», затем уточнила сигнатуру. Справка отвела ошибку до того, как та была написана, а не после.

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

Про слабые модели вывод получился неожиданным. Haiku я вывел из таблицы после того, как 13 прогонов из 15 дали ноль, а два прогона одной и той же клетки разошлись на 11.9 и 0 баллов. Разброс одиночного прогона перекрыл всё, что меряют оси эксперимента, и это само по себе результат: единичный замер ничего не доказывает ни в мою пользу, ни против. Провалы при этом были не от непонимания задачи, а от выдуманного API платформы: Новая Структура вместо Новый, несуществующие типы КодировщикBase64 и АлгоритмХеша, оператор Xcor. И отдельно показательно, что дважды модель отчиталась «✓ Syntax validated with 1C Designer» о проверке, которую ей не дали выполнить.

Локальные модели пока не показали ничего, и это тоже честный результат: три оболочки на своём сервере с Qwen3.6-35B упёрлись в 32 тысячи токенов контекста и оборвались на третьем или восьмом ходу, не создав ни одного файла. Такой ноль принадлежит серверу, а не модели, и в общую шкалу он не сводится.

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

И последнее наблюдение, ради которого стоило городить весь стенд. Конфигуратор ловит несуществующую глобальную функцию, несуществующий тип и неверную сигнатуру конструктора (Новый ДвоичныеДанные(Строка, "UTF-8") отвергается как «Конструктор не найден»), а вот вызов несуществующего метода у существующего объекта проходит с кодом ноль. То есть ХешированиеДанных.УстановитьТаймаут() синтаксическая проверка пропустит, и BSL Language Server тоже: он даёт около 450 замечаний по качеству кода, но выдуманные методы не ловит совсем. Практический вывод для вашей работы с ИИ в 1С: «скомпилировалось» не равно «работает», единственная надёжная проверка это выполнить код на живой базе.

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

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

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