Прямой ответ: дообученная модель не обязательна, если обвязка и RAG на высоте
Дообучать модель под 1С не обязательно, если рядом с ней работает нормальная агентская обвязка и RAG. Автор экспериментального проекта собрал интерактивного помощника на open-source стеке и сравнил его с 1С Напарником на семи вопросах из повседневной работы пользователей и разработчиков 1С. По его описанию, собственный агент чаще выдавал готовые к работе ответы с кодом и порядком диагностики, а Напарник в ряде случаев ограничивался описанием механизма или ссылался на отсутствие информации. Полный разбор сравнения опубликован на Хабре (1С Напарник. Стоит он того?).
Размен оказался прямолинейным. Напарник заметно быстрее: он отвечает предобученной моделью и не тратит время на поиск материалов. Самодельный агент идёт длинным маршрутом: гибридный поиск по базе знаний, дополнительные вызовы LLM, суммаризация найденного. За глубину и конкретику платишь секундами ожидания.
Две оговорки автор делает сразу. Выбор конкретной LLM он оставляет за скобками, тесты шли на моделях уровня deepseek-v4-flash, gpt-6.1-sol и glm-5.3-flash. Затраты на создание и обучение специализированной модели оценить невозможно: публичных цифр в материале нет. С учётом этих оговорок вывод звучит так: топовая модель плюс аккуратная обвязка и RAG дают результат не хуже специализированного дообученного решения, а порог входа в такие сценарии заметно снизился.
Что такое 1С Напарник и open-source агент: краткое описание участников сравнения
1С Напарник - помощник от вендора 1С. Его ресурс - предобученная модель, которая отвечает быстро и без внешних поисковых шагов. Обратная сторона той же конструкции: ответ ограничен тем, что модель уже знает и что попало в её обучение.
Второй участник - интерактивный помощник на open-source стеке. Агентская обвязка построена на Deep Agents поверх LangGraph: из коробки доступны планирование задач, делегирование субагентам с изолированным контекстом и управление контекстным окном через суммаризацию истории. Поиск в базе знаний гибридный: полнотекстовая ветка на FTS PostgreSQL с русским словарём, векторная на pgvector с HNSW-индексом, слияние результатов через Reciprocal Rank Fusion. Структуру конфигураций разбирает парсер метаданных, интернет ищется через API Яндекса.
Контекст полезно держать в голове: тема ИИ-агентов у разработчиков 1С обсуждается активно, и спорят там не только о моделях (разбор самых обсуждаемых материалов сообщества 1С в 2026 году).
Архитектура open-source агента: как устроена обвязка, которая заменяет дообучение
Обвязка состоит из нескольких слоёв, и каждый закрывает свою часть работы, которую при дообучении пришлось бы вкладывать в веса модели.
Гибридный RAG-поиск: PostgreSQL FTS + pgvector и Reciprocal Rank Fusion
Полнотекстовая ветка работает на FTS PostgreSQL с русским словарём. Это важно для вопросов, где есть точные идентификаторы: имена объектов метаданных, события технологического журнала, названия процедур. Векторная ветка использует расширение pgvector с HNSW-индексом и ловит фрагменты, близкие по смыслу, даже если формулировка пользователя не совпадает с текстом документации.
Дальше результаты двух выдач сливаются через Reciprocal Rank Fusion: кандидат, занявший высокое место хотя бы в одной ветке, поднимается в итоговом списке. Смысл простой. Чисто векторный поиск теряет точные идентификаторы и путает похожие объекты. Чисто полнотекстовый не находит перефразировки. RRF отдаёт агенту и точное совпадение по имени, и смысловую близость.
Парсер метаданных конфигураций: ориентация в тысячах модулей
Для ориентации в тысячах модулей написан парсер метаданных конфигураций. Он собирает объекты, реквизиты и связи между ними, поэтому агент отвечает не по случайно найденному куску текста, а с учётом того, к какому объекту относится код и с какими регистрами он связан.
Масштаб материала, с которым всё это работает: пять выгрузок типовых конфигураций дают около 236 тысяч файлов и 193 тысячи каталогов. Для исходников типовых конфигураций используется отдельный быстрый поиск, иначе агент тонул бы в переборе файлов. Похожая задача, сборка контекстной инфраструктуры для разбора кода, разобрана в материале про агента, который закрыл исследовательские запросы аналитиков (архитектура на tree-sitter и уроки внедрения).
Интернет агент ищет через API Яндекса; по утверждению автора, выдача по России релевантнее, чем у поисковиков, встроенных в чаты LLM. Найденные сведения агрегируются и суммаризируются, а не сваливаются в ответ сырым списком ссылок. Детали стека автор приводит в исходном разборе на Хабре (1С Напарник. Стоит он того?).
Сравнение на семи практических вопросах: где open-source агент выиграл, а где Напарник
Сравнение шло на семи вопросах из повседневной работы пользователей и разработчиков 1С. В доступном фрагменте исходного материала подробно раскрыты пять сценариев, полные ответы Напарника там не приведены. Ниже то, что описывает автор, с пометками там, где данных меньше, чем нужно для строгого вывода (описание эксперимента).
Настройка технологического журнала для таймаутов управляемых блокировок
Самый показательный сценарий. Агент выдал конфигурацию технологического журнала с фильтром длительных ожиданий, объяснил, как найти блокирующее соединение, и предложил дополнительные события, чтобы докопаться до причины долгой транзакции.
Ключевая мысль ответа: фиксировать нужно не только ошибку, но и соединение, которое удерживало блокировку. Начинать разбор стоит с событий TTIMEOUT, TDEADLOCK и ожиданий TLOCK. Сбор включается на сервере 1С через файл logcfg.xml в каталоге conf используемой установки платформы.
Фрагмент конфигурации из ответа:
<log location="D:\TJ\Locks" history="4">
<event>
<eq property="name" value="TLOCK"/>
<gt property="duration" value="1000000"/>
</event>
</log>В конфигурации заданы каталог хранения D:\TJ\Locks, глубина хранения history="4" и два условия отбора события: по имени TLOCK и по длительности ожидания. Фильтр по duration отсекает короткие срабатывания, чтобы журнал не разрастался на ровном месте. Читатель получает готовый файл и порядок действий вместо абзаца про то, что технологический журнал вообще существует.
Подключение нетипового справочника к подсистеме версионирования БСП
Задача из категории интеграции с БСП: нужно понять, как подсистема версионирования подключается к объекту, которого нет в типовой поставке. Автор относит этот вопрос к тем, где open-source агент дал готовый к работе ответ. Полный текст решения в доступном фрагменте не приведён, поэтому конкретные шаги подключения здесь не пересказываем: ограничимся констатацией, что по описанию автора ответ оказался применимым на практике.
Запрет отмены проведения документа с уже списанными партиями
Прикладная задача про бизнес-логику: не дать отменить проведение документа, если партии уже списаны. Такой ответ проверяется практикой: либо предложенный порядок действий и код работают, либо нет. По описанию автора, агент дал готовое решение с порядком действий, а Напарник по совокупности разобранных вопросов чаще ограничивался описанием механизма.
Версионирование присоединённых файлов и расхождение остатков в УТ 11.5
Два оставшихся примера из перечня. Первый - версионирование присоединённых файлов: задача про механику хранения версий вложений. Второй - расхождение остатков с регистром себестоимости в УТ 11.5, то есть диагностика расхождения данных между отчётом и регистром. Автор указывает, что и здесь агент дал рекомендации, готовые к работе, тогда как Напарник в ряде случаев описывал механизм и не доводил ответ до последовательности проверок.
Скорость и ресурсозатраты: почему Напарник быстрее, а агент - глубже
Разница в скорости объясняется количеством шагов до первого токена ответа. Напарник делает один проход предобученной моделью. Собственный агент перед ответом планирует задачу, ищет в полнотекстовой и векторной ветках, при необходимости лезет в исходники типовых конфигураций, вызывает LLM повторно и суммаризирует историю, чтобы не переполнить контекст. Каждый шаг добавляет задержку, и на простом вопросе она заметна.
Отсюда практическое разделение. Для типовой справки и быстрого уточнения выигрывает Напарник: секунды против десятков секунд. Для диагностики, где нужен код, порядок проверок и привязка к конкретным объектам конфигурации, выигрывает агент: скорость ответа перестаёт быть главной метрикой, когда ответ всё равно приходится перепроверять в отладчике.
Модели, на которых шло тестирование, deepseek-v4-flash, gpt-6.1-sol и glm-5.3-flash, по описанию автора все нормально работают с вызовами инструментов и имеют достаточное контекстное окно. Выбор конкретной модели автор оставил за скобками, и это логично: обвязка переносится между моделями, а задержка и стоимость ответа зависят от неё не меньше. Экономику агентских прогонов и границы окупаемости разбирает отдельный материал про агента и человека в QA (11 недель замеров, 277 агентских часов и 80 ₽ за час работы агента).
Ограничения сравнения и открытые вопросы
Границы выводов стоит обозначить до того, как читатель побежит переписывать рабочий стек.
- Модель за скобками. Автор не сравнивал конкретные LLM между собой, тесты шли на моделях уровня deepseek-v4-flash, gpt-6.1-sol и glm-5.3-flash.
- Стоимость обучения неизвестна. Затраты на создание и обучение специализированной модели оценить невозможно, значит, сравнение с дообучением идёт по качеству ответов, а не по бюджету.
- Неполная выборка. Семь вопросов - малая выборка, а в доступном фрагменте подробно раскрыты пять сценариев из семи; полные ответы Напарника не приведены.
- Оценки со слов автора. Утверждения о том, что агент чаще давал готовые ответы, а Напарник быстрее, опираются на описание автора материала, а не на независимую проверку.
- Зависимость от контекста. Результат меняется от версии Напарника, версии платформы, редакции конфигурации и качества внутренней базы знаний.
Отдельный фактор, который в таких сравнениях часто упускают: поведение модели на длинном контексте и цена инференса зависят от архитектуры и версии модели, а не только от размера окна (разбор про выбор модели, бенчмарки и стоимость инференса в 2026 году).
Практические выводы: кому и когда стоит собирать своего агента
Порог входа в собственного агента снизился, но не до нуля. Минимальный рабочий стек по этому кейсу выглядит так: агентская обвязка на Deep Agents и LangGraph, гибридный поиск на PostgreSQL FTS и pgvector с Reciprocal Rank Fusion, парсер метаданных конфигураций и отдельный быстрый поиск по выгрузкам исходников.
Собирать своё стоит, когда:
- вопросы выходят за типовую документацию и требуют кода под конкретную конфигурацию;
- есть внутренняя база знаний, которой нет в публичных источниках;
- нужна кастомизация под свой процесс, а не готовый чат с фиксированными настройками;
- появляются требования к приватности и локальному контуру.
Напарник остаётся быстрее и удобнее для типовых вопросов: когда нужен короткий ответ по механизму платформы, а не готовый блок кода с порядком диагностики.
Что закладывать в бюджет времени и ресурсов: поддержку обвязки, обновление парсера под новые версии конфигураций, индексацию исходников (пять выгрузок это 236 тысяч файлов), оплату вызовов LLM и поискового API. Практичный старт: поднять RAG-поиск по своей базе знаний, прогнать десяток своих задач и только потом решать, нужна ли дообученная модель.