Реквизиты, которые бот путал в RAG

Первый блин: столкнулся с логистическим ботом, который принимает заказы через Telegram и сохраняет их в таблицы. На одном из полей - банковские реквизиты: номер счета, корреспондентский счет, БИК. Агент должен был их тянуть из базы знаний и подставлять в платеж.

Но на деле один и тот же номер в разных контекстах становился разным. Корреспондентский счет 044525974 один раз появился как 044525974, в другой раз как 044525979, в третий раз как 425974. Бот путался. Семантический поиск (RAG) в данном случае не помогал: для модели числа - это просто токены в контексте, она не видит в них структуру и значение. Добавил в индекс подробное описание каждого реквизита на русском вместо голых цифр? Мимо, модель все равно ловит паттерн похожести, а не точное совпадение.

Что сделал: убрал реквизиты из RAG совсем. Положил их в отдельный детерминированный справочник, жестко привязанный к типу платежа и партнеру. Когда агенту нужно вставить реквизит, он не ищет в базе знаний, а дергает lookup-таблицу. LLM говорит только «тип платежа = экспорт, партнер = X», а все остальное - прямой код без модели. No hallucinations, no confusion.

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

#n8n #логистика #RAG #автоматизация #LLM #Telegram #интеграция #детерминизм