LLM + 1С: почему чат-бот для учёта — плохая идея и как реализовать AI-шлюз через OData
- Голосовой ввод транскрибировался в текст отдельным модулем на Java с библиотекой Vosk; далее текст конвертировался в OData-запросы.
- Использовались локальные языковые модели, запущенные через Ollama: Llama 3.1 (8B) как рабочая модель и Mistral Small (24B) для проверки гипотез.
- Для поиска по метаданным применялся RAG: локальная векторизация mxbai-embed-large и векторная БД PostgreSQL с расширением pgvector.
- В ходе тестов автор столкнулся с тем, что модели могут игнорировать вызов инструментов и выдавать нерелевантные ответы, а также искажать результат на этапе генерации текста.
- Финальное решение — универсальный инструмент запроса к 1С, который возвращает пользователю сырой JSON напрямую; после этого отпала необходимость в тяжёлой модели и сервере под RTX 4090.
Почему это важно: В статье показано, что модель способна исказить даже корректно полученные данные, когда формирует человеческий ответ. Для учётных систем критична точность реквизитов и сумм, и «почти правильный» результат становится операционным риском. Поэтому подход, где LLM помогает ориентироваться в структуре данных, а факты возвращаются напрямую из источника, выглядит более устойчивым.
На что обратить внимание: Автор явно ограничивает сценарий закрытым контуром и локальными моделями, что важно для систем, где внешние облачные API недопустимы. В финальной схеме LLM выбирает сущность и параметры фильтрации, а выдача данных идёт напрямую через returnDirect = true, чтобы исключить «испорченный телефон» генерации. Также упоминается слой обогащения контекста полей, который сейчас закомментирован и оставлен как задел для будущей более сложной фильтрации.
Коротко
- Кейс иллюстрирует конфликт: LLM хорошо угадывает намерение, но при пересказе строгих реквизитов «почти правильно» превращается в ошибку.
- Для закрытых контуров ценность часто не в «умном диалоге», а в разделении ролей: модель помогает найти запрос, а факты приходят из источника.
- Увеличение модели помогло убрать одни дефекты (например, дубли), но не дало гарантий: при генерации ответа возможны «додуманные» сущности.
- Если RAG опирается на метаданные, качество сильно зависит от структуры знаний: в описании проекта разделение сущностей и полей повышало релевантность.
- Механика AI-шлюза переносит ответственность в код: модель предлагает параметры, а следующий вопрос — как задаются и проверяются правила таких параметров.
FAQ
Зачем это важно тем, кто хочет подключать LLM к 1С или другим учётным системам, где реквизиты и суммы должны совпадать на 100%?
Автор показывает, что риск появляется на этапе генерации ответа: модель может исказить корректные данные. Поэтому он уводит вывод фактов в прямой возврат JSON из 1С.
Почему даже при правильном OData-запросе и корректном JSON-ответе 1С автор называет чат-бот для учёта плохой идеей?
В тестах модель дублировала записи и «выдумывала» контрагента и ИНН при пересказе результата, хотя исходный JSON был верным.
Как устроен «AI-шлюз» в финальной версии: что делает LLM и что делает Java-инструмент, который обращается к OData-интерфейсу 1С?
LLM определяет сущность и параметры фильтрации, а Java-инструмент выполняет запрос к 1С и возвращает пользователю сырой JSON напрямую через returnDirect = true.
Читайте также
Распознавание реквизитов из карточек контрагентов: как устроен API для извлечения данных из документов- Как тимлид заменил десятки вкладок на файловую систему и Claude Code
- Как научить LLM исправлять код без лишних изменений
- Динамический ресайзинг изображений (Image Previewer)
- LLM-агент для поиска свободных доменов: автоматизация подбора
- Паттерн 'AI-шлюз': LLM как навигатор, данные — напрямую из источника: Когда LLM используется для учётных и любых 'строгих' данных, риск возникает не на этапе получения данных, а на этапе их пересказа: модель может исказить даже корректный JSON, добавив или изменив реквизиты. Архитектурный выход — разделение ролей: LLM определяет сущность и параметры запроса, а фактические данные возвращаются напрямую из системы через API, без генеративного пересказа.
[Архитектура]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Автор описывает эксперимент с чат-ботом для запросов к 1С по OData на базе локальных LLM. В итоге проект переехал в формат AI-шлюза: модель подбирает параметры запроса, а пользователю возвращаются данные 1С без пересказа.