ИИ анализ договоров в 1С: когда хватит HTTP-сервера, а когда нужна локальная LLM

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

AI Summary

• Для подключения ИИ к 1С обычно есть два практичных пути: собственный HTTP-сервер внутри 1С или готовый экстрактор данных.
• Локальная LLM оправдана не всегда: для простых OCR, транскрибации и классификаций хватает небольших моделей, но для юридического анализа договоров нужны более крупные модели и строгая проверка качества.
• Большие договоры на 20-30 страниц нельзя просто целиком отправлять в маленькую модель. Их нужно разбивать на части, проверять по правилам и собирать итог.
• Основная сложность не в том, чтобы запустить модель, а в стабильном пайплайне: данные, очередь, авторизация, валидация, observability, оценка качества и восстановление после сбоев.
• По материалам консультации, для серьезной офисной задачи не стоит начинать ниже класса 120B, а 30B/70B лучше рассматривать только после тестов на реальных документах.

Оглавление

• С чего начинать проект ИИ для 1С?
• Как вытащить данные из 1С: HTTP-сервер или экстрактор?
• Сколько стоит интеграция с 1С?
• Когда локальная LLM имеет смысл?
• Почему анализ договоров сложнее обычного чат-бота?
• Какую архитектуру выбрать для AI-пайплайна?
• Как снижать галлюцинации и проверять качество?
• Что выбрать: API, локальную модель или гибрид?
• FAQ

С чего начинать проект ИИ для 1С?

Ключевые выводы: сначала нужно описать объем документов, число пользователей, требования к качеству и ограничения по данным. Без этого выбор модели, сервера и бюджета будет случайным.

[Факт]: в консультации несколько раз подчеркивается, что проект "упирается в нефункциональные требования": сколько документов обрабатывать, сколько людей будет пользоваться системой и какой уровень качества нужен.

Типичная ошибка - начинать с вопроса "какую нейросеть поставить?". Для проекта вокруг 1С правильнее сначала ответить на другие вопросы:

• где лежат договоры: в 1С, файловом хранилище, PDF-архиве, базе или смешанно;
• сколько договоров в корпусе: сотни, тысячи или сотни тысяч;
• какой средний размер договора: 2-3 страницы или 20-30 страниц;
• нужно ли проверять документы регулярно или только по запросу пользователя;
• какие изменения нужно отслеживать: поля договора, статьи, сроки, нормативные требования, шаблоны писем;
• можно ли отправлять документы во внешние API или все должно оставаться в контуре компании;
• какой уровень качества приемлем: "помощник для черновика" или 90-95% точности на критичных задачах.

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

Как вытащить данные из 1С: HTTP-сервер или экстрактор?

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

[Факт]: в расшифровке называются два самых обиходных способа: HTTP-сервер в 1С и готовые экстракторы данных.

Вариант 1. HTTP-сервер внутри 1С

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

Плюсы:

• можно сделать ровно те методы, которые нужны проекту;
• для простых задач обычно дешевле, чем покупать большой экстрактор;
• удобно для MVP и ограниченного набора объектов;
• проще контролировать бизнес-логику на стороне 1С.

Минусы:

• нужен специалист по 1С, который понимает конкретную конфигурацию;
• при большом количестве методов стоимость быстро растет;
• самописные конфигурации часто требуют ручной адаптации;
• масштабируемое универсальное решение сделать сложно.

Вариант 2. Экстрактор данных из 1С

Экстрактор ставится как дополнительный модуль в 1С. В графическом интерфейсе выбирают объекты, поля, формат выгрузки и целевое хранилище: например, PostgreSQL, ClickHouse или другую базу. Выгрузка может идти по расписанию или по событиям.

Плюсы:

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

Минусы:

• лицензии и внедрение могут стоить заметно дороже простого HTTP-сервера;
• универсальность все равно ограничена конфигурациями 1С;
• иногда нужна помощь интегратора;
• для простого MVP это может быть избыточно.

Критерий	HTTP-сервер в 1С	Экстрактор данных
Лучший сценарий	Несколько понятных методов и MVP	Регулярная выгрузка множества объектов
Стоимость старта	Ниже при простой задаче	Выше из-за лицензии и внедрения
Гибкость	Высокая, но нужна разработка	Высокая в рамках возможностей продукта
Зависимость от 1С-специалиста	Высокая	Средняя или высокая на внедрении
Масштабирование	Требует проектирования	Удобнее для data-пайплайна

Сколько стоит интеграция с 1С?

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

[Факт]: в разговоре простая разработка HTTP-интеграции оценивалась от 100-150 тысяч рублей и выше, а экстракторы и комплексные решения обсуждались в диапазоне от сотен тысяч до 1,2-1,4 млн рублей и выше.

Эти цифры нельзя использовать как коммерческое предложение. Они полезны как порядок бюджета. В реальном проекте стоимость меняется из-за пяти факторов:

1. Сколько баз 1С нужно подключить.
2. Насколько типовая или самописная конфигурация.
3. Сколько объектов, документов и полей нужно выгружать.
4. Нужны ли проверки, журналирование, права доступа и отказоустойчивость.
5. Кто делает работу: фрилансер, штатный 1С-специалист, интегратор или команда продукта.

Для простого MVP разумно сначала оценить HTTP-сервер: несколько методов, тестовая среда, проверка, перенос на прод, отзыв доступов. Для большого контура, где данные должны регулярно попадать в отдельную аналитическую базу, экстрактор может оказаться сопоставимым по цене, но более удобным по сопровождению.

Когда локальная LLM имеет смысл?

Ключевые выводы: локальная LLM нужна, когда данные нельзя отправлять наружу, есть бюджет на инфраструктуру и команда готова поддерживать качество. Для многих задач проще и надежнее использовать внешние API или гибридный подход.

[Факт]: в консультации отдельно сказано: локальные модели "без чудес" начинают уверенно работать в сложных агентских сценариях ближе к крупным моделям, а 30B/70B нужно обязательно проверять на реальных задачах.

Локальная модель выглядит привлекательно: данные остаются внутри, нет зависимости от внешнего API, можно контролировать сервер. Но для анализа договоров этого недостаточно. Нужно качество, контекст, скорость, параллельность и восстановление после сбоев.

Упрощенное правило по памяти из консультации: при FP8-квантизации модель примерно занимает столько гигабайт видеопамяти, сколько в ней миллиардов параметров, плюс запас на контекстное окно. Для 30B это около 30 GB VRAM плюс контекст. Для 120B нужны уже несколько GPU или квантизация, а для более крупных моделей инфраструктура становится очень дорогой.

Класс модели	Где может хватить	Где рискованно
1-10B	OCR-подзадачи, простая классификация, извлечение коротких полей	Юридический анализ, сложные выводы, длинные договоры
30B	Простые проверки, "да/нет", короткие инструкции после тестов	Агентские сценарии, длинный контекст, надежные юридические выводы
70B	Более сложные классификации и резюмирование	Полная проверка договоров без сильной декомпозиции
120B+	Минимально разумный класс для серьезного офисного анализа	Все равно требует eval, chunking и перепроверок
300-500B+	Более зрелые агентские сценарии	Очень дорогая инфраструктура

В консультации звучал ориентир: 120B-модель может "впритык" поместиться в две 48 GB видеокарты в сжатом формате. Но "поместиться" не означает "стабильно решить юридическую задачу". Это только инфраструктурный минимум для эксперимента.

Почему анализ договоров сложнее обычного чат-бота?

Ключевые выводы: договоры длинные, формулировки неоднозначные, требования меняются, а ошибки дорого стоят. Поэтому систему нужно разбивать на этапы и проверять результат, а не просить модель "прочитать все и ответить".

[Факт]: в примере из консультации обсуждалась база до 500 тысяч договоров, договоры на 20-30 страниц и задача периодически проверять изменения и готовить шаблоны писем.

Для пользователя все выглядит просто: загрузить договор, спросить модель, получить ответ. Внутри задача сложнее:

• договор нужно распознать, если это PDF или скан;
• текст нужно разбить на смысловые части;
• нужно отдельно хранить актуальные правила, изменения законодательства и внутренние требования;
• по каждому фрагменту нужно выполнить ограниченный набор проверок;
• ответы нужно собрать в единый вывод;
• итог нужно верифицировать, чтобы модель не придумала статью, обязанность или риск.

Если загрузить 20-30 страниц в маленькую модель и попросить общий вывод, качество резко падает. Модель может пропустить важную часть, перепутать контекст, сделать уверенный, но неверный вывод. Поэтому рабочий подход - chunking, правила, отдельные микрозадачи и eval.

Пример декомпозиции:

1. Извлечь структуру договора: стороны, даты, предмет, обязательства, штрафы, сроки.
2. Разбить документ на блоки: общие условия, предмет, ответственность, расторжение, приложения.
3. Для каждого блока выполнить 2-3 проверки, а не десятки сразу.
4. Сравнить результаты с базой актуальных требований.
5. Сформировать черновик вывода и список цитат из договора.
6. Отдельно проверить итог на противоречия.
7. Передать результат в 1С, веб-интерфейс, Telegram или рабочую очередь специалиста.

Какую архитектуру выбрать для AI-пайплайна?

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

[Факт]: в консультации как минимальные элементы назывались FastAPI, Kafka, отдельные микросервисы, PostgreSQL, Docker или Kubernetes, vLLM/LM Studio/Ollama, LiteLLM, Langfuse и Grafana.

Базовая схема может выглядеть так:

Компонент	Роль
1С HTTP-сервер или экстрактор	Отдает документы, поля и события
PostgreSQL/ClickHouse	Хранит выгруженные данные и результаты обработки
FastAPI-сервис	Принимает запросы, управляет задачами, отдает ответы
Kafka или другой брокер	Организует очередь между микросервисами
Inference-сервер	Запускает модель через vLLM, LM Studio или Ollama
Worker pipeline	Делит договоры на части, вызывает модель, собирает результат
Сервис законодательства	Хранит обновления правил отдельно от LLM
Авторизация	Ограничивает доступ пользователей и сервисов
Langfuse/LiteLLM/Grafana	Логи, трассировка, лимиты, метрики и наблюдаемость
Kubernetes или Docker	Развертывание, health-check, перезапуск зависших сервисов

vLLM в разговоре описывается как более быстрый inference-движок, но более требовательный к настройке. LM Studio и Ollama проще для старта, однако обычно медленнее. Для офисного сценария разница в 15-20% скорости может быть не критична на MVP, но станет заметной при росте очереди и параллельных пользователей.

Очередь нужна обязательно. Если два пользователя уже отправили запрос, а GPU занят, третий не должен получать ошибку. Задача должна встать в очередь, дождаться обработки и вернуть результат. Также нужны health-check и перезапуск: inference иногда зависает, после перезагрузки модели нужно заново загрузить веса в память, а это занимает время.

Как снижать галлюцинации и проверять качество?

Ключевые выводы: качество юридического AI-пайплайна достигается не одним промптом, а eval-набором, фиксированными правилами, повторяемыми проверками и измерением отклонений.

[Факт]: в консультации оценка и доведение качества названы самой трудоемкой частью: построить пайплайн можно быстрее, чем довести стабильность до 90-95%.

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

Практический контроль качества:

• собрать датасет реальных договоров и эталонных ответов;
• разделить задачи: извлечение полей, поиск рисков, проверка правил, письмо, сводка;
• для каждой задачи измерять точность отдельно;
• сохранять промпт, вход, выход, модель, температуру и версию пайплайна;
• повторно прогонять eval после каждого изменения модели или промпта;
• использовать цитирование фрагментов договора как обязательное условие вывода;
• внедрить human-in-the-loop для критичных решений.

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

Что выбрать: API, локальную модель или гибрид?

Ключевые выводы: если законодательные или договорные ограничения разрешают внешние API, их стоит протестировать первыми. Если данные нельзя выводить наружу, локальная модель или private cloud становятся реалистичнее, но дороже и сложнее.

[Факт]: в консультации для нормативно-правовых данных обсуждался гибрид: более умные API-модели могут готовить сводки по законодательству, а локальная модель использовать уже подготовленные данные внутри контура.

Решение можно принимать по таблице:

Сценарий	Рекомендация
Нужно быстро проверить идею	API сильной модели + небольшой прототип
Данные строго нельзя отправлять наружу	Локальная LLM или private GPU cloud
Нужно обрабатывать много 1С-объектов	Экстрактор + отдельное хранилище
Нужны 3-5 методов из 1С	HTTP-сервер внутри 1С
Договоры длинные и юридически важные	Chunking, eval, human review, крупная модель
Нужен дешевый MVP	HTTP-сервер + внешняя API-модель на обезличенных данных
Нужен промышленный контур	Микросервисы, очередь, observability, регламент поддержки

Гибрид часто оказывается самым практичным. Например, изменения законодательства можно собирать отдельным сервисом и предварительно обрабатывать сильной моделью там, где это допустимо. Затем локальная система получает уже структурированную сводку и сравнивает ее с договорами. Это снижает количество tool calls, уменьшает нагрузку на локальную модель и повышает управляемость качества.

Практический план запуска

Ключевые выводы: начинать стоит с архитектурного проектирования и короткого пилота на реальных документах. Покупка GPU без eval почти всегда приводит к разочарованию.

[Факт]: в консультации предлагается сначала потратить несколько дней на проектирование, перепроверку решений и декомпозицию задачи, а не сразу "хуяк в продакшн".

План на первые 4-6 недель:

1. Описать целевые сценарии: что именно система должна находить в договоре.
2. Выбрать способ получения данных из 1С: HTTP-сервер или экстрактор.
3. Собрать 50-100 реальных договоров для тестов и эталонной разметки.
4. Проверить 2-3 модели через API или open-router-подобный доступ, если это допустимо.
5. Проверить локальные модели на тех же примерах, начиная не с интерфейса, а с качества.
6. Разработать пайплайн chunking + правила + вывод с цитатами.
7. Добавить очередь, логи, лимиты и сохранение всех входов/выходов.
8. Сравнить стоимость API, private cloud и собственного GPU.
9. Запустить пилот на ограниченной группе пользователей.
10. Только после eval принимать решение о покупке железа или промышленном внедрении.

FAQ

Можно ли просто подключить ChatGPT-подобную модель к 1С?

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

Что лучше для 1С: HTTP-сервер или экстрактор?

Если задача простая и нужны конкретные методы, часто достаточно HTTP-сервера в 1С. Если нужно регулярно выгружать много объектов, полей и документов в отдельное хранилище, удобнее смотреть в сторону экстрактора.

Подойдет ли модель 30B или 70B для анализа договоров?

Для простых проверок и коротких задач - возможно, после тестов. Для надежного анализа длинных юридических документов без декомпозиции - рискованно. По материалам консультации, для серьезной офисной задачи стоит смотреть минимум на класс 120B и все равно строить eval.

Нужно ли покупать собственные GPU?

Не всегда. Можно начать с API или аренды GPU в private cloud. Собственное железо имеет смысл, когда понятны требования, нагрузка, ограничения по данным и экономика владения.

Почему нельзя загрузить весь договор в модель сразу?

Длинный договор перегружает контекст, особенно у маленьких моделей. Модель может пропустить важные пункты или смешать разные части документа. Надежнее разбивать договор на смысловые блоки и проверять каждый по ограниченному набору правил.

Какой inference-движок выбрать?

Для быстрого промышленного инференса часто смотрят на vLLM. Для простого запуска и экспериментов удобны LM Studio или Ollama. Разница важна, но качество пайплайна и модели обычно важнее, чем 15-20% скорости на старте.

Вывод

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

Локальная LLM нужна не потому, что "так безопаснее", а потому что ограничения по данным, нагрузка и экономика делают ее оправданной. Для простых задач можно начать с API и MVP. Для серьезного контура с сотнями тысяч договоров, длинными PDF и юридическими выводами нужен полноценный пайплайн: декомпозиция, eval, observability, очереди, проверка качества и команда, которая понимает и 1С, и LLM-инфраструктуру.