Telegram-бот по своей базе знаний: когда RAG не нужен

Если вы не программист и хотите Telegram-бота, который отвечает по вашей базе знаний, начните с честного вопроса: а нужен ли вам вообще RAG? RAG (произносится «рэг», по-простому это когда бот ищет ответы в большой библиотеке текстов через векторный поиск) звучит модно, но для маленькой базы он часто оверкилл. Я свой бот-навигатор по материалам клуба собрала без всякого RAG: весь список материалов весит около 6 тысяч токенов (это примерно 30 страниц текста), и я просто отдаю его модели целиком в системном промпте. Работает, обходится примерно в 8 долларов в месяц, а за счёт кэша каждый следующий запрос в течение пяти минут дешевле обычного в 10 раз. Ниже разберу, когда RAG правда не нужен, покажу три своих живых сборки (бот-навигатор, виртуальный двойник эксперта и разбор путей к личной базе), и честно расскажу, на каких граблях я поскользнулась. Программистом для этого быть не обязательно, но повозиться придётся.

Что такое RAG и почему нетехнари его боятся зря

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

Звучит серьёзно, и нетехнарь сразу решает, что без RAG за такую задачу и браться нечего. А зря. Вся эта машинерия нужна только тогда, когда данных реально много: сотни документов, тысячи страниц, целые архивы. Если ваша база помещается в несколько десятков страниц, вы можете отдать её модели целиком, и никакой векторный поиск вам не понадобится.

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

Когда RAG действительно не нужен: правило про размер базы

Дам конкретную развилку, по которой я решаю сама. Она грубая, но рабочая.

Если ваша база это список материалов, оглавление, набор ссылок с описаниями, короткий свод правил, договорённостей, часто задаваемых вопросов, то есть всё, что укладывается в несколько десятков страниц текста, вы почти наверняка обойдётесь без RAG. Мой бот-навигатор ровно про это: список материалов на 6 тысяч токенов, и он целиком лежит в системном промпте бота.

Если же у вас сотни PDF, многолетние архивы переписок, база на тысячи документов, куда постоянно добавляется новое, тогда да, целиком это в модель не влезет и RAG становится оправдан. Но давайте честно: у скольких нетехнарей на старте такие объёмы? У большинства база это «пара десятков полезных материалов, в которых люди путаются». А для такого RAG, как я это называю, оверкилл.

Есть ещё третий, самый интересный вариант, когда вам не нужен ни RAG, ни целый список, а нужен метод. О нём отдельно во втором кейсе, потому что там подход совсем другой.

Кейс: бот-навигатор по клубу, где RAG не понадобился

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

Собирала так. Сначала ТЗ. Я его составила в Claude со скиллом explore (скилл это как заранее прописанная инструкция, по которой ИИ работает). Дальше вайбкодинг: код бота написал Claude Code, это когда вы объясняете задачу словами, а среда пишет код за вас. Заняло у него минут пять-десять, я не преувеличиваю.

Теперь главное, ради чего всё затевалось. Список материалов весит около 6 тысяч токенов, это где-то 30 страниц текста. Я отдаю его модели целиком в системном промпте. Никаких сложных RAG-баз с векторным поиском тут не нужно, для моего объёма это оверкилл. Работает бот на Claude Sonnet 4.6.

Отдельно про деньги, потому что тут кроется приятный трюк. Кэш системного промпта в Claude живёт 5 минут. Пока это окно открыто, каждый следующий запрос обходится в 10 раз дешевле обычного. То есть модель не перечитывает мои 30 страниц заново на каждый вопрос, а помнит их и берёт с полки. В итоге весь бот стоит мне примерно 8 долларов в месяц за API Claude плюс минимальный тариф Railway (это сервис, где бот крутится, чтобы работать без моего компьютера).

Пара технических деталей, которые пригодятся

Чтобы не осталось белых пятен, ещё несколько моментов из этой сборки.

• Проверка членства без таблиц. Бот проверяет, участник вы клуба или нет, через официальный метод Telegram API getChatMember. Для этого бот добавлен админом канала, и никакие базы со списками участников вести не надо, Telegram сам всё знает.
• Память бота короткая. Он держит последние 4 пары сообщений в памяти процесса. Для навигатора этого хватает, длинных диалогов тут и не бывает.
• Индикатор «печатает». Ответ приходит за 5–7 секунд, а это ощутимая пауза. Чтобы человек не думал, что бот завис, я добавила typing-индикатор через sendChatAction раз в 4 секунды. Мелочь, а живости добавляет.
• Деплой. Код лежит в приватном репозитории GitHub, а разворачивается на Railway. Как выложить агента на Railway, я разбирала отдельно, ссылку дам в конце.

Две грабли, на которых я поскользнулась

Без граблей не обошлось, и я про них честно, чтобы вы не наступили.

Первая: после деплоя обязательно остановите локального бота на своём компьютере. Если этого не сделать, два процесса начнут конкурировать за один токен Telegram, и каждое второе сообщение будет теряться. Выглядит это как «бот через раз глючит», а на деле их просто два, и они дерутся.

Вторая тоньше. Кэш проверки членства живёт 10 минут. Из-за этого только что добавленный участник ещё 10 минут получает ответ «вы не участник клуба», хотя он уже вошёл. Не баг, а особенность кэша, но человека это путает, так что про неё стоит помнить.

Кейс: виртуальный двойник эксперта, где вместо RAG нужен скилл

А теперь тот самый третий вариант, который я обещала. Иногда вам не нужен ни RAG, ни целый список материалов. Вам нужен метод, по которому мыслит эксперт. И это совсем другая история.

Я проверяла идею Anthropic: сделать из книги скилл для агента. Книги под рукой не было, поэтому я взяла открытый бесплатный Telegram-канал эксперта по 115-ФЗ (это закон про отмывание денег, если что) и решила собрать из него виртуального двойника.

Сделала так. Выгрузила канал через десктопный Telegram в JSON (это формат, в котором данные хранятся понятной для программы структурой). Выгрузка канала за несколько лет заняла пару минут. Claude Code написал мне программку очистки, и из 1910 сообщений осталось 1763 содержательных поста.

Дальше самое важное. Я не сказала ИИ «перепиши этот канал в один файл». Я поставила задачу иначе: «вытащи из этих постов метод и сложи его в структуру». Разница огромная. В первом случае вы получаете свалку текста, во втором конспект того, как человек рассуждает. Готовые рубрики канала при этом сами стали оглавлением справочника, удобно.

Собрала я это как скилл: файл SKILL.MD с методом плюс десяток справочников по темам, которые подгружаются по требованию. На тестовой ситуации агент разложил кашу ровно по методу: разделил запутанный случай на три отдельных сюжета и сам приписал, что это не заменяет живого юриста. Вот это «сам приписал» меня и порадовало, метод сработал.

Почему тут скилл, а не RAG: главная мысль

Объясню разницу так, как поняла её сама. RAG ищет похожие слова, а не понимает метод. Он найдёт вам куски текста, где встречаются нужные слова, и на этом всё. А скилл вытаскивает сам способ рассуждения.

Моя любимая формулировка: RAG — это библиотека, а скилл — это конспект. Библиотека большая и в ней всё есть, но она не думает за вас. Конспект маленький, зато в нём выжата суть и логика. Для «двойника эксперта» вам нужен именно конспект, а не полка с книгами.

Пара оговорок из моего опыта. У Claude в браузере есть лимит на длину описания навыка, и мой скилл под него не влез. В Claude Code такого ограничения нет, там я всё и собрала. И отдельно про этику, это важно. Посты эксперта это его авторский труд, и право на них остаётся за ним. Такой скилл я не выкладываю как готовый продукт и не продаю. Сделала для проверки идеи, на том и стоит.

А если у вас реально гора файлов: пять путей к базе знаний

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

Первый — память самой платформы. Тот же ChatGPT или Claude что-то помнят о вас между разговорами. Самый простой вариант, но и самый ненадёжный, для серьёзной базы не годится. Второй — готовые сервисы вроде Notion, где вы складываете всё вручную в аккуратную структуру. Третий — ИИ поверх ваших файлов (Cursor, Claude Cowork), это моя золотая середина: файлы лежат у вас, а ИИ читает их и отвечает по ним. Четвёртый — автономный агент вроде Claude Code или Codex, который сам роется в ваших папках. Пятый, для самых чувствительных данных, — свой сервер с локальной моделью, когда наружу не уходит вообще ничего.

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

Два правила, которые сэкономят вам нервы

Из этого разбора вынесите хотя бы два правила, я их усвоила на своей шкуре.

Первое про формат. Инструменты и интерфейсы постоянно меняются, а вечны (и то относительно) только ваши документы. Поэтому файлы лучше переводить в Markdown (это простой текстовый формат, который читается чем угодно и переживёт любой модный сервис). Сегодня вы в Notion, завтра в чём-то ещё, а Markdown-файлы останутся с вами.

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

Что выбрать под свою задачу: короткая шпаргалка

Сведу всё вместе, чтобы вы могли примерить на себя.

Если у вас список материалов, свод правил, набор ссылок или FAQ на несколько десятков страниц, вам хватит подхода из первого кейса: отдать всё модели целиком в системном промпте, RAG не трогать. Если вам нужно, чтобы бот думал как конкретный эксперт по вашим текстам, стройте скилл, как во втором кейсе: вытаскиваете метод, а не пересыпаете текст из кармана в карман. И только если у вас правда сотни документов и постоянно растущий архив, вот тогда есть смысл разбираться с RAG и векторным поиском. До этого объёма он вам, скорее всего, ни к чему.

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

С чего начать прямо сейчас

Не откладывайте в режим «как-нибудь потом разберусь». Давайте конкретный шаг на эту неделю.

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

Подписывайтесь на канал, если хотите больше таких разборов: t.me/gruboprostiite

FAQ

Что такое RAG простыми словами?

RAG это способ отвечать по большой базе текстов, когда целиком она в модель не влезает. Бот сначала находит в этой базе куски, похожие на ваш вопрос (тот самый векторный поиск, «найди похожее по смыслу»), и подсовывает их ИИ для ответа. Нужно это только при больших объёмах. Для базы на несколько десятков страниц RAG чаще всего оверкилл, проще отдать всё модели целиком.

Когда для Telegram-бота по базе знаний RAG не нужен?

Когда база небольшая и укладывается в несколько десятков страниц: список материалов, оглавление, свод правил, набор ссылок, FAQ. Мой бот-навигатор по клубу держит список на 6 тысяч токенов (около 30 страниц) целиком в системном промпте, и никакого RAG с векторным поиском там нет. Для такого объёма он лишний.

Сколько стоит такой бот в месяц?

Мой бот-навигатор обходится примерно в 8 долларов в месяц за API Claude плюс минимальный тариф Railway (сервис, где бот крутится без моего компьютера). Помогает кэш системного промпта: он живёт 5 минут, и в этом окне каждый следующий запрос стоит в 10 раз дешевле обычного, потому что модель не перечитывает базу заново на каждый вопрос.

Чем скилл отличается от RAG?

RAG ищет похожие слова, а не понимает метод. Скилл вытаскивает сам способ рассуждения эксперта. Моя формулировка: RAG — это библиотека, а скилл — это конспект. Библиотека большая, но не думает за вас; конспект маленький, зато в нём выжата суть. Для «двойника эксперта» нужен именно скилл: я собрала его из постов канала, вытащив метод, а не переписав текст целиком.

Какие грабли ждут при запуске такого бота?

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

Что делать, если файлов реально много?

Сначала навести порядок по пяти шагам: аудит, группировка, обогащение, перевод форматов, опись. На аудите пометьте архивом всё, к чему не прикасались год, обычно это 60–70 процентов файлов, а база нужна лишь для оставшейся трети. Файлы переводите в Markdown, он переживёт любой модный сервис. И называйте папки латиницей без пробелов, иначе агенты спотыкаются.