Veynrel: LLM-советы для Obsidian проверяют по цитатам перед правкой

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Паттерн «модель советует — код валидирует цитаты, планировщик строит diff, человек подтверждает» становится обязательным для любого AI-функционала, который пишет в рабочие данные.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

В Obsidian появился плагин Veynrel, который советует, что делать с похожими заметками. Интересна здесь не сама фича, а обвязка вокруг неё. Автор под ником Ziverpup разложил путь от «модель нашла пару» до «в Markdown изменилась строка» на четыре независимых этапа: каталог цитат, валидация ссылок, планировщик операции, подтверждение diff. Запись напрямую модель не делает никогда.

Смысл для бизнеса шире заметок. Это готовый шаблон для любого AI-функционала, который пишет в рабочие данные: карточку клиента, прайс, задачу в трекере, шаблон договора. Если у вас в продукте есть кнопка «применить», её придётся собирать по такой же схеме.

Что именно собрали

Поиск похожих заметок устроен предсказуемо. Текст режется на осмысленные фрагменты, для фрагментов считаются векторы, векторы сравниваются. Найденная пара — кандидат. Повод открыть два файла и посмотреть, а не команда на слияние.

Дальше начинается скучная часть, из-за которой всё и держится. Перед вызовом модели локальный код читает сохранённые файлы и собирает каталог фрагментов. У каждого фрагмента есть сторона (A или B), точный срез текста и идентификатор вида nonce:A:0. Модель не может вернуть произвольную цитату. Она обязана сослаться на ID из каталога, код сам находит фрагмент и подставляет текст.

Ответ проверяется по схеме veynrel.relationship.refs.v2. Выдуманный ID, ссылка на фрагмент из другой заметки, битая схема, устаревший снимок файла — всё отбивается с кодами reference_unknown и reference_side_mismatch. Ссылку не «исправляют по смыслу». Её отклоняют, и результат не попадает на следующий этап.

На тестовой паре с двумя одноимёнными заметками Cache lifetime (Study/Caching и Study/Systems) модель предложила связать файлы, а не слить. Предложение само по себе не создало ни одной ссылки.

Совет — ещё не правка

Согласились связать. Вставить [[Cache lifetime]] нельзя: файлов с таким именем два, и переход приведёт не туда. Дальше нужны решения, которые модель принимать не должна: какая заметка ссылается на какую, в какой абзац ставить ссылку, можно ли вообще трогать этот абзац. В Markdown попадаются списки, кодовые блоки, таблицы, frontmatter, встроенные ссылки.

Этим занимается планировщик. Он не исполняет команду из JSON — он переводит разрешённый тип рекомендации в параметры операции: направление, место, подтверждение. На неподдерживаемой структуре или при нехватке данных он отказывает. Перед записью код проверяет, куда Obsidian реально разрешит ссылку при двух одноимённых файлах, и блокирует запись, если затронутые редакторы открыты. Пользователь видит точный diff до/после, подтверждает применение отдельно, после чего план перепроверяется на устаревший снимок файла. Есть Undo.

Где подвох

Валидация цитат закрывает галлюцинации уровня «такой фразы в файле нет». Она не закрывает «фраза есть, но вывод шире, чем она подтверждает».

Проверка доказывает только, что цитата есть в нужной заметке. Разумен ли тезис, решает человек.

Автор проверил это на себе: десять реальных запросов к DeepSeek прошли техническую валидацию, но как минимум один тезис подтверждался выбранной цитатой лишь частично. Все защиты сработали, а вывод всё равно пришлось править руками.

Второй подвох спрятан в самих кандидатах. Предыдущий разбор, сделанный вручную, дал такую картину: 40 синтетических заметок, десять найденных пар, девять полезных, но уверенно связать получилось только четыре. Находить похожее и решать, что с этим делать, — разные задачи.

Близость векторов не говорит, нужно ли объединять документы. Даже сходство 0.95 означает не «95% уверенности в дубликате», а лишь близость в выбранном векторном пространстве.

Третий подвох — данные. Для удалённого провайдера текст заметок уходит наружу, поэтому плагин сначала показывает подготовленный запрос и требует согласия. Локальный Ollama через настраиваемый endpoint факт передачи данных не отменяет.

Кому это нужно

Всем, кто строит AI-фичу с записью в рабочие данные. Три роли нужно развести жёстко: модель предлагает, код проверяет ссылки и строит план, человек подтверждает diff. Если в вашей архитектуре модель сразу вызывает запись в CRM или в документ, вы покупаете файл с правками, а не решение.

Второй слой — каталог. Любая ссылка модели на источник должна указывать на ID из заранее собранного набора. Свободный текст в поле «цитата» не проверяется никак.

Брать или подождать: вердикт за 30 секунд

• Брать как референс архитектуры — если у вас в бэклоге есть AI-функция с записью в данные. Схема переносится на любую LLM, не только на заметки.
• Подождать — если нужен готовый «умный» инструмент для команды прямо сейчас. Плагин про поиск и аккуратную правку заметок, а не про автоматизацию документооборота.
• Не брать — если в вашем процессе нет человека, готового смотреть diff. Без него защита превращается в формальность.

FAQ

Модель вообще не может изменить файл?

Не может. Запись идёт только через планировщик и подтверждение diff, плюс доступен Undo.

Валидация цитат гарантирует корректность вывода?

Нет. Она гарантирует, что цитата существует в нужной заметке. Разумность тезиса проверяет человек.

Что будет, если файл изменили между планом и применением?

План перепроверяется на устаревший снимок, запись не проходит. Открытые затронутые редакторы тоже блокируют применение.

Данные уходят наружу?

Для удалённого провайдера — да, поэтому запрос показывают до отправки и просят согласие.

Что сделать на этой неделе

1. Выпишите все места в продукте, где AI сейчас пишет в рабочие данные без подтверждения. Список будет коротким и неприятным.
2. Для каждого места введите каталог источников: ID, сторона, точный срез. Модель ссылается только на ID.
3. Добавьте два отказа: неизвестная ссылка и ссылка не на ту сторону. Не «исправляйте по смыслу».
4. Отделите планировщик от модели. Он переводит тип рекомендации в параметры операции и умеет говорить «нет».
5. Сделайте экран diff и отдельную кнопку подтверждения. Без них остальное не считается.
6. Прогоните десять реальных запросов и вручную проверьте, где цитата подтверждает тезис частично.

Проверьте свою AI-фичу на один вопрос: если модель ошибётся, кто это заметит до записи в файл? Если ответ «никто, потом поправим» — вы уже платите за инциденты, просто ещё не знаете их стоимость.