Что происходит, когда LLM ищет что-то в моей памяти

В прошлом посте я рассказал, что MCP даёт языковой модели доступ к Obsidian.

Но сам доступ ещё не означает, что модель получает весь vault целиком.

Когда я задаю вопрос о проекте, система работает иначе.

Сначала LLM решает, какой инструмент ей нужен.

Например, если нужно понять текущее состояние проекта, она может сначала выполнить поиск по нужной области Obsidian.

После этого MCP возвращает не весь проект, а список подходящих файлов и фрагментов.

И только затем модель открывает те документы, которые действительно нужны для ответа.

Упрощённо получается такая цепочка:

вопрос

поиск по проекту

найденные файлы

чтение нужных документов

сбор контекста

ответ

Для меня это принципиальная часть архитектуры.

Если в vault находятся сотни проектов и тысячи файлов, передавать их модели целиком бессмысленно.

Большая часть информации не относится к текущему вопросу и только увеличивает шум.

Поэтому модель перемещается по памяти постепенно.

Например, реальный search-first протокол внутри моего MCP-контура выглядит примерно так:

searchInPath: Projects/Systems/PRJ-002 Network

query: internet OR VPN OR DNS OR MacStudio OR "Mac Studio" OR "MacBook Air" OR route OR routing OR split

Сначала задаётся область поиска.

Затем одним запросом система пытается получить достаточно широкий набор кандидатов.

После этого читаются только наиболее релевантные файлы.

Такой подход появился не только ради экономии контекста.

В какой-то момент я столкнулся с rate limit Obsidian MCP.

Если модель начинает перебирать предполагаемые названия файлов и делать много последовательных запросов, сервер может вернуть 429 и временно остановить дальнейший доступ.

Поэтому внутри проекта появился отдельный принцип:

сначала поиск, потом чтение.

Не угадывать файлы один за другим.

Не читать весь проект заранее.

Не продолжать запросы после 429.

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

Технически сам MCP-клиент тоже работает через последовательность отдельных операций.

Сначала создаётся MCP-сессия.

Затем клиент получает список доступных инструментов.

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

Упрощённо:

initialize

mcp-session-id

tools/list

tools/call

То есть MCP не является каналом, через который в LLM постоянно течёт весь Obsidian.

Это скорее набор дверей в проектную память.

Модель сама решает, какую дверь открыть, получает небольшой участок информации и при необходимости идёт дальше.

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

Я могу спросить о проекте, которым не занимался несколько недель, а модель сама найти его текущее состояние, прочитать нужные источники и восстановить контекст из реальных файлов.

Но пока мы говорили только о логике доступа.

Есть ещё один вопрос: как удалённая LLM вообще вызывает MCP-сервер, который физически работает на моём Mac?

В следующем посте разберу весь путь запроса от внешней модели до локального Obsidian.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все проекты 🎶

💻 annFlow