Сервер ідентифікації

Звичайний сервер підтримує прослуховувач MCP/ZeroMQ до зупинки. За наявності URL моделі він відновлює перервану роботу під час запуску; завершені або явно зупинені пакети залишаються бездіяльними.

New Batch передає серверу джерело, призначення й розмір пакета. Сервер автоматично виконує ідентифікацію, зіставлення TMDB, вибір кандидатів, збереження каталогу й переміщення медіафайлів. Звичайні файли обробляються групами до 10, а потім обробляються відповідні каталоги. Дивіться схему пакета та шаблони каталогів.

Явний діагностичний режим --run-batch вибирає звичайні файли безпосередньо в джерелі, виключає підкаталоги й символьні посилання, визначає файли та завершує роботу. Він може завантажити збережену робочу область і пропустити готові результати. Сама ідентифікація не змінює початкові файли; діагностичний режим не запускає звичайний автоматичний імпорт.

Компоненти

Класи робочого процесу розташовані у r3el/app, запити — у r3el/app/prompts, MCP-інструменти — у r3el/app/tools. Запуск MCP через stdio: python -m r3el.app.tools.

FileMgr — інтерфейс файлової системи.
FileContext, SubmitIdentificationPrompt та InvalidIdentification окремо надають контекст, інструкції інструмента та виправний зворотний зв’язок.
BatchIdentification і ToolConversation координують пакет і окремі діалоги.
LLM та IdentificationTools з’єднують HTTP та stdio MCP; схема інструментів виявляється через MCP і надсилається разом із запитом до моделі.
MCP-міст SubmitIdentification пересилає значення через ZeroMQ.
SubmissionHandler і ValidateIdentification працюють у R3el, виконують звичайну перевірку форми та повертають ідентифікацію або відмову.
Identification зберігає прийняту назву, рік і цілу впевненість від 0 до 10.
MediaFileBatch та MediaFile містять поточні дані робочої області.
WorkspaceDb зберігає й відновлює робочу область через спільний DbMgr.

Модель пропонує лише значення полів. R3el призначає ідентифікатори пакета, елемента й спроби поза контролем моделі. Прослуховувач визначає активний контекст серверної спроби за її ID.

Запити з даними використовують JSON-об’єкт з окремими полями instructions і data. Дати, імена файлів та причини відхилення залишаються структурованими. Вибір TMDB використовує такий самий формат: об’єкт query і масив candidates з полями number, title, overview та vote_count. Уривки описів включають завершення речення після приблизно 160 символів; якщо опису немає, передається порожній рядок. Запити тільки з інструкціями, як-от focus, зберігають своє формулювання.

Результати й журналювання

Дивіться постійну робочу область для станів і лічильників.

Приховані імена (починаються з .) позначаються unresolved_hidden_file із нулем спроб і ніколи не надсилаються LLM. Вони враховуються в розмірі пакета та залишаються у результатах і журналі.

Кожне інше ім’я отримує одну початкову та не більше MAX_LLM_RETRIES = 2 виправних спроб. Неправильна структура виклику інструмента або відхилені дані форми спричиняють виправний запит. Після вичерпання спроб зберігається unresolved_llm, і обробка переходить до наступного файлу. Прийнятий результат — identified, а не підтверджений збіг TMDB. Запити й схема інструмента вимагають цілочисельної впевненості від 0 до 10. Дробові числа, рядки, булеві значення й числа поза діапазоном відхиляються без приведення типів.

Помилки HTTP, MCP, бази даних або транспорту зупиняють пакет і не перетворюються мовчки на помилки ідентифікації. SIGTERM/SIGINT скасовують поточний діалог, закривають процес MCP і прослуховувач та зупиняють сервер.

Журнал подій містить знайдені імена файлів, джерела й вміст запитів, сирі відповіді моделі, надходження та результати інструментів, рішення перевірки й результати файлів і пакетів. JSON містить ID пакета/елемента/спроби; ID елемента — це ID MediaFile. Батьківські ID поєднують події пакета, елемента, спроби й інструментів. Результати зберігаються у media_file_batches та media_files, фіксуються в журналі й виводяться як JSON. Результат файлу включає issues.

Перезапуск і робоча область

Результат кожного файлу фіксується разом із подією завершення. Повторний --run-batch завантажує збережений пакет і пропускає готове; перерваний файл починає новий діалог. Збережені каталог, вибір і розмір пакета мають перевагу над новими аргументами --film-dir і --batch-size. Робочу область може використовувати тільки один процесор. Поновлення записує batch_resumed.

Пакет identification_completed доступний для майбутнього зіставлення й перевірки. Повторний --run-batch повертає готові результати без звернення до моделі. Clear Current Batch видаляє робочі записи після зупинки обробки, зберігаючи медіафайли, каталог і журнал.

Встановлення й оновлення застосовують EventSchema, потім WorkspaceSchema, включно зі станами життєвого циклу зіставлення. Служба завантажує облікові дані TMDB з /etc/r3el/tmdb.env.

Запуск

Для запуску з вихідного коду встановіть залежності та задайте DB_HOST, DB_USER, DB_PASSWORD, DB_NAME (DB_PORT за замовчуванням 3306). Ініціалізуйте обидві схеми та підключіться до стандартного порту інференсу LlamaSrv:

.venv/bin/python -B -m r3el.activity.EventSchema
.venv/bin/python -B -m r3el.activity.WorkspaceSchema
.venv/bin/python -B -m r3el.server.R3elServer --run-batch --llm-url http://127.0.0.1:51001

Додаткові --film-dir, --batch-size та --zmq-endpoint перевизначають значення DR3el; стандартний пакет — 10. Для ізольованої робочої області використовуйте окрему базу даних. У режимі --run-batch задайте --llm-url або R3EL_LLM_URL; для бездіяльного запуску сервера вони не потрібні.

Встановлення/оновлення готує службу systemd, але залишає її зупиненою та без автозапуску. Типова R3EL_LLM_URL — http://127.0.0.1:51001, стандартна адреса інференсу LlamaSrv; її можна змінити через /etc/r3el/server.env. Окремо запустіть LlamaSrv, дочекайтеся HTTP 200 від http://127.0.0.1:51001/health (або налаштованої адреси моделі), а потім запустіть прослуховувач:

sudo systemctl start r3el-server.service

Якщо відновлювати нічого, служба очікує нових пакетів. Лише діагностичний --run-batch завершується після ідентифікації. Звичайна служба приймає пакети з вебінтерфейсу.

Сервіс моделі LlamaSrv

LlamaSrv (репозиторій GitHub) запускає локальну модель Qwen і керує нею незалежно від R3el. Спочатку виконайте інструкції LlamaSrv зі встановлення й підготовки моделі. Стандартна модель — Qwen3.5-4B. Застосунки надсилають OpenAI-сумісні запити на порт інференсу 51001; порт 51000 призначений для панелі керування LlamaSrv. R3el використовує цей документований стандарт у r3el/constants/DLlama.py, а не оголошує власний прослуховувач моделі.

Встановлення, оновлення, видалення та scripts/services.sh керують лише службами R3el. Вони не створюють, не запускають, не зупиняють і не видаляють LlamaSrv, його облікові записи/конфігурацію, llama.cpp або файли моделей. Модель може бути зупинена під час встановлення R3el чи перегляду каталогу, але має бути готова перед ідентифікацією або вибором кандидатів через LLM. Для стандартного встановлення LlamaSrv:

sudo systemctl start llamasrv-llm.service
curl -fsS http://127.0.0.1:51001/health

Дочекайтеся HTTP 200 перед запуском сервера пакетів R3el. Для іншого хоста або порту інференсу задайте R3EL_LLM_URL у /etc/r3el/server.env; див. підключення до моделі.

Залиште параметр LlamaSrv llama.jinja увімкненим (типове значення): він передає --jinja до llama-server. Модель Qwen потребує шаблону чату з підтримкою інструментів; див. документацію llama.cpp. R3el запускає власний stdio MCP-процес, надсилає схеми інструментів із кожним запитом, виконує отримані виклики й повертає результати, коли потрібне виправлення. Запит містить tool_choice: "required" і parallel_tool_calls: false; очікується один структурований елемент message.tool_calls з ID, назвою функції та аргументами, закодованими як JSON. Реєструвати інструменти R3el чи задавати --mcp-servers-config у LlamaSrv не потрібно. Інші застосунки можуть передавати й виконувати власні інструменти через той самий сервіс моделі.

Після оновлення старішого встановлення R3el нова служба використовує порт 51001, якщо /etc/r3el/server.env не перевизначає R3EL_LLM_URL. Наявні перевизначення зберігаються: оновіть стару адресу або видаліть перевизначення, щоб використати стандарт LlamaSrv. Раніше встановлений qwen-server.service, його файли й облікові записи залишаються без змін. Виводьте цю службу з експлуатації окремо, перевіривши інші застосунки, що її використовують.

Перевірка

.venv/bin/python -B -m unittest discover -s tests -v
sudo env R3EL_TEST_DB=1 .venv/bin/python -B -m unittest discover -s tests -v

Друга команда потребує доступу до MariaDB root через socket і створює та видаляє унікальну тестову базу й користувача. Використовуються тимчасові імена файлів і підробна LLM, а не робочі файли чи база. Інтеграційні тести перевіряють HTTP, MCP, ZeroMQ, MariaDB, відкочування контрольної точки, ексклюзивність обробки й відновлення після примусового завершення сервера посеред пакета.