Практический эксперимент, опубликованный в потоке публикаций о разработке, поставил под сомнение тезис о безусловном превосходстве специализированных моделей от вендора. Разработчик сравнил интерактивного помощника, собранного на open-source компонентах, с «Напарником» от 1С на типовых вопросах, с которыми ежедневно сталкиваются пользователи и программисты. В качестве полигона использовались реальные задачи коллег по цеху, а не синтетические тесты. Главный вопрос формулируется так: что эффективнее — дорогое дообучение узкой модели или качественная инженерная обвязка вокруг универсальной облачной LLM. На первый взгляд кажется очевидным, что модель от вендора с привилегированным и неограниченным доступом к материалам не оставит камня на камне от конкурентов. Но, возможно, рынок уже дошёл до момента, когда разница в качестве ответов общих и специализированных моделей не оправдывает затрат на дообучение.

Самодельный агент построен на агентской обвязке Deep Agents на базе LangGraph, которая из коробки даёт планирование задач, делегирование субагентам с изолированным контекстом и управление окном через суммаризацию истории. Выбор конкретной языковой модели автор оставил за скобками, отметив, что все топовые решения сопоставимого уровня хорошо работают с вызовами инструментов и имеют приличное контекстное окно. Тестирование проводилось на моделях класса deepseek-v4-flash, gpt-6.1-sol и glm-5.3-flash. Основой послужило хорошо структурированное индексное дерево базы знаний на RAG-индексах с гибридным поиском: полнотекстовая ветка на FTS PostgreSQL с русским словарём и векторная на pgvector с HNSW-индексом, результаты которых сливаются через Reciprocal Rank Fusion — кандидаты с высоким местом в каждой выдаче поднимаются в итоговом списке. Такая архитектура позволяет не полагаться на одну стратегию поиска, а комбинировать точное совпадение терминов с семантической близостью, что особенно важно для предметной области 1С с её специфической терминологией и сокращениями.

Отдельного внимания заслуживает работа с исходниками типовых конфигураций. Пять выгрузок — это около 236 тысяч файлов и 193 тысячи каталогов, и на современном железе такой объём не является проблемой при хороших алгоритмах. Для ориентации в тысячах модулей разработчики написали парсер метаданных, собирающий объекты, реквизиты и связи между ними. Поиск в интернете реализован через API Яндекса, который даёт более релевантную выдачу по России, чем встроенные в чаты LLM поисковики; найденные сведения агрегируются и суммаризируются. В качестве тестового вопроса был взят сценарий настройки технологического журнала для поиска причин таймаутов управляемых блокировок. Этот выбор показателен: задача требует не просто знания синтаксиса logcfg.xml, но и понимания того, как платформа фиксирует события TLOCK, TTIMEOUT и TDEADLOCK, как сопоставлять номера соединений с сеансами и какие дополнительные события CALL, SCALL, SDBL, DBMSSQL или DBPOSTGRS подключать для диагностики блокирующего соединения.

Оба помощника справились с задачей, но продемонстрировали разные акценты. Агент на open-source стеке выдал конфигурацию журнала с фильтром длительных ожиданий, объяснил, как найти блокирующее соединение, и предложил дополнительные события для поиска причины долгой транзакции. «Напарник» также привёл конфигурацию и указал на WaitConnections, однако подробнее остановился на сборе материалов для расследования, а не на разборе действий блокирующего соединения. Иными словами, вендорный помощник оказался сильнее в формальной стороне вопроса, тогда как самодельный агент глубже проработал диагностический сценарий. Показательно, что open-source решение не просто выдало XML-заготовку, но и предупредило о необходимости контролировать объём собираемых данных, не включать все события надолго и не путать номер соединения с номером сеанса — то есть продемонстрировало понимание эксплуатационных рисков, а не только справочную эрудицию.

Контекст этого сравнения выходит за рамки одной задачи. На рынке корпоративных ИИ-ассистентов идёт конкуренция между стратегией глубокой специализации, требующей дообучения на проприетарных данных, и стратегией универсальной модели с развитой обвязкой. Первая обещает точность за счёт привилегированного доступа к материалам вендора, вторая — гибкость и скорость адаптации. Российские разработчики 1С находятся в особом положении: доступ к внешним облачным сервисам ограничен, а требования к локальному развёртыванию и защите данных высоки. Поэтому вопрос о том, стоит ли платить за специализированное решение, если open-source агент показывает сопоставимый результат, становится практическим. Для российского рынка значение этого эксперимента двояко. С одной стороны, он подтверждает, что отечественные вендоры способны создавать продукты, конкурирующие с самодельными сборками на открытых компонентах. С другой — демонстрирует зрелость open-source инструментов и доступность инфраструктуры вроде PostgreSQL с pgvector и LangGraph, что снижает барьер входа для небольших команд. Отраслевая реакция пока сдержанная: обсуждение ведётся в профессиональных сообществах, где участники отмечают, что итоговый выбор зависит от бюджета, требований к поддержке и готовности нести расходы на дообучение. Сравнение с альтернативами показывает, что универсальные облачные модели в связке с грамотным RAG-поиском уже решают значительную часть прикладных задач без узкоспециализированного тюнинга.

Перспективы дальнейшего противостояния будут определяться тем, насколько быстро вендоры смогут улучшать свои модели за счёт уникальных данных и насколько доступными останутся вычислительные ресурсы для самостоятельной сборки. Открытым остаётся вопрос о стоимости владения: экономия на дообучении может обернуться затратами на инженерную поддержку и интеграцию, а также на сопровождение парсера метаданных и гибридного поиска при обновлении типовых конфигураций. Кроме того, неясно, как поведут себя open-source агенты на задачах, требующих глубокого понимания закрытой внутренней документации заказчика, — там, где привилегированный доступ вендора к материалам может дать решающее преимущество. Ещё один открытый вопрос — воспроизводимость результата: один тестовый сценарий не позволяет делать статистически значимых выводов, и для полноценной оценки потребуется серия задач разного профиля. Тем не менее сам факт появления такого сравнения говорит о том, что рынок ИИ-помощников для 1С переходит от этапа восторженного внедрения к этапу прагматичной оценки эффективности, где на первый план выходят измеримые метрики, а не маркетинговые обещания.