Skip to content
BranchesTags

Repository files navigation

Описание проекта

Telegram‑бот‑помощник с поддержкой RAG (Retrieval Augmented Generation):

  • Накопление знаний через загрузку файлов разных типов (текст, Markdown, PDF, Word, Excel, изображения, а также ZIP‑архивы с такими файлами).
  • Web‑scraper: загрузка и разбор веб‑страниц, сохранение содержимого в базу знаний.
  • Рекурсивный wiki‑scraper: обход wiki‑раздела сайта (например, Gitee Wiki) с пересборкой соответствующей части базы знаний.
  • Векторная база знаний (FAISS + эмбеддинги sentence-transformers) с хранением фрагментов в SQL‑БД.
    • Reranker для улучшения релевантности поиска (top-100 → rerank → top-k)
    • Настраиваемый чанкинг с overlap (по умолчанию 2000/400 символов)
    • Inline citations [source_id] в ответах ИИ
  • KB-настройки: режимы чанкинга и RAG-поведение хранятся в БД по каждой базе знаний, управляются через админ-панель и API.
  • Индексация кода: загрузка локальной кодовой базы (в контейнере) или из git; 1 файл = 1 чанк, инкрементальное обновление по хешу.
  • Ответы пользователям формируются моделью ИИ с учётом контекста из базы знаний, с явным указанием источников (название документа или страницы, язык, версия, дата обновления, путь/URL).
  • Поддержка провайдеров ИИ: Ollama, OpenAI, Anthropic, DeepSeek, Open WebUI API (через OpenAI-compatible endpoint) с возможностью отдельно выбирать модели для текста и изображений.
  • Интеграция с n8n: бот отправляет события о загрузке/сканировании документов в n8n через вебхуки, есть отдельное админ‑меню для проверки подключения и тестовых запусков.
  • Готовая контейнеризация: бот, БД и Redis запускаются через Docker / docker‑compose, при этом данные и настройки хранятся вне контейнеров.

Engineering Governance

  • Для любого изменения функциональности/поведения/конфигурации (включая bugfix) обновляются:
    • SPEC.md
    • релевантный docs/design/<feature>-vN.md
    • docs/REQUIREMENTS_TRACEABILITY.md
  • Секреты (токены/ключи/пароли) не должны попадать в git; перед завершением задачи запускается:
    • python scripts/scan_secrets.py
  • Политики агентов:
    • глобовый baseline: C:\Users\devl\.codex\AGENTS.md
    • проектные дополнения: AGENTS.md

Архитектура

Микросервисы: Telegram‑бот + Backend API

  • Telegram‑бот (frontend)

    • файлы: bot.py, bot_handlers.py, bot_callbacks.py, templates/buttons.py;
    • отвечает только за приём апдейтов, управление состояниями диалога, отображение меню и форматирование HTML‑ответов;
    • не имеет прямого доступа к БД и rag_system – вся бизнес‑логика вынесена в backend и вызывается через HTTP‑клиент backend_client (httpx, API‑ключ в заголовке X-API-Key).

  • Backend‑сервис (FastAPI, директория backend/)

    • реализует REST‑API для:
      • аутентификации пользователей (/auth/telegram) и управления пользователями (/users/*);
      • работы с базами знаний (/knowledge-bases/*);
      • ingestion документов/архивов/вики/веб‑страниц/изображений (/ingestion/*);
      • RAG‑поиска и управления моделями (/rag/query, /rag/reload-models);
    • использует общие модули rag_system.py, document_loaders.py, image_processor.py, database.py как внутреннее RAG‑ядро и слой доступа к данным.

Основные модули

  • bot.py – точка входа Telegram‑бота, регистрация хендлеров и глобального обработчика ошибок.
  • bot_handlers.py – обработчики команд и сообщений:
    • работа с состояниями диалога,
    • запросы к RAG (через backend_client.rag_query(...)) и формирование ответов с подробным указанием источников,
    • загрузка документов, ZIP‑архивов и изображений в базу знаний (через /ingestion/document и /ingestion/image),
    • web‑scraper (загрузка страниц по URL через /ingestion/web),
    • запуск рекурсивного wiki‑сканирования (/ingestion/wiki-crawl, /ingestion/wiki-git, /ingestion/wiki-zip).
  • bot_callbacks.py – обработка callback‑кнопок, админ‑панель, выбор базы знаний, типов загрузки, просмотр журнала загрузок, выбор провайдеров и моделей ИИ; для пользователей, БЗ, источников и журнала использует backend‑эндпоинты (/users/*, /knowledge-bases/*).
  • rag_system.py – RAG‑ядро (используется backend‑сервисом, а не напрямую ботом):
    • модели KnowledgeBase и KnowledgeChunk (через SQLAlchemy),
    • создание и управление базами знаний,
    • добавление фрагментов (add_chunk) с эмбеддингами и указанием источника (source_type, source_path) и метаданных,
    • точечное удаление фрагментов по источнику (обновление версий документов),
    • векторный поиск (FAISS) с reranker'ом для улучшения релевантности (top-N кандидатов → rerank → top-k),
    • резервный поиск по ключевым словам при отсутствии эмбеддингов.
  • kb_settings.py - дефолты и нормализация настроек баз знаний (чанкинг, single-page mode, UI подсказки).
  • document_loaders.py – загрузчики документов:
    • MarkdownLoader, PDFLoader, WordLoader, ExcelLoader, TextLoader, WebLoader, ImageLoader,
    • менеджер DocumentLoaderManager автоматически выбирает нужный загрузчик по расширению или URL,
    • универсальный чанкер с настраиваемым размером и overlap (по умолчанию из конфига).
  • database.py – описание схемы БД и создание подключения:
    • таблицы users, messages, knowledge_bases, knowledge_chunks, knowledge_import_logs (журнал загрузок),
    • поддержка MySQL и SQLite (по переменным окружения MYSQL_URL / DB_PATH),
    • автоматические миграции структуры.
  • ai_providers.py – абстракция провайдеров ИИ:
    • OllamaProvider (локальные модели через Ollama),
    • OpenAIProvider, AnthropicProvider, DeepSeekProvider, OpenWebUIProvider (при наличии соответствующих env-настроек),
    • менеджер ai_manager для выбора провайдера и моделей,
    • возможность отдельно выбирать модель для текстовых запросов и модель для изображений.
  • image_processor.py – обработка изображений:
    • мультимодальные запросы к ИИ,
    • использование выбранной пользователем модели Ollama для изображений,
    • OCR (pytesseract) и объединение описания/текста для загрузки в RAG.
  • web_search.py – поиск в интернете через DuckDuckGo (для общего веб‑поиска, не для RAG).
  • templates/buttons.py – создание клавиатур:
    • основное меню пользователя – reply‑клавиатура внизу экрана,
    • inline‑клавиатуры для админ‑меню, выбора БЗ, типов документов, журнала загрузок, настроек ИИ и т.д.
  • cache.py – кэширование истории в Redis.
  • logging_config.py – единая конфигурация логирования (консоль + файлы логов).
  • error_handlers.py – глобальный обработчик ошибок Telegram с уведомлением администраторов.
  • n8n_client.py – HTTP‑клиент для сервиса n8n (health‑check, отправка событий о загрузке знаний, запуск workflow по API).

RAG‑путь данных (с учётом backend):

  1. Администратор в Telegram‑боте выбирает/создаёт базу знаний в админ‑меню (бот вызывает /knowledge-bases/*).
  2. Админ загружает файл / изображение или вводит URL страницы; бот отправляет файл/URL на backend (/ingestion/*).
  3. В backend document_loaders / image_processor разбивают документ на фрагменты.
  4. rag_system.add_chunk (внутри backend) сохраняет каждый фрагмент в knowledge_chunks с:
    • content – текст фрагмента,
    • chunk_metadata – JSON‑метаданные (тип документа, страница, лист и т.п., язык, версия, хэш, время обновления и др.),
    • source_type – markdown, pdf, word, excel, web, image и т.д.,
    • source_path – путь к файлу или URL.
  5. При включённых эмбеддингах формируется вектор и добавляется в FAISS‑индекс.
  6. При запросе пользователя бот обращается к /rag/query, получает RAG‑ответ и список источников и формирует итоговый HTML‑ответ пользователю.

MCP (Model Context Protocol): текущая реализация использует локальный FAISS‑индекс и SQL‑хранилище. Подключение внешнего MCP‑совместимого хранилища возможно через замену/расширение rag_system.py, сохраняя интерфейс add_chunk / search.

Принципы работы

  • Разделение ролей:
    • пользователи могут искать по базе знаний, задавать вопросы ИИ, делать поиск в интернете, отправлять изображения;
    • администраторы управляют пользователями, базами знаний, загрузкой документов и настройками ИИ.
  • RAG‑поиск:
    • при запросе "по базе знаний" сначала выполняется векторный поиск (FAISS) с получением большого пула кандидатов,
    • затем применяется reranker для улучшения релевантности и отбора top-k результатов,
    • найденные фрагменты передаются в модель ИИ как контекст с тегами <source_id> для inline citations,
    • бот в ответе дополнительно выводит список источников: название документа/страницы, тип, язык, версия, дата обновления и путь/URL,
    • при включенных citations (RAG_ENABLE_CITATIONS=true) модель может использовать inline citations в формате [source_id] в ответе.
  • Web‑scraper:
    • через админ‑меню выбирается база знаний → тип загрузки web → вводится URL;
    • WebLoader скачивает страницу, очищает HTML (BeautifulSoup), конвертирует в текст (html2text),
    • текст разбивается на абзацы и сохраняется в RAG с source_type='web' и source_path=URL.
  • Wiki‑scraper:
    • через админ‑меню для выбранной БЗ можно указать корневой URL вики,
    • скрепер проходит по всем страницам внутри wiki‑раздела, удаляет старые фрагменты этой вики и загружает актуальные,
    • результаты (количество страниц, фрагментов, удалённых старых данных) отображаются администратору и записываются в журнал загрузок.
  • Хранение данных:
    • пользователи, сообщения и база знаний хранятся в SQL‑БД (MySQL или SQLite),
    • векторные представления хранятся в той же БД (строкой JSON) и загружаются в FAISS‑индекс в памяти при работе,
    • кэширование истории реализовано через Redis.
  • Настройки:
    • все настройки берутся из .env файла через модуль config.py (см. ниже),
    • настройки по умолчанию лежат в образе, но пользователь может полностью переопределить их через собственный .env вне контейнера,
    • RAG параметры (chunk size, overlap, top_k, context length, reranker) настраиваются через переменные окружения и имеют разумные значения по умолчанию (из Open WebUI).
  • Логирование и ошибки:
    • все основные операции (загрузки, сканирование вики, поиск) логируются в консоль и в файл в директории data/logs (по умолчанию data/logs/bot.log),
    • при неожиданных ошибках Telegram‑хэндлеров глобальный обработчик отправляет краткое уведомление всем администраторам (ADMIN_IDS).

Настройка (локальный запуск без Docker)

Подробные инструкции по настройке см. в документации.

  • 1. Клонировать проект
git clone <repo-url>
cd telegram_bot_ai
  • 2. Установить зависимости
pip install -r requirements.txt
  • 3. Создать и заполнить .env (используйте готовый шаблон env.template)

Подробнее о конфигурации см. docs/CONFIGURATION.md

# Linux / macOS
cp env.template .env

# Windows PowerShell
Copy-Item env.template .env

После этого отредактируйте .env, указав свои токены и параметры. Минимальный пример:

TELEGRAM_BOT_TOKEN=ваш_токен_бота

# Вариант 1: MySQL
MYSQL_URL=mysql+mysqlconnector://telegram:пароль@localhost/telegram_chatbot

# Вариант 2: SQLite (локальный файл)
# DB_PATH=bot_database.db

OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=deepseek-r1:1.5b

ADMIN_IDS=123456789  # через запятую для нескольких админов

REDIS_HOST=localhost
REDIS_PORT=6379

# RAG Configuration (опционально)
# RAG_MODEL_NAME=sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2
# RAG_ENABLE=true
# RAG_MAX_CANDIDATES=100  # Количество кандидатов для векторного поиска перед rerank
# RAG_RERANK_MODEL=cross-encoder/ms-marco-MiniLM-L-6-v2  # Модель reranker'а для улучшения релевантности
# 
# # Настройки чанкинга и поиска (по умолчанию из Open WebUI)
# RAG_CHUNK_SIZE=2000  # Размер чанка в символах (~300-800 токенов)
# RAG_CHUNK_OVERLAP=400  # Перекрытие между чанками в символах
# RAG_TOP_K=10  # Количество лучших результатов для контекста
# RAG_CONTEXT_LENGTH=1200  # Максимальная длина контекста на источник в символах
# RAG_ENABLE_CITATIONS=true  # Включить inline citations [source_id] в ответах ИИ

# Hugging Face (опционально, для gated/private моделей и лимитов API)
# HF_TOKEN=hf_xxx

# Интеграция с n8n (опционально — уже настроено по умолчанию)
# N8N_BASE_URL=http://n8n:5678          # можно переопределить внешний адрес
# N8N_DEFAULT_WEBHOOK=bot-events       # предустановленный путь вебхука
# N8N_PUBLIC_URL=http://localhost:5678 # URL для кнопки "Открыть n8n"
# N8N_API_KEY=<если требуется запуск workflow по API>

# Outbound proxy (optional)
# HTTP_PROXY=http://proxy.example:8080
# HTTPS_PROXY=http://proxy.example:8443
# ALL_PROXY=socks5://proxy.example:1080
# NO_PROXY=backend,qdrant,redis,db,n8n,localhost,127.0.0.1

Если контейнеры должны работать через прокси/VPN, используйте стандартные переменные окружения HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY. Для внутреннего трафика Docker обязательно укажите NO_PROXY как минимум для backend,qdrant,redis,db,n8n,localhost,127.0.0.1.

  • 4. Запустить внешние сервисы (если используются)

    • MySQL (создать БД telegram_chatbot, пользователя и задать MYSQL_URL).

  • Redis.

  • 5. Запустить бота

python -m frontend.bot

Запуск в Docker

Подготовка

  • Установить Docker и docker‑compose.
  • Скопировать env.template → .env (как описано выше) и заполнить нужными значениями. Этот файл не входит в образ и полностью управляется пользователем.

Использование GPU (опционально)

Для использования GPU в Docker контейнерах необходимо:

  1. Установить nvidia-container-toolkit (требуется для доступа к GPU из контейнеров):

    # Ubuntu/Debian
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

  2. Раскомментировать секцию GPU в docker-compose.yml (в сервисе bot):

    deploy:
  resources:
    reservations:
      devices:
        - driver: nvidia
          count: all
          capabilities: [gpu]

  3. Установить RAG_DEVICE=cuda в .env файле:

    RAG_DEVICE=cuda  # или cuda:0 для конкретного GPU

  4. Пересобрать и перезапустить контейнеры:

    docker-compose up -d --build

Диагностика проблем с GPU:

Если вы видите предупреждение ⚠️ CUDA запрошена (cuda), но недоступна, проверьте:

  1. Доступность GPU в контейнере:

    docker exec telegram_rag_bot nvidia-smi

    Если команда не работает, GPU недоступен в контейнере - проверьте, что:

    • Установлен nvidia-container-toolkit
    • Секция deploy раскомментирована в docker-compose.yml
    • Docker перезапущен после установки toolkit

  2. Версия PyTorch с поддержкой CUDA:

    docker exec telegram_rag_bot python -c "import torch; print(f'PyTorch: {torch.__version__}, CUDA available: {torch.cuda.is_available()}')"

    Если CUDA available: False, возможно установлена CPU-версия PyTorch. В этом случае:

    • Пересоберите образ с явной установкой PyTorch с CUDA (см. ниже)
    • Или проверьте логи при запуске - бот покажет детальную диагностику

  3. Принудительная установка PyTorch с CUDA: Если sentence-transformers установил CPU-версию PyTorch, добавьте в Dockerfile перед установкой зависимостей:

    # Установить PyTorch с поддержкой CUDA (замените cu118 на вашу версию CUDA)
RUN pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118

Примечание: PyTorch с поддержкой CUDA обычно устанавливается автоматически через sentence-transformers. Если GPU недоступен, бот автоматически переключится на CPU с детальным предупреждением в логах, включающим диагностику проблемы.

Запуск

docker-compose up -d --build

Рекомендуемый запуск с авто-выбором DB режима:

python scripts/start_stack.py
.\scripts\start_stack.ps1
./scripts/start_stack.sh
  • При заданном MYSQL_URL launcher включает compose-profile mysql и поднимает db.
  • Если MYSQL_URL не задан, MySQL контейнер не запускается (SQLite режим).

Будут подняты сервисы:

  • bot – контейнер с Telegram‑ботом и RAG.
  • db – MySQL с данными в томе db_data (на хостовой машине).
  • redis – Redis с персистентным хранилищем в томе redis_data.
  • n8n – визуальный оркестратор (автоматизация сценариев). События от бота отправляются в n8n по вебхуку, UI доступен на http://localhost:5678 (по умолчанию).

Все пользовательские настройки берутся из внешнего файла .env, а данные БД хранятся в внешних Docker‑томах, что позволяет:

  • обновлять образ бота без потери данных;
  • перенастраивать окружение, не меняя код и не пересобирая образ.

Инструкция для пользователя

  • 1. Старт

    • Найдите бота в Telegram и отправьте команду /start.
    • Если вы не администратор, ваша регистрация отправится на одобрение.

  • 2. Поиск по базе знаний

    • После одобрения выберите в главном меню пункт поиска по базе знаний или просто введите текстовый вопрос без команды.
    • Бот выполнит RAG‑поиск по загруженным документам и ответит, указав использованные источники с названием документа/страницы, версией, языком и датой обновления.

  • 3. Поиск в интернете

    • Выберите пункт «поиск в интернете», введите запрос.
    • Бот выполнит поиск через DuckDuckGo, кратко обработает результаты моделью ИИ и добавит список ссылок‑источников.

  • 4. Вопрос напрямую ИИ

    • Пункт «задать вопрос ИИ» – прямое общение с моделью без базы знаний.
    • При повторном входе бот предложит: восстановить предыдущий контекст или начать новый диалог.
    • Поддерживаются текст, голосовые и аудиофайлы: для voice/audio бот сначала делает транскрипцию, затем отправляет текст в ИИ.
    • Для медленных запросов бот показывает временный статус ожидания и удаляет его после ответа.
    • Первый ответ делается кратким; для неясного вопроса бот сначала задает уточнение.
    • Пустой ввод в этом режиме блокируется с подсказкой.
    • Слишком длинные ответы ИИ автоматически отправляются частями.

  • 5. Изображения

    • Отправьте изображение.
    • Бот опишет картинку с помощью мультимодальной модели; при загрузке в базу знаний (по указанию админа) описание и распознанный текст будут сохранены как фрагменты знаний.

Инструкция для администратора

  • Регистрация и роли

    • Ваш Telegram ID должен быть указан в переменной ADMIN_IDS.
    • Админ автоматически одобряется при первом входе.

  • Управление пользователями

    • В админ‑меню доступны:
      • просмотр списка пользователей и их статусов,
      • удаление пользователей,
      • одобрение/отклонение заявок через inline‑кнопки.

  • Управление базами знаний

    • Создание базы знаний: через админ‑меню → раздел «Базы знаний» → «Создать».
    • Просмотр и выбор БЗ: список баз, количество фрагментов, описание.
    • Доступные действия:
      • загрузка документов (выбор типа: файл, web, изображение),
      • очистка БЗ (удаление всех фрагментов),
      • полное удаление БЗ.

  • Загрузка документов и web‑scraper

    • В админ‑меню:
      1. Выберите БЗ.
      2. Выберите «Загрузить документ» и тип:
        • markdown, pdf, word, excel, text – отправьте соответствующий файл,
        • web – введите URL страницы, содержимое будет спарсено и сохранено в RAG,
        • image – отправьте изображение, оно будет описано и загружено в БЗ.

  • Настройки ИИ

    • В разделе настроек можно:
      • выбрать провайдера (Ollama / OpenAI / Anthropic / DeepSeek / Open WebUI),
      • для Ollama – отдельно выбрать модель для текстовых запросов и модель для обработки изображений из списка доступных.

Интеграция с n8n

  • В docker-compose поднят отдельный сервис n8n (порт 5678). UI доступен на http://localhost:5678 (по умолчанию), данные хранятся в data/n8n/.
  • После загрузки любых знаний (файлы, ZIP, web, wiki, изображения) бот отправляет событие knowledge_import в n8n через настроенный вебхук. В payload передаются:
    • ID и имя базы знаний;
    • тип источника (document, wiki, web, image, archive);
    • путь/URL источника, количество добавленных фрагментов, время загрузки;
    • пользователь (telegram_id, username) и дополнительные детали (версия документа, хэш, статистика wiki и т.п.).
  • Настройте переменные окружения:
    • N8N_BASE_URL – URL сервиса (в Docker по умолчанию http://n8n:5678);
    • N8N_DEFAULT_WEBHOOK – путь вебхука внутри n8n (например, bot-events);
    • N8N_PUBLIC_URL – адрес, который отображается в UI и для кнопки «Открыть n8n»;
    • N8N_API_KEY – (опционально) используется для запуска workflow по API.
  • В админ‑панели появилась кнопка «Интеграция n8n»:
    • проверка подключения (/healthz);
    • отправка тестового события с данными администратора;
    • быстрая ссылка на UI n8n.
  • Через n8n можно строить любые цепочки действий: уведомления DevOps, пересборка поисковых индексов, выгрузка статистики по журналу загрузок и т.д.

Настройка RAG параметров

Все параметры RAG настраиваются через переменные окружения в .env файле:

Модели эмбеддингов и reranker

  • RAG_MODEL_NAME (по умолчанию: sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2)

    • Модель для создания векторных представлений текста
    • Рекомендуется для мультиязычных баз знаний
    • Альтернативы: intfloat/multilingual-e5-base или large для лучшего качества

  • RAG_RERANK_MODEL (по умолчанию: cross-encoder/ms-marco-MiniLM-L-6-v2)

    • Модель reranker'а для улучшения релевантности поиска
    • Пересортировывает кандидаты после векторного поиска
    • Если не загрузится, поиск работает без reranker'а (только по расстоянию в FAISS)

  • RAG_DEVICE (по умолчанию: cpu)

    • Устройство для моделей эмбеддингов и ранкинга
    • Возможные значения: cpu, cuda (автоматически выберет первый GPU), cuda:0, cuda:1 и т.д.
    • Для использования GPU в Docker необходимо:
      1. Установить nvidia-container-toolkit (см. раздел "Использование GPU")
      2. Раскомментировать секцию GPU в docker-compose.yml
      3. Установить RAG_DEVICE=cuda в .env
    • Если GPU недоступен, автоматически переключится на CPU с предупреждением в логах

  • RAG_MAX_CANDIDATES (по умолчанию: 100)

    • Количество кандидатов для векторного поиска перед применением reranker'а
    • Больше значение = больше кандидатов для reranker'а, но медленнее поиск
    • Рекомендуется: 50-150 для средних баз, 100-200 для больших баз знаний

Чанкинг документов

  • RAG_CHUNK_SIZE (по умолчанию: 2000)

    • Размер чанка в символах (~300-800 токенов при средней длине токена 3-4 символа)
    • Меньше значение = более точный поиск, но больше фрагментов
    • Больше значение = меньше фрагментов, но может потерять детали
    • Рекомендуется: 1500-2500 символов

  • RAG_CHUNK_OVERLAP (по умолчанию: 400)

    • Перекрытие между соседними чанками в символах
    • Сохраняет контекст на границах фрагментов
    • Обычно 15-25% от RAG_CHUNK_SIZE
    • Рекомендуется: 300-500 символов

Параметры поиска и контекста

  • RAG_TOP_K (по умолчанию: 10)

    • Количество лучших результатов после reranker'а, которые передаются в контекст ИИ
    • Больше значение = больше информации для модели, но длиннее промпт
    • Рекомендуется: 5-15 для большинства случаев

  • RAG_CONTEXT_LENGTH (по умолчанию: 1200)

    • Максимальная длина контекста на источник в символах
    • Ограничивает размер каждого фрагмента в промпте
    • Рекомендуется: 800-1500 символов в зависимости от модели ИИ

  • RAG_ENABLE_CITATIONS (по умолчанию: true)

    • Включить/выключить inline citations [source_id] в ответах ИИ
    • При true: контекст формируется с тегами <source_id>, модель может использовать citations
    • При false: используется старый формат с заголовками источников

Пример настройки для разных сценариев

Для больших баз знаний (тысячи документов):

RAG_MAX_CANDIDATES=150
RAG_TOP_K=15
RAG_CHUNK_SIZE=2500
RAG_CONTEXT_LENGTH=1500

Для точного поиска по технической документации:

RAG_CHUNK_SIZE=1500
RAG_CHUNK_OVERLAP=500
RAG_TOP_K=8
RAG_CONTEXT_LENGTH=1000

Для быстрого поиска (меньше точность):

RAG_MAX_CANDIDATES=50
RAG_TOP_K=5
RAG_CHUNK_SIZE=2500

Примечания

  • Для полноценной работы RAG рекомендуется установить:
    • sentence-transformers,
    • faiss-cpu.
  • Для обработки изображений и OCR:
    • системный пакет tesseract-ocr,
    • Python‑библиотеки Pillow и pytesseract.
  • В Docker‑образ эти зависимости уже включены.

По умолчанию логи пишутся в файл data/logs/bot.log. Путь можно изменить с помощью переменной окружения BOT_LOG_DIR.

About

No description, website, or topics provided.

Resources

Readme
Apache-2.0 license
Activity

Stars

1 star

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages