
Использование режимов QA в Obsidian Copilot
Obsidian Copilot реализует режимы QA (Question-Answer, вопрос-ответ), которые помогают ИИ работать с нашими заметками. Эти режимы позволяют Copilot находить нужную информацию в заметках, отвечать на вопросы по заметкам картотеки, создавать новые заметки на основе существующих и многое другое. Режимы QA Copilot рассматривались ранее в статье Obsidian и нейросети, однако их применение на практике может вызывать трудности. В этой статье я подробно расскажу, как использовать режимы QA в Obsidian Copilot. Настройка рассматривается в статье Настройка Copilot в Obsidian, а использование Copilot в обычном режиме в статье Сценарии использования Obsidian Copilot.
В отличие от обычного режима чата, режимы QA используют эмбеддинги. Чтобы раскрыть весь потенциал режимов QA и избежать разочарований, крайне важно понимать несколько основных принципов работы ИИ и поиска информации.
Еще раз об эмбеддингах и смысловом поиске
Любая нейросеть отвечает на основании того массива данных, который использовался для её обучения. Несмотря на то, что этот массив очень большой, модель может не знать определённые факты, термины или определения, особенно частного порядка. При ответах на подобные вопросы модель либо начинает фантазировать, придумывая наиболее подходящий ответ, либо честно говорит: «Я не знаю».
Переобучение модели — это крайне затратный и сложный процесс, требующий огромных вычислительных ресурсов. Поэтому был разработан более эффективный способ: в самом запросе заранее сообщать модели нейросети ряд наводящих фактов и подробностей, что позволяет получить достаточно точный и чёткий ответ на вопрос. Например, запрос «Напиши список отличников в нашем классе» (на который ни одна модель не даст ответ!) можно представить так:
Вова по истории получил 5
Маша по математике получила 4
Петя по физике получил 2
Саша по физкультуре получил 4
Напиши список отличников в нашем классе.
В этом случае ответ будет корректным, что можно проверить в любой модели нейросети. Вот пример ответа модели gemma2
, работающей локально на моем ноутбуке. На ответ у неё ушло примерно 12 секунд, в то время как сетевые модели, такие как ChatGPT, ответят мгновенно.

Таким образом, для ответов на подобные частные вопросы необходимо, во-первых, подобрать правильные факты из большого объёма частной информации, а во-вторых, подставить эти факты в запрос модели. Именно это и реализуют режимы QA в Obsidian Copilot.
Метод RAG (Retrieval-Augmented Generation)
Для подбора фактов для подстановки в запрос используется специальный метод семантического поиска, называемый RAG (Retrieval-Augmented Generation).
Методы поиска в тексте можно условно разделить на две большие группы:
- Лексический (словарный) поиск
- Семантический (смысловой) поиск
Первая группа включает поиск по словам и их словоформам (склонениям, спряжениям и т.п.), а также по синонимам. Однако такой поиск, несмотря на его понятность и привычность, может не находить правильные документы, особенно по нечетким запросам, например, «Кино про мужика, который на Марсе картошку сажал«.
Семантический поиск, в свою очередь, является более сложным. Его суть заключается в использовании эмбеддингов, то есть представлении объектов поиска (в нашем случае — достаточно длинных фрагментов текста) в виде наборов чисел, или, как говорят, векторов в многомерном пространстве смыслов. Упрощенно это можно представить так: берётся фрагмент текста и оценивается по ряду критериев: насколько этот текст о людях?, насколько он рассказывает о деревьях? и т.п. Каждый критерий — это отдельная размерность в многомерном пространстве смыслов, а их комбинация указывает на некую точку, где числа — это координаты этой точки.
Для чего это нужно? Почему бы не использовать просто лексический поиск? В случае коротких нечетких запросов лексический поиск значительно снижает качество отбора документов, особенно если в них нет искомых слов. Семантический поиск находит документы, близкие по смыслу к запросу. Кроме того, эмбеддинги могут применяться не только к текстовым документам, но и, например, к изображениям.
Модели эмбеддингов
Чтобы вычислить эмбеддинги, то есть наборы чисел (векторы) для каждого фрагмента текста в исходных документах, используется специально обученная модель. Она значительно отличается от моделей, с которыми мы ведем чаты. Её задача — получить объект (в нашем случае фрагмент текста) и посчитать вектор для него, то есть вернуть набор чисел. У разных моделей количество чисел в векторе и может варьироваться, от нескольких сотен до тысяч. С одной стороны, чем больше — тем лучше, но с другой стороны, векторы с большим количеством координат сложнее и тяжелее сравнивать между собой при отборе документов.
Настройку моделей эмбеддингов в Obsidian Copilot мы рассматривали в статье Настройка Copilot в Obsidian, и здесь повторять не будем, но отметим несколько крайне важных моментов.
Во-первых, при выборе моделей эмбеддингов крайне важно учитывать, обучалась ли модель на документах с требуемым языком. Например, популярная и рекомендуемая в англоязычных источниках модель nomic-embed-text
, судя по всему, не обучалась на русском языке, по крайней мере, мне нигде не удалось найти упоминания об этом. Поэтому её использование для русских документов и запросов приведёт к низкому качеству отбора документов по смыслу. После многочисленных экспериментов я пришёл к использованию модели bge-m3
, для которой явно заявлено обучение на более чем 100 языках, включая русский. Более подробно о настройке говорится в статье Настройка Copilot в Obsidian.
Во-вторых, для работы эмбеддингов и режимов QA необходимо полностью проиндексировать все заметки вашего Obsidian и посчитать для них векторы. Это медленный процесс, особенно если мы используем локальную модель эмбеддингов. Например, у меня при общем количестве заметок около пяти тысяч этот процесс занял чуть более пяти часов. Далее следует регулярно переиндексировать новые или изменённые заметки. Это можно сделать либо автоматически (настраивается в параметре Auto-Index Strategy в настройках Copilot), либо вручную, командой «Index (refresh) vault for QA». Я лично это делаю раз в один-два дня, и это занимает несколько минут.
Можно, конечно, использовать и сетевые модели эмбеддингов, у которых ресурсов значительно больше, чем у нашего компьютера. Но в этом случае важно понимать, что вы собираетесь сначала выгрузить все ваши заметки, а затем регулярно выгружать все новые и изменённые. Это может быть, во-первых, дорого, а во-вторых, не все согласятся делиться всей своей информацией с кем бы то ни было.
Режимы QA в Obsidian Copilot
Как было сказано ранее, существует два режима:
- Long Note QA
- Vault QA
В обоих случаях Copilot сначала превращает ваш запрос в векторное представление, то есть вычисляет и получает числа вектора с помощью модели эмбеддингов, затем находит рядом стоящие вектора в пространстве смыслов (напомним, вектор — это координаты точки). Он находит самые близкие точки к расчетной точке запроса, то есть наиболее близкие по смыслу заметки к запросу, и на основе полученных векторов подставляет несколько заметок (точнее, фрагментов текста из этих заметок) в ваш запрос. И уже такой обогащённый запрос отправляется нейросети.
Здесь важно понимать два момента:
- Всю подготовительную работу (расчёт эмбеддинга для запроса, расчёт близких векторов) Copilot выполняет локально, на вашем компьютере, и ему на это нужно время, поэтому любой запрос в режимах QA будет медленнее, чем в обычном чате.
- Obsidian Copilot выбирает и подставляет в запрос несколько фрагментов из нескольких заметок, но не из всех! Этот параметр Max Sources указывается в настройках плагина и обычно равен 3. Бесполезно задавать в режимах QA вопросы, которые требуют большего числа заметок. Например, «Найди мне все заметки, которые я делал в 2023 году, и обобщи их» — ответ будет гарантированно неполным! Кстати, это ограничение исключительно на уровне плагина; автор, видимо, посчитал, что так будет лучше и быстрее — ограничивать число выбранных источников данных для расширения запроса.
Разница между режимами заключается в том, какие именно вектора будут использованы для расчёта смысловой близости к запросу. В режиме Long Note QA будут использованы вектора фрагментов текста только текущей заметки, а в режиме Vault QA — всего хранилища Obsidian.
Рассмотрим их более подробно.
Long Note QA
Как можно понять из названия, этот режим позволяет выбирать фрагменты текста из текущей заметки по смыслу запроса и обогащать ими сам запрос. Этот режим имеет смысл и практическую пользу только на действительно больших заметках. Важно понимать, что у любой модели, с которой вы ведёте чат, есть такой параметр, как размер контекстного окна, фактически, сколько текста она воспринимает в запросе (и помнит в предыдущих вопросах и ответах). Например, для модели chatgpt-4o-mini
этот параметр равен 128K токенов. Это очень большое контекстное окно. Одно слово примерно равно 2 токенам, то есть мы имеем около 60 тысяч слов.
Если ваша заметка по объёму меньше, чем размер контекстного окна используемой модели, режим Long Note QA не нужен! Намного проще и быстрее просто загрузить заметку целиком в нейросеть с помощью кнопки в чате Copilot и задавать вопросы по ней.
Но если заметка больше, чем контекстное окно модели, вот здесь и пригодится Long Note QA. Это могут быть большие заметки с объёмными документами, например, полное описание какого-либо стандарта, заметка, которая включает в себя длинную переписку с кем-либо, должностные инструкции, сложенные в одну большую заметку и т.п. В этом случае Copilot сможет отвечать на вопросы по этому тексту.
Для экспериментов и демонстрации я взял полный текст романа А.С. Пушкина «Евгений Онегин» (26 тысяч слов, и это, скорее всего, поместится в контекстное окно chatgpt-4o-mini). Эксперимент не совсем чистый, так как произведения Пушкина хорошо известны многим моделям, да и классический язык, на котором писал Пушкин, немного отличается от современного русского. Но всё же результаты очень интересные.
Вот простой запрос: «Какова причина дуэли между Ленским и Онегиным?«. На ответ потребовалось 14 секунд, и ответ оказался более чем правильным и полным.

Более сложный вопрос: «Зачем Онегин сорвался и срочно уехал из Петербурга в деревню?«
Ответ неверный: «Онегин уехал из Петербурга в деревню в результате душевного смятения и разочарования, вызванного его отношениями с Татьяной и конфликтом с Ленским….«. Нейросеть перепутала два факта: приезд Онегина в деревню по причине смерти дяди и его отъезд из деревни после дуэли.
Пробуем уточнить вопрос: «Что побудило Онегина изначально переехать из Петербурга в деревню? Не придумывай ответ, используй только предоставленную информацию.«

Здесь, по крайней мере, нейросеть честно сказала «Я не знаю!» и явно указала, что далее лишь её предположения. Однако они неверны, жизнь Онегина сложно назвать уединённой, он посещал балы и различные тусовки в Питере того времени. ChatGPT не смог ответить, потому что у Пушкина причины резкого переезда Онегина в деревню упоминаются вскользь и в разных местах: во введении (дядя не в шутку занемог) и в одной из глав (дядя умер, и Онегин получил наследство):
Вдруг получил он в самом деле
От управителя доклад,
Что дядя при смерти в постели
И с ним проститься был бы рад.
Прочтя печальное посланье,
Евгений тотчас на свиданье
Стремглав по почте поскакал
И уж заранее зевал,
Приготовляясь, денег ради,
На вздохи, скуку и обман
(И тем я начал мой роман);
Но, прилетев в деревню дяди,
Его нашел уж на столе,
Как дань готовую земле.
Хорошо, попробуем вопросы, на которые гарантированно есть ответы: «Как звали и какая профессия была у Ленского?«.
Ответ более чем полный и корректный: «В произведении «Евгений Онегин» персонажа по имени Ленский зовут Владимир Ленский. Он является поэтом, что подчеркивается в тексте, где говорится о его увлечении поэзией и романтическом восприятии мира. Ленский изображён как молодой, чувствительный и идеалистичный человек, который стремится к высоким чувствам и вдохновению, что отражает его профессию и характер.«
Таким образом, Long Note QA удобно использовать на очень больших заметках, длинных документах, собранных текстах из большого числа разных заметок.
Рекомендации по использованию режима Long Note QA:
- Используйте его только в том случае, если заметка значительно больше контекстного окна модели. В противном случае проще загрузить всю заметку в модель.
- При формулировании запроса старайтесь чётко описывать, что вы хотите получить.
- Если ответ явно не соответствует ожиданиям, попробуйте очистить предыдущий контекст беседы. Например, на мои вопросы и намёки на смерть дяди (переезд Онегина в деревню) ChatGPT упорно держался за факт дуэли с Ленским. Видимо, он проводил аналогию «смерть — дуэль — срочно уехал — из-за женщины«. Помогла очистка контекста — новый чат.
Vault QA
В отличие от Long Note QA, в режиме Vault QA используются вектора всех заметок в хранилище Obsidian для выбора подходящих по смыслу фрагментов текста. То есть нейросеть может отвечать на произвольные вопросы по любой теме в вашем Obsidian. Однако следует помнить о следующих моментах:
- Чем более подробно расписаны ваши заметки, тем лучше будет ответ. Здесь на качество напрямую влияют принципы Zettelkasten, а именно самодостаточность заметки.
- Для формирования расширенного запроса используются лишь несколько наиболее близких по смыслу заметок (параметр Max Sources), поэтому качественный ответ будет в том случае, если вся требуемая информация содержится в нескольких заметках, число которых меньше этого параметра. Поэтому бесполезно задавать вопросы, которые требуют большого числа заметок, например, «Перечисли даты, когда я занимался проектом XXX«, если у вас нет одной такой заметки с хронологией, а лишь упоминания проекта в ежедневных заметках, то полного ответа вы не получите.
Тем не менее, вариантов использования режима масса. Это отличный инструмент семантического поиска и анализа информации в вашей картотеке Obsidian. Вот некоторые из них:
Поиск специфической информации в ваших заметках
Существует два вида поиска: лексический (словарный), который представляет собой обычный поиск в Obsidian и, к примеру, OmniSearch, и семантический поиск, который осуществляется по смыслу. Они не пересекаются. Второй нужен тогда, когда вы не помните ни ключевые слова, ни названия заметки, а помните лишь смысл, о чём она.
Вот пример:

Вот ещё отличный пример: я помню, что записывал цитату, но не помню, куда и к какой книге (это пример, на самом деле я помню автора и книгу).

Информация по конкретной теме
Можно задавать вопросы по конкретным проектам, темам или разделам в вашей картотеке. Вот наглядный пример:

Но помните, что если вы знаете, что таких заметок у вас много, ответ может быть неполным, так как число источников ограничено.
Вот ещё один наглядный пример:

Ответ более чем правильный и полный, он просто не помещается на скриншоте. Более того, он связал в ответе сохранённые мною цитаты из книг Дорофеева, принципы Zettelkasten и инструменты Obsidian, которые у Дорофеева не упоминаются, но упоминаются в моих заметках.
Кстати, можно использовать теги, особенно если они указаны во фронтматтере заметки. А у меня именно так, более того, теги в заметке Copilot и пишутся.
Вот пример такого запроса в режиме Vault QA:

Ответ правильный, достаточно полный и полностью меня удовлетворяющий. Я не привожу ответы на этот вопрос и выше целиком, потому что они объёмные, например, сейчас он накатал почти полный лист A4 с рекомендациями.
Поиск связанной информации
Очень интересный пример, в котором я ищу возможные связи с другими заметками:

Здесь я приведу ответ нейросети полностью:
На основании заметки Настройка и использование режимов QA в Obsidian Copilot можно выделить несколько связей с другими заметками по теме, которые могут быть полезны для дальнейшего изучения и анализа. Вот некоторые из них:
1. Эмбеддинги: Эта заметка важна, так как эмбеддинги являются основой работы режимов QA в Obsidian Copilot. Понимание того, как работают эмбеддинги, поможет лучше осознать, как Copilot обрабатывает запросы и находит информацию.
2. RAG: Метод RAG (Retrieval-Augmented Generation) описывает, как происходит семантический поиск и подбор фактов для формирования ответов. Эта заметка поможет углубить понимание механизмов, лежащих в основе режимов QA.
3. Ollama: Если Ollama связан с использованием нейросетей или моделей для обработки текста, то эта заметка может дать дополнительные идеи о том, как интегрировать различные инструменты для улучшения работы с заметками.
4. План статьи и черновые материалы Режимы QA Obsidian Copilot: Эта заметка может содержать предварительные идеи и черновики, которые помогут понять, как развивалась концепция режимов QA и какие аспекты были важны для автора.
Эти связи помогут вам глубже понять, как работают режимы QA в Obsidian Copilot, и как они могут быть использованы для более эффективного поиска и обработки информации в ваших заметках.
Что интересно в этом ответе: в настоящей статье я не упоминал Ollama, рассчитывая, что локальные модели, в том числе модели эмбеддингов, у вас уже настроены, но поскольку они в моем случае работают на базе Ollama, Copilot в режиме QA посчитал, что эта семантическая (смысловая) связь важна, и он прав. Мне кажется, что это один из самых наглядных примеров использования режима Vault QA.
Сразу оговорюсь, далеко не всегда удается получить такие показательно правильные результаты в запросах о связывании заметок. Если у вас не получилось, попробуйте выполнить задачу по шагам несколькими запросами:
- Выдели основные идеи, которые описаны в заметке [[НАЗВАНИЕ]]
- Найди самые подходящие заметки по теме ПУНКТ_1 из предыдущего списка
- и так далее до конца списка идей.
Подобные запросы можно использовать не только для нахождения связанных по смыслу заметок, но и, например, для более глубокого погружения в тему. Или для поиска вариантов заметок, которых нет, но которые нужно было бы создать. Здесь множество вариантов использования.
Заключение
Итак, мы рассмотрели использование режимов QA в Obsidian Copilot, которые представляют собой мощный инструмент для работы с заметками и поиска информации. Режимы QA, основанные на эмбеддингах и методе RAG, позволяют эффективно извлекать и обрабатывать заметки и данные по смыслу из хранилища Obsidian, что открывает новые горизонты в использовании Obsidian Copilot.
Важно отметить, что успешное использование режимов QA зависит от качества и структуры самих заметок. Чем более подробно и самодостаточно оформлены записи, тем лучше будет результат. Режим Long Note QA подходит для работы с большими текстами, в то время как Vault QA позволяет осуществлять семантический поиск по всему хранилищу, что открывает новые возможности для анализа и синтеза информации.
Таким образом, использование режимов QA в вашей практике работы с Obsidian может значительно повысить эффективность поиска и обработки информации, а также улучшить качество ваших заметок. Рекомендуется экспериментировать с различными подходами и методами, чтобы максимально раскрыть потенциал этого инструмента и адаптировать его под свои нужды.
«Существует два вида поиска: лексический (словарный), который представляет собой обычный поиск в Obsidian и, к примеру, OmniSearch, и семантический поиск, который осуществляется по смыслу. Они не пересекаются.» — как переключаются эти режимы?
Никак. Это просто разные механизмы поиска.
Лексический поиск (поиск по словам) используется в обычном поиске Obsidian и в OmniSearch (к примеру).
Семантический поиск (поиск по схожему смыслу) используется в RAG, то есть отборе эмбеддингов в режимах QA Copilot.
Они никак не переключаются и не пересекаются. Просто разные механизмы используются в разных инструментах.
Грубо говоря, если мне нужно найти ВСЕ заметки со словом «RAG», я буду искать через OmniSearch. Если мне нужно найти заметки по смыслу «Как работают эмбеддинги в Копилот?», я этот вопрос задам Копилоту в режиме QA. Далеко не факт, что он найдет ВСЕ ЗАМЕТКИ, он возьмет столько, сколько указано в Max Sources, но они будут подходить по смыслу. Например, в моем случае, он дал следующее (я пропускаю длинный и подробный ответ Копилота, оставляю только источники информации):
— Векторное хранилище
— nomic-embed-text
— Проверка эмбеддингов Ollama 2024-09-05
— Настройка и использование режимов QA в Obsidian Copilot
И он прав в своём выборе. Вот это и есть семантический поиск.
подключил гпт. сделал индексацию. спрашиваю «что произошло 26 сентября», но он никак не может найти заметку с этой датой. где может быть ошибка?
Посмотрите, какие заметки выбраны в качестве источников информации. Это внизу ответа, раздел Sources. Там точно все заметки подходят по смыслу? Если там полный разброд и шатания (то есть, смысловой связи нет вообще), то у вас совершенно неподходящая модель эмбеддингов. Убедитесь, что ваша модель поддерживает русский язык (или используйте bge-3m, она точно поддерживает).
Далее, убедитесь, что хранилище действительно проиндексировано корректно. Выполните команду (Ctrl + P) «Count total tokens in your vault» и посмотрите результат. Токен — примерно пол слова, то есть их должно быть хорошо больше чем общее число слов в вашем Obsidian. Например, у меня их больше 2,7 миллиона). Если их подозрительно мало, у вас проблемы с индексацией хранилища.
Ну и наконец, попробуйте переформулировать запрос по другому.
Если брать мой Obsidian за образец (по крайней мере, у меня модель эмбеддингов с поддержкой русского, полная индексация практически без ошибок и достаточно полные заметки дневника), то вот примерный вид ответа на такой запрос:
Что случилось 26 сентября?
26 сентября 2023 года была запланирована задача по размещению информации о конференции UIC dev 2023 на сайте. Эта задача была помечена как «Позже» и имела срок выполнения до 26 сентября. Таким образом, 26 сентября было важным днем для выполнения этой задачи, связанной с конференцией, которая состоялась 30 сентября в Ижевске.
Sources:
— Конференция UIC dev 2023
— 2023-09-25
— Разные мероприятия и конференции
— Планерка 2023-12-25
Обратите внимание, несмотря на то, что я просил 26 сентября, не указывая год, он в качестве источников взял заметки за другие даты.
Но ответ достаточно сильно изменился когда я задал запрос «Обобщи мои заметки на дату 26 сентября 2024«. Ответ не привожу, там много чувствительной и несколько личной информации.
Попробуйте.
спасибо за ответы!
1. обновил копилот
2. прикрутил для ембедингов модель бге в оламе
3. количество токенов показывает примерно 1,5 млн
но
в режиме vault qa не работает
An unexpected error occurred while indexing
the vault. Please check the console for
details.
An unexpected error occurred while indexing the vault. Please check the console for details.
А в консоли что пишет? (Ctrl+Shift+I)
консоль не вызывается
макбук
Чтобы открыть консоль DevTools на macOS, нужно зажать клавиши «cmd + Shift + I».
См. https://forum.obsidian.md/t/how-to-access-the-console/16703
да, конечно, я нашел в инструкции, что их надо нажать, однако ничего не происходит )
См. предыдущий ответ и форум Obsidian