Не наступайте на грабли, на которые наступили мы
Типичная картина: бизнес просит «чат-бота по 1С», вы за выходные склеиваете RAG-пайплайн в ноутбуке, демонстрируете — все в восторге. Через месяц — кошмар. Бот отвечает невпопад, половину вопросов пропускает, контекст рвется, пользователи шлют скриншоты с криками «он галлюцинирует!». Знакомо? В этой статье — наш реальный путь от прототипа RAG для 1С УНФ до production-ready AI-агента, который реально экономит деньги. Без рекламных обещаний, только цифры, архитектура и решения, которые мы приняли под давлением метрик.
Если вам нужен подробный roadmap по RAG 2026 — у нас есть отдельная статья. А здесь — хроника борьбы с энтропией.
Фаза 0: когда «просто RAG» работает только в Jupyter
Наша поддержка по 1С УНФ тонула: 300+ обращений в день, среднее время ответа — 40 минут. Внедрили простую RAG-схему на LangChain + OpenAI text-embedding-3-large (тогда еще актуальный). Индекс — FAISS, чанки по 512 токенов. В тестах на 50 вопросах — точность 70%, полнота 85%. Руководство довольно, неделю собираем похвалы. А потом — реальные пользователи.
⚠️ Первая же неделя в продакшене показала:
- Точность упала до 38% (пользователи задавали вопросы иначе, чем датасет).
- 25% ответов содержали грубые ошибки — модель ссылалась на несуществующие документы.
- Время ответа — до 12 секунд (OpenAI API + ретривер).
- Пользователи просто закрывали чат, не дождавшись ответа — показатель abandon rate 68%.
1 Что сломалось в простом RAG
Мы допустили классическую ошибку — прототип проверяли на вопросах из документации, а не из реальных тикетов. Реальные вопросы — это «Почему не закрывается накладная?», а не «Как закрыть накладную по УНФ?». Модель не умела переформулировать контекст. К тому же в 1С есть тонна специфических терминов (акты, сверки, счета-фактуры), и эмбеддинги плохо схватывали синонимы. Итог: простой RAG не готов к продакшену, если нет культуры метрик и A/B-тестов.
Фаза 1: Метрики как компас — что и как измерять
Вместо того чтобы бросаться усложнять архитектуру, мы сели и определили, что для бизнеса важно. Сформировали три ключевых метрики:
| Метрика | Формула / Как считали | Целевое значение |
|---|---|---|
| Coverage (покрытие) | % вопросов, на которые бот дал хотя бы какой-то ответ | >90% |
| Answer Accuracy | Экспертная оценка по 3-балльной шкале (0 — неверно, 0.5 — частично, 1 — верно). Мы наняли двух консультантов 1С. | >0.85 |
| Abandon Rate | % диалогов, где пользователь ушел без дополнительного действия | <30% |
Дополнительно замеряли latency (цель <3 с) и затраты (цель <$0.05 на запрос). Без этих метрик любое решение — гадание. Как раз об этом мы писали в статье про проблемы контекста в бизнес-среде.
Фаза 2: Гибридный поиск и улучшение ретривера
Первое, что мы сделали — заменили тупой семантический поиск на гибридный: BM25 + векторный поиск с весами 0.3/0.7. Подняли топ-10 чанков до топ-15. Добавили реранкер (cross-encoder) на входе в LLM. Модель — Llama 3 70B (через Together AI, дешевле OpenAI). Размер чанков уменьшили до 256 токенов, перекрытие 32 токена. Это дало прирост точности до 78%, покрытие — до 72%. Но abandon rate оставался 55% — пользователи все еще не получали конкретного ответа на свой вопрос.
💡 Инсайт: гибридный поиск — must have для RAG, он решает проблему синонимов и ключевых терминов. Детали — в нашем roadmap по RAG 2026.
Фаза 3: Промпт-инжиниринг и контекстный RAG
Следующий шаг — мы перестали кормить LLM плоскими чанками. Добавили в промпт структурированное описание контекста: тип документа, дата, номер, фрагмент. Научили модель явно указывать источник. Подготовили шаблоны промптов — вот готовые шаблоны для RAG. Результат: метрика accuracy выросла до 0.85, покрытие — до 78%, abandon rate — 43%. Уже неплохо, но бизнес хотел большего: например, чтобы бот мог зайти в 1С и проверить статус документа.
«Мы хотим, чтобы бот сам делал проводки, а не просто рассказывал теорию» — сказал финдиректор.
Тут мы поняли: простым RAG задачу не закрыть. Нужен агент с инструментами.
Фаза 4: Агентный RAG с инструментами
Мы построили Agentic RAG. Основа — ReAct паттерн: LLM получает задачу, выбирает действие (поиск по базе знаний, вызов API 1С через REST, запрос уточнения у пользователя), выполняет, анализирует результат и повторяет. В качестве LLM использовали GPT-4.5 (по состоянию на май 2026 — уже есть GPT-5, но мы остановились на 4.5 из-за соотношения цена/качество). Инструменты:
- search_knowledge_base — гибридный поиск с reranker
- call_1c_api — выполнение запроса к 1С через HTTP (только для чтения данных, запись через approval)
- get_user_context — получение информации о пользователе (роль, права, история обращений)
⚠️ Ошибка, которую мы совершили — дали агенту слишком много свободы. Он начал вызывать API 1С на каждый чих, даже когда ответ можно было найти в базе знаний. Это взвинтило latency до 18 секунд и стоимость до $0.12 на запрос. Пришлось ограничить: вызывать внешние инструменты только если уверенность в ответе из базы ниже 0.7.
После настройки cost control и throttle получили финальные метрики:
| Метрика | Фаза 1 (простой RAG) | Фаза 4 (Agentic RAG) |
|---|---|---|
| Coverage | 68% | 91% |
| Answer Accuracy | 0.38 | 0.92 |
| Abandon Rate | 68% | 22% |
| Avg Latency | 12 с | 4.5 с |
| Cost per query | $0.02 | $0.07 |
Агент окупился: время ответа поддержки сократилось с 40 минут до 3 минут, уровень эскалаций упал на 70%. Пользователи перестали ненавидеть бота.
Фаза 5: Production-readiness — мониторинг, откаты, надежность
Продакшен — это не только качество ответов, но и устойчивость. Мы внедрили:
- Health checks для LLM-эндпоинтов и 1С API.
- Fallback на простой RAG в случае ошибки агента.
- Логирование всех шагов агента в ClickHouse для ретроспективного анализа.
- Ценовые алерты — если cost per query превышает $0.10, система автоматически переключается на более дешевую модель (например, Llama 4 70B).
Об архитектуре production-ready агентов мы подробно писали здесь. А про дисциплину Agent Engineering — отдельная статья.
Ключевой урок: не стройте агента, пока RAG не выжал максимум
Самый частый вопрос от коллег: «Почему вы не начали сразу с агента? Дорого?». Нет, дело в неизвестности. Если вы не понимаете, где именно ломается ваш RAG, агент только добавит хаоса. В нашем случае первые 70% улучшений дали гибридный поиск и промпт-инжиниринг. Агент был нужен для последних 20% — когда задача требует действий, а не консультации. Иногда достаточно просто Agentic RAG поверх SQL-таблиц.
Что дальше: куда мы движемся
В планах — заменить GPT-4.5 на open-source модель (Llama 4 70B уже close), внедрить HippoRAG 2 для долгосрочной памяти агента, и добавить GraphRAG для связей между объектами 1С. Но это уже тема следующей статьи. Если вы строите что-то подобное — начните с метрик, не с архитектуры. И никогда не доверяйте прототипу, который запускали только на датасете из документации. Проверяйте на реальных диалогах. Иначе — грабли, как у нас.
💡 Совет: Полный код инструментов и конфигураций агента доступен по запросу в телеграм-канале. А пока посмотрите обзор Agentic RAG System — там готовый код оценки.
