/ заметки · 16 мая 2026 г. · rag · self-hosted · знания

Самохостинговый RAG на Claude Max

OpenKB, Meridian и маршрут OAuth к Claude Max. Заметки про сборку личного retrieval-augmented стека без потокенного API-счёта.

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

OpenKB это индекс. Он берёт документы, которые меня интересуют (статьи, договоры, справочные материалы, личные заметки) и компилирует их в запрашиваемую вики со ссылками между документами. Себя он выставляет Claude Code как stdio MCP-сервер, что означает: сессия Claude может задавать ему вопросы через типизированный интерфейс инструментов. Шаг компиляции делает свой собственный LLM-вызов внутри; я выставил его на Sonnet, потому что связки получаются лучше, чем на меньших размерах, а разница в скорости неважна для фонового задания.

Meridian это маршрутизатор. Это маленький постоянно работающий сервис, который держит OAuth-сессию к Claude Max и локально предоставляет конечную точку в форме OpenAI. Всё в доме, что хочет говорить с моделью Claude, сначала говорит с Meridian. Meridian затем говорит с Claude по OAuth-маршруту, и именно эта часть переводит маржинальную стоимость с потокенной на нулевую. Компромисс это лимиты скорости вместо счетов, и для личного стека это правильный обмен.

Claude Code это агент, который связывает их. Когда я задаю вопрос, требующий контекста из документов, он вызывает OpenKB через MCP, получает релевантные фрагменты и отвечает. Когда вопрос этого не требует, он отвечает напрямую. Маршрутизация лежит в CLAUDE.md, не в проводе.

Несколько вещей, которые это научило, и которые я бы не предсказал.

Self-hosted RAG это в основном про латентность и доверие, а не про стоимость. Экономия в стоимости реальна, но не она делает опыт лучше. Лучше его делает то, что индекс живёт в той же сети, что и агент, и поэтому запрос ощущается как обращение к коллеге, а не как звонок поставщику. И я точно знаю, что в индексе, потому что я сам это туда положил.

Самое сложное это не retrieval; это кураторство. Наивный RAG по всему, что я когда-либо писал, хуже, чем аккуратный индекс из сорока документов. Модель полезнее, когда корпус меньше, более когерентен и семантически плотнее. Я тратил больше времени, решая, что НЕ должно быть в индексе, чем что должно.

У OAuth-маршрутизации непростительный режим отказа. Если API-ключ установлен в любой shell где-нибудь на хосте, прокси молча обходится, и попадание идёт в реально оплачиваемый API. В первый раз, когда я это отследил, я научился grep’ать свои dotfiles на предмет случайных export. Защитная привычка теперь: unset этой переменной в начале каждой точки входа, которая должна маршрутизироваться через Meridian.

Модель знает, когда она в бейдже. Каждый ответ несёт маленький сигнал в квадратных скобках, обозначающий, какой путь его обслужил: прямой вызов, вызов с инструментами, медленная opt-in эскалация к большей модели. Это не только диагностика; это меняет, как я читаю ответ. Прямой вызов это уверенная догадка. Вызов с инструментами имеет квитанции. Эскалационный ответ это обдуманный.

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

Пока стек работает, счета предсказуемы, а индекс растёт примерно так же быстро, как моё внимание. Это примерно то, что я хотел.

← все заметки