AI-помощник по внутренней базе знаний (RAG): бот в Telegram с уровнями доступа

Сбор: слияние по id сообщения

Чаты снимаются лейнами и сливаются по id сообщения. Причина простая: копирование поверх стёрло бы историю при первом же неполном съёме — источник отдаёт только последние N сообщений. Голосовые расшифровываются через whisper, скриншоты — через OCR, пересланные документы попадают в индекс как отдельные источники. На выходе всё — текст, у каждого чанка есть ссылка обратно.

Правка отправленного сообщения обновляет запись, а прежняя версия складывается в историю правок. Раньше дедупликация по идентификатору выбрасывала правку целиком: ответ сотрудницы пролежал в чате 15 часов, и по обрезанной версии был сделан противоположный вывод.

Приём материалов: что доезжает до базы

Картинки, присланные документом, уходят в OCR. PDF без текстового слоя разбирается постранично через растеризацию — с пределом в 20 страниц и честной пометкой прямо в тексте. Архивы разворачиваются рекурсивно тем же извлекателем, границы — 60 файлов и 40 МБ. Презентации поддержаны. Звуковая дорожка видео уходит в тот же распознаватель речи, что и голосовые: второй собственный вызов завёл бы вторую правду о том, чем мы распознаём речь.

Цифры первого прогона: 98 залипших вложений возвращены в очередь, 45 извлечено сразу, 76 вложений вне рабочих чатов сознательно не тронуты. Из одного архива извлечено 573 572 символа, таких архивов в очереди стояло 14. Два PDF на 9,7 и 16,3 МБ давали ровно 0 символов до постраничного OCR. Перебор вложений знал только документы и фотографии, поэтому мимо обработчика прошли 27 видео-сообщений, 15 из них — в личном чате владельца. Из живого ролика извлечено 2201 символ разбора товара.

Честные статусы: видно, что не доехало

Три из четырёх потерянных вложений стояли со статусом «готово»: выглядели доставленными и не попадали ни в один список проблем. Теперь статус называет причину — нет текста, PDF без OCR, видео, неподдерживаемый формат, превышен предел размера. Сводка печатает список того, что не доехало, а прогон завершается предупреждением.

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

Метки «пусто» перепроверены на живых файлах

Ни одна из трёх меток не подтвердилась: 12 «сбоев скачивания» упирались в предел размера, 6 «видео без звука» имели звук, 20 «нет текста» скрывали разные истории. Отдельная находка — проверка на ведущую скобку выбрасывала распознанный текст целиком: таблица распозналась на 771 символ и ушла в «нет текста», потому что OCR срезал первую букву.

Уровни доступа задаются в одном месте

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

Поэтому обе стороны ходят в одну функцию is_private_source, а на дрейф между ними стоит гард-тест: если кто-то заведёт вторую копию логики приватности, падает CI.

Тот же принцип держит гард «скриншот с паролем не индексируем». Он переведён с того, как файл положил мессенджер, на тип извлечения — и правился в том же коммите, что и приём материалов: между двумя отдельными правками существовало бы окно, в котором скриншоты с ключами индексировались.

Поиск: BM25 в памяти → SQLite FTS5

Первая версия держала весь индекс в памяти процесса. Работало, пока бот жил на ноутбуке. Переписал хранение на SQLite FTS5, но с нюансом: FTS5 используется только как хранилище индекса (через fts5vocab), а ранжирование остаётся своим.

Причина конкретная: встроенная bm25() в FTS5 отдаёт по документу одно число и скрывает вклад каждого слова. Этот вклад и нужен, чтобы отличить покрытие слов запроса от веса, набранного на одном частом слове. Отдать ранжирование движку значило бы ухудшить выдачу.

Миграция сделана без риска: движок переключается одной переменной окружения, старый и новый прогоняются на одних запросах, выдача сверена ранг-в-ранг. Отличий нет — изменилась только цена.

Ответ приходит целиком

Пустой ответ рассуждающей модели лечится одним повтором с бюджетом 8000 токенов. Замер на боевом промпте в 6466 символов показал, что само рассуждение берёт 400–700 токенов, и худший ответ выдавался ровно на сложных вопросах при полностью исправной основной модели.

Что надстроено сверху базы

База знаний оказалась платформой. Поверх неё живут:

• Дистилляция фактов — переписка сворачивается в структурированные факты
• Утренние сводки и доски в Telegram-хабе: бизнес-пульс, пульс кампаний, инфра-пульс, дайджест трекера
• Около двух десятков сторожей по принципу «упало — напиши в личку и в Discord»: живость CRM, зависшие заказы, срок на оспаривание платежа, важное сообщение владельца, устаревание индекса
• MCP-сервер над базой — личные модели владельца видят ту же базу знаний, без второй такой же системы

С ноутбука уехал весь контур сбора

Падение памяти в 20 раз дало практический результат. Именно оно позволило унести бота с ноутбука подрядчика на сервер, где всего 961 МБ RAM. Хроническая болезнь «ноутбук уснул — бот молчит ночью» закрыта в корне: бот отвечает круглосуточно.

Следом уехала почта. Выкачка почтового корпуса по IMAP на ноутбуке выключена, готовый разобранный корпус забирается с сервера. Ноутбук качал 34 ГБ сырых писем ради 459 МБ разобранных; тот же корпус сервер собирает сам с конца июля, весит он 450 МБ и полнее. Диск ноутбука был занят на 98 процентов — 12 свободных гигабайт из 460.

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

Историю страхует отдельный гард: файл заменяется, только если он не короче локального. На первом же боевом прогоне гард отклонил второй ящик (8022 → 7985) и предотвратил тихое стирание 34 писем.

Попутно с ноутбука убрана сборка индекса на 103 МБ: он пересобирался 96 раз в сутки и не читался ни одним потребителем — время последнего чтения обоих его файлов совпадало с моментом записи.

Сторожа живут на сервере

Около двух десятков сторожевых процессов работают на сервере под systemd-таймерами. Launchd-агенты на ноутбуке выгружены и переименованы в отключённые, команда отката записана в журнал инфраструктуры.

Показательная починка оттуда же: сторож свежести данных мессенджера шесть часов писал «обновлялся 0 минут назад» при мёртвом сборщике. Разбор вывода утилиты состояния файла отдавал мусор, а мусор считался нулевым возрастом. Теперь варианты разбора пробуются по порядку, и результат проверяется на «это вообще число».

Приватность: замерили на живом индексе

Права доступа можно долго обсуждать на словах. Поэтому сделан замер на живом индексе: сколько приватных фрагментов реально видит уровень «команда». Ответ был неприятный — 1327.

После правки прав доступный этому уровню объём сжался с 6139 до 4560 фрагментов, приватных среди них — 0, при этом рабочих данных не потеряно. Отдельно поднят лог обращений: проверка подтвердила, что реального доступа к этим фрагментам никто не успел получить.

Что изменилось в работе

Вопрос «что мы решили по этому» теперь задаётся боту и возвращается ответом с цитатами на конкретные сообщения — включая те, что были голосовыми. Утренние сводки приходят сами, сторожа пишут раньше, чем проблему заметит клиент, а личные модели владельца через MCP работают с той же базой — без второй такой же системы и второй копии данных.