RAMBA AI Router

RAMBA AI Router

Локальный интеллектуальный маршрутизатор LLM для инфраструктуры RAMBA ART

RAMBA AI Router — собственный локальный маршрутизатор языковых моделей RAMBA ART.

Router принимает запрос пользователя, анализирует его тип и контекст, выбирает подходящую локальную LLM, при необходимости повышает уровень модели, проверяет ответ через Verifier и использует постоянную память между диалогами.

Текущая стабильная версия: v4.7 — Semantic Long-Term Memory

Release:   v4.7
Commit:    11b18b2
Backend:   Ollama
API:       FastAPI / Uvicorn
Storage:   SQLite
Inference: NVIDIA GPU

Назначение проекта

RAMBA AI Router создаётся как центральный интеллектуальный слой локальной AI-инфраструктуры RAMBA ART.

Основная идея проекта:

Пользователь
     │
     ▼
RAMBA AI Router
     │
     ├── анализ запроса
     ├── выбор модели
     ├── история диалога
     ├── долговременная память
     ├── escalation
     └── verification
              │
              ▼
         Local LLM

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

Основные задачи:

• автоматический выбор подходящей LLM;
• минимизация задержки ответа;
• рациональное использование GPU;
• сохранение контекста разговора;
• постоянная память между сессиями;
• автоматическое повышение уровня модели для сложных запросов;
• проверка потенциально ненадёжных ответов;
• создание основы для будущего AI Agent.

Инфраструктура

RAMBA AI Router работает в локальной инфраструктуре RAMBA ART.

Основной AI-хост:

Host: depo
Platform: Proxmox VE
CPU: Xeon E5-2678 v3
GPU: NVIDIA GeForce GTX 1080

Локальные модели обслуживаются через:

Ollama
http://127.0.0.1:11434

Router реализован на:

• Python;
• FastAPI;
• Uvicorn;
• SQLite;
• Ollama API.

Модели

В Router используются несколько специализированных моделей.

Роль	Модель	Назначение
FAST	gemma3:4b	Быстрые повседневные запросы
INFRA	qwen3:8b	Linux, Proxmox, Docker, сети, инфраструктура
SMART	qwen3.5:9b	Более сложный анализ и рассуждение

Общая идея:

                 Request
                    │
                    ▼
              RAMBA Router
                    │
        ┌───────────┼───────────┐
        │           │           │
        ▼           ▼           ▼
      FAST        INFRA       SMART
   Gemma 3 4B   Qwen3 8B   Qwen3.5 9B

Такой подход позволяет не использовать самую тяжёлую модель для каждого простого запроса.

Архитектура

Текущая архитектура RAMBA AI Router v4.7:

                         Пользователь
                              │
                              ▼
                    ┌─────────────────┐
                    │ RAMBA AI Router │
                    │      v4.7       │
                    └────────┬────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
                 ▼                       ▼
          Session Memory          Long-Term Memory
              v4.6                     v4.7
                 │                       │
           messages_json             memory_facts
                 │                       │
                 └───────────┬───────────┘
                             │
                             ▼
                    Context + Routing
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
             FAST           INFRA          SMART
          Gemma 3 4B      Qwen3 8B     Qwen3.5 9B
              │              │              │
              └──────────────┼──────────────┘
                             │
                             ▼
                         Escalation
                             │
                             ▼
                          Verifier
                             │
                             ▼
                      Финальный ответ

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

Обработка одного сообщения в актуальной версии выглядит примерно так:

1. Получение /chat запроса
2. Определение session_id
3. Загрузка Session Memory
4. Поиск Long-Term Memory
5. Анализ запроса
6. Выбор роли модели
7. Выбор FAST / INFRA / SMART
8. Формирование prompt
9. Добавление истории разговора
10. Добавление релевантной долговременной памяти
11. Вызов Ollama
12. Анализ результата
13. При необходимости Escalation
14. При необходимости Verifier
15. Сохранение Session Memory
16. Возврат ответа

История развития

Router v1

Первая версия Router была proof-of-concept.

Основная задача заключалась в том, чтобы доказать сам принцип:

один API может автоматически направлять разные запросы в разные локальные модели.

Маршрутизация в основном основывалась на простых правилах и ключевых словах.

Архитектура:

Request
   │
   ▼
Keyword Rules
   │
   ├── FAST
   ├── INFRA
   └── SMART

Главный результат v1 — подтверждение жизнеспособности идеи локального multi-model Router.

Router v2

Во второй версии была улучшена логика классификации запросов.

Вместо одного простого совпадения ключевых слов Router начал учитывать несколько признаков запроса.

Появилась более стабильная специализация моделей.

Основная проблема всё ещё сохранялась:

• Router практически не понимал контекст;
• follow-up сообщения могли классифицироваться неправильно;
• история разговора не являлась частью маршрутизации.

Router v3

Router v3 стал заметным архитектурным шагом вперёд.

Основным изменением стала score-based routing.

Каждая роль могла получать собственный score.

Пример:

Запрос:
"Как пробросить GPU в Proxmox?"

FAST   = 0
INFRA  = 8
SMART  = 2

Результат:
INFRA

Это позволило отказаться от жёсткой схемы:

нашли одно слово → выбрали модель

в пользу:

несколько признаков
      │
      ▼
score каждого класса
      │
      ▼
лучший маршрут

В поколении v3 были заложены основы дальнейшего Router v4.

Router v4

RAMBA AI Router v4 — текущее поколение системы.

Если v1–v3 в основном решали задачу выбора модели, то серия v4 постепенно превратила Router в полноценный интеллектуальный middleware.

Основные возможности поколения v4:

• context-aware routing;
• session affinity;
• hysteresis;
• история диалога;
• persistent session memory;
• escalation;
• Verifier;
• Semantic Long-Term Memory;
• диагностический API;
• SQLite persistence.

Версии Router v4

Версия	Основное изменение	Статус
v4.1	Развитие новой архитектуры Router v4	Готово
v4.2	Улучшение контекстной маршрутизации	Готово
v4.3	Стабилизация routing logic	Готово
v4.4	Escalation	Готово
v4.5	Verifier и дальнейшее развитие маршрутизации	Готово
v4.6	Persistent Context / Session Memory	Готово
v4.7	Semantic Long-Term Memory	Текущая стабильная версия

Context-Aware Routing

Одной из ключевых проблем ранних версий были короткие follow-up сообщения.

Например:

Пользователь:
В Proxmox vfio-pci не захватывает GTX 1080.

Router:
INFRA

Пользователь:
А как проверить?

Если анализировать только вторую фразу:

А как проверить?

она почти не содержит информации для классификации.

Router v4 учитывает историю разговора и может сохранить прежнюю специализацию.

Таким образом:

Proxmox / GPU passthrough
        │
        ▼
      INFRA
        │
        ▼
"А как проверить?"
        │
        ▼
      INFRA

Session Affinity и Hysteresis

В Router v4 используется концепция session affinity.

Если разговор уже уверенно ведётся одной специализированной моделью, Router не должен переключаться между моделями из-за каждого короткого сообщения.

Hysteresis снижает число ненужных переключений.

Упрощённо:

Current role = INFRA

Новый score:

FAST   3
INFRA  4

Разница небольшая
        │
        ▼
оставить INFRA

Это делает разговор стабильнее.

Escalation

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

Пример:

Request
   │
   ▼
FAST
   │
   ├── ответ достаточный → вернуть
   │
   └── требуется усиление
             │
             ▼
           SMART

Или:

INFRA
  │
  └── сложный анализ
           │
           ▼
         SMART

Таким образом Router может начинать с более дешёвой и быстрой модели, а более мощную использовать только тогда, когда это действительно требуется.

Verifier

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

Его задача — снизить риск выдачи явно слабого, противоречивого или потенциально ненадёжного результата.

Упрощённая схема:

Primary Model
      │
      ▼
    Answer
      │
      ▼
   Verifier
      │
      ├── OK
      │
      └── требуется correction

Verifier является частью поколения Router v4.

Persistent Session Memory — v4.6

Версия v4.6 добавила постоянное хранение истории сессий.

До этого часть session state зависела от жизни процесса Router.

Основная SQLite-база:

/home/artem/ramba-router/ramba-context.db

Для session memory используется таблица:

sessions

Основные поля:

session_id
role
model
messages_json
created_at
updated_at

Архитектура:

Пользователь
     │
     ▼
 session_id
     │
     ▼
RAMBA Router
     │
     ▼
SQLite sessions
     │
     ▼
messages_json
     │
     ▼
LLM Context

В результате история диалога переживает перезапуск процесса Uvicorn.

После рестарта Router может загрузить session state из SQLite.

Semantic Long-Term Memory — v4.7

Версия v4.7 добавила второй независимый механизм памяти.

Если Session Memory хранит историю конкретного разговора, Long-Term Memory хранит отдельные знания.

Пример:

На сервере depo установлена NVIDIA GeForce GTX 1080.

Такой факт не относится к одной конкретной session_id.

Он может использоваться:

• завтра;
• после restart Router;
• в новой сессии;
• в разговоре с другим session_id.

Два уровня памяти

Возможность	Session Memory	Long-Term Memory
Версия	v4.6	v4.7
Привязана к session_id	Да	Нет
Хранит историю диалога	Да	Нет
Хранит отдельные знания	Нет	Да
SQLite persistence	Да	Да
Переживает restart	Да	Да
Работает между сессиями	Нет	Да
Tags	Нет	Да
Importance	Нет	Да
Статистика использования	Нет	Да

Архитектурно:

                RAMBA Router
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
    Session Memory        Long-Term Memory
          │                     │
    current dialog          knowledge
          │                     │
          └──────────┬──────────┘
                     ▼
                 LLM Context

Таблица memory_facts

Для долговременной памяти используется отдельная SQLite-таблица:

CREATE TABLE memory_facts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    scope TEXT NOT NULL,
    fact TEXT NOT NULL,
    tags TEXT,
    importance REAL NOT NULL DEFAULT 0.5,
    created_at TEXT NOT NULL,
    updated_at TEXT NOT NULL,
    last_used_at TEXT,
    use_count INTEGER NOT NULL DEFAULT 0
);

Поля:

Поле	Назначение
id	Уникальный ID факта
scope	Область действия
fact	Текст знания
tags	Поисковые теги
importance	Важность
created_at	Время создания
updated_at	Время изменения
last_used_at	Последнее использование
use_count	Количество использований

Пример Memory Fact

{
  "fact": "На сервере depo установлена видеокарта NVIDIA GeForce GTX 1080",
  "scope": "global",
  "tags": [
    "depo",
    "gpu",
    "nvidia",
    "gtx1080"
  ],
  "importance": 0.9
}

Memory Retrieval

Перед вызовом LLM Router выполняет поиск релевантной долговременной памяти.

Функция:

retrieve_memories()

Упрощённая схема:

User message
     │
     ▼
retrieve_memories()
     │
     ▼
memory_facts
     │
     ▼
relevance score
     │
     ▼
top memories
     │
     ▼
System Context
     │
     ▼
LLM

В версии v4.7 retrieval основан на:

• совпадениях слов;
• совпадениях тегов;
• importance.

Количество одновременно добавляемых фактов ограничено:

MAX_MEMORY_FACTS = 5

Это защищает prompt от чрезмерного разрастания.

Нерелевантная память не добавляется.

Memory API

Версия v4.7 предоставляет отдельное API управления памятью.

Добавление факта

Endpoint:

POST /memory

Пример:

{
  "fact": "На сервере depo установлена видеокарта NVIDIA GeForce GTX 1080",
  "scope": "global",
  "tags": ["depo", "gpu", "nvidia", "gtx1080"],
  "importance": 0.9
}

Просмотр памяти

GET /memory

Удаление памяти

DELETE /memory/{id}

Почему память пока управляемая

В v4.7 модель не записывает новые факты автоматически.

Это намеренное решение.

Если сразу разрешить LLM сохранять любые данные из разговора, могут быстро появиться:

• случайные факты;
• ошибочные утверждения;
• временная информация;
• дубликаты;
• противоречащие друг другу записи;
• слишком большой объём памяти.

Поэтому v4.7 сначала реализует прозрачный жизненный цикл:

explicit add
    │
    ▼
SQLite
    │
    ▼
retrieval
    │
    ▼
usage statistics
    │
    ▼
explicit delete

Автоматическое извлечение памяти будет добавляться отдельным этапом.

Использование Long-Term Memory в /chat

При поступлении нового сообщения выполняется:

/chat
  │
  ├── get_session()
  │
  ├── load Session Memory
  │
  ├── retrieve Long-Term Memory
  │
  ├── route request
  │
  ├── build prompt
  │
  ├── ask Ollama
  │
  ├── escalation / verifier
  │
  ├── save session
  │
  └── response

Ответ API v4.7 содержит диагностическое поле:

"memory_used": [...]

Это позволяет увидеть, какие факты были реально добавлены в запрос модели.

Production-проверка v4.7

После реализации v4.7 был выполнен отдельный production-тест.

В Long-Term Memory был добавлен факт:

На сервере depo установлена видеокарта NVIDIA GeForce GTX 1080.

Затем была создана новая сессия.

Запрос:

Какая видеокарта установлена на сервере depo?

Router нашёл memory fact и ответил:

NVIDIA GeForce GTX 1080.

После этого процесс Router был полностью перезапущен.

После restart была создана ещё одна новая сессия.

Запрос:

Что за GPU стоит на depo?

Результат:

NVIDIA GeForce GTX 1080.

При этом:

history_messages = 0
memory_used       = memory #1
use_count         = 2

Таким образом доказано:

• ответ не зависел от Session Memory;
• память работала в новой сессии;
• память пережила restart Router;
• SQLite persistence работает;
• retrieval правильно нашёл нужный факт.

Тестирование

Для каждой версии Router используется regression suite.

Для v4.7:

test-router-v4.7.py

Проверяются:

• базовая маршрутизация;
• score routing;
• context routing;
• session affinity;
• hysteresis;
• escalation;
• verifier;
• session history;
• persistent session storage;
• Long-Term Memory;
• add memory;
• list memory;
• retrieve memory;
• no-match retrieval;
• use_count;
• last_used_at;
• delete memory;
• SQLite persistence;
• HTTP Memory API.

Финальный результат regression suite:

=== v4.7 MEMORY REGRESSION OK ===

🎉 ALL TESTS PASSED

Memory regression выполняется на временной SQLite-базе и не изменяет production memory.

Health API

Для диагностики используется:

GET /health

Пример v4.7:

{
  "router": "ok",
  "version": "4.7",
  "ollama_loaded_models": [
    "gemma3:4b"
  ],
  "sessions": 2,
  "sessions_memory": 0,
  "sessions_persistent": 2,
  "memory_facts": 1
}

Параметр:

memory_facts

показывает количество долговременных фактов.

Файлы проекта

Основные файлы текущей версии:

/home/artem/ramba-router/router_v47.py
/home/artem/ramba-router/test-router-v4.7.py
/home/artem/ramba-router/ramba-context.db

Исторические версии Router сохранены отдельно и доступны через Git history и release tags.

Production endpoints

Текущий Router v4.7:

127.0.0.1:8003

Дополнительно оставлена резервная контрольная версия v4.5:

127.0.0.1:8002

Она используется как fallback при разработке новых версий.

Git workflow

Разработка каждой крупной возможности ведётся в отдельной feature-ветке.

Для v4.7 использовалась:

feature/semantic-memory-v4.7

Основной commit:

18563ba Add semantic long-term memory for router v4.7

После успешных тестов feature-ветка была объединена с main.

Merge commit:

11b18b2 Merge branch 'feature/semantic-memory-v4.7' into 'main'

Релиз зафиксирован тегом:

v4.7

На момент релиза:

HEAD -> main
origin/main
tag: v4.7

указывали на один релизный commit.

Релизы

Версия	Основное изменение	Статус
v1	Первый keyword router	Историческая
v2	Улучшенная классификация	Историческая
v3	Score-based routing	Историческая
v4.1–v4.3	Context-aware архитектура	Стабильные этапы
v4.4	Escalation	Готово
v4.5	Verifier	Готово
v4.6	Persistent Session Memory	Готово
v4.7	Semantic Long-Term Memory	Current Stable

Ограничения текущей версии

Версия v4.7 уже имеет persistent long-term memory, но это всё ещё первая управляемая реализация.

Текущие ограничения:

• память записывается через API;
• отсутствует automatic memory extraction;
• отсутствует автоматическое обновление фактов;
• нет автоматической дедупликации;
• нет memory consolidation;
• retrieval основан на словах и тегах;
• embeddings пока не используются;
• vector database отсутствует;
• нет confidence-модели для автоматически полученных фактов.

Это сделано намеренно.

Для текущего оборудования с GTX 1080 приоритетными являются:

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

Следующий этап

Следующее поколение RAMBA AI Router должно добавить автоматическое извлечение и управление памятью.

Предварительная архитектура:

Conversation
     │
     ▼
Memory Extractor
     │
     ├── ignore
     │
     ├── create fact
     │
     ├── update fact
     │
     └── merge duplicate
              │
              ▼
         memory_facts
              │
              ▼
      Memory Retrieval
              │
              ▼
             LLM

Основные задачи следующего этапа:

• Automatic Memory Extraction;
• классификация полезности факта;
• защита от случайного запоминания;
• confidence;
• дедупликация;
• обновление изменившихся знаний;
• consolidation;
• conflict detection;
• подготовка к embeddings.

После стабилизации жизненного цикла памяти можно переходить к:

• semantic embeddings;
• vector retrieval;
• RAG;
• внешним knowledge base;
• tool calling;
• AI Agent.

Перспективная архитектура

Долгосрочная цель проекта:

                         User
                           │
                           ▼
                  ┌─────────────────┐
                  │ RAMBA AI Agent  │
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │  RAMBA Router   │
                  └────────┬────────┘
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
          Memory          RAG           Tools
             │             │             │
             └─────────────┼─────────────┘
                           │
                           ▼
                  Model Orchestration
                           │
              ┌────────────┼────────────┐
              │            │            │
              ▼            ▼            ▼
             FAST        INFRA        SMART
                           │
                           ▼
                      Local GPU

В такой архитектуре Router становится не конечным приложением, а центральным AI orchestration layer.

Статус проекта

Компонент	Статус	Версия
Ollama	Готово	—
NVIDIA GPU inference	Готово	—
FAST / Gemma 3 4B	Готово	—
INFRA / Qwen3 8B	Готово	—
SMART / Qwen3.5 9B	Готово	—
Score-based Routing	Готово	v3
Context-Aware Routing	Готово	v4
Session Affinity	Готово	v4
Hysteresis	Готово	v4
Escalation	Готово	v4.4
Verifier	Готово	v4.5
Session Memory	Готово	v4.6
Persistent Context	Готово	v4.6
Semantic Long-Term Memory	Готово	v4.7
Memory API	Готово	v4.7
Automatic Memory Extraction	Планируется	Следующий этап
Memory Consolidation	Планируется	Следующий этап
Embeddings	Планируется	Позднее
Vector Search	Планируется	Позднее
RAG	Планируется	Позднее
Tool Calling	Планируется	Позднее
RAMBA AI Agent	Планируется	Будущий этап

Итог

RAMBA AI Router v4.7 — текущая стабильная версия локального интеллектуального маршрутизатора RAMBA ART.

Проект прошёл путь:

Keyword Router
      │
      ▼
Score Routing
      │
      ▼
Context Routing
      │
      ▼
Escalation
      │
      ▼
Verifier
      │
      ▼
Persistent Session Memory
      │
      ▼
Semantic Long-Term Memory

Текущая система уже умеет:

• автоматически выбирать локальную модель;
• учитывать специализацию запроса;
• сохранять роль в контексте разговора;
• избегать ненужного переключения моделей;
• повышать уровень модели при необходимости;
• проверять ответ;
• сохранять историю сессий в SQLite;
• восстанавливать сессии после restart;
• хранить отдельные долгосрочные знания;
• находить релевантные факты;
• использовать знания в совершенно новой сессии;
• сохранять долговременную память после restart Router.

Ключевой результат v4.7:

RAMBA AI получил настоящий persistent knowledge layer, независимый от конкретного диалога.

Production-проверка подтвердила полный цикл:

Memory Fact
     │
     ▼
SQLite
     │
     ▼
Router Restart
     │
     ▼
New Session
     │
     ▼
Memory Retrieval
     │
     ▼
Correct LLM Answer

Следующий этап проекта — автоматическое извлечение, обновление и консолидация памяти с последующим переходом к semantic retrieval, RAG и полноценному RAMBA AI Agent.