Необходимость CRM: выживание в сегодняшней бизнес-реальности

Многие предприниматели до сих пор воспринимают CRM-систему как «программку для отдела продаж» — этакую продвинутую записную книжку для учета клиентов. Это фундаментальное и зачастую фатальное заблуждение. Как очень метко заметил Алексей Горностаев, бизнес сегодня умирает не от налогов, конкуренции или кризиса. Он погибает от внутреннего хаоса: отсутствия отлаженных процессов и современной CRM как средства отслеживания коммуникаций с клиентом. CRM — это не форма учета, а форма жизни бизнеса. Это фундамент, который позволяет фиксировать каждый контакт, выполнять каждое обещание и не терять ни одного обращения. Внедрение правильной CRM-системы — это не вопрос удобства, а базовое условие для выживания и развития в современных реалиях, где клиент не обязан ждать, напоминать о себе и мириться с беспорядком.

Если в крупных компаниях эти проблемы, как правило, решены за счет устоявшихся бизнес-процессов, то у малого бизнеса (ИП, самозанятых, селлеров на маркетплейсах) часто царит операционный хаос.

Но успех управления отношениями с клиентами в бизнесе складывается из двух очень важных факторов:

1. Выявленные и формализованные бизнес-процессы и регламенты.
2. Удобная в использовании CRM, реализующая обработку данных о клиентах.

Суть высказывания выше довольно проста. Первое: чтобы что-то учитывать (а именно это и делает CRM с данными о клиентах), нужно самому понимать, как именно в нашем конкретном бизнесе происходит взаимодействие с клиентом. Это и есть формализация бизнес-процессов. Второе: CRM должна помогать, а не мешать реализовать эти бизнес-процессы. Точка.

Сегодня на рынке полно CRM для малого и среднего бизнеса, но все ли они удовлетворяют этим принципам? Например, многие CRM тут же начинают предлагать или откровенно навязывать коллтрекинг, но чисто телефонные коммуникации становятся в последнее время всё менее популярными. Так нужна ли вам эта функция? Или, наоборот, у вас на сайте есть форма заказа и заявки, но точно ли на 100% что она попадает в CRM с нужными для обработки данными?

Муки выбора CRM

Если просто поискать что-то типа «недорогая или бесплатная CRM для малого бизнеса«, вы даже не увидите результатов поиска, потому что всё будет завалено рекламными предложениями, обещающими золотые горы прямо сейчас. Но вы когда-нибудь чувствовали себя так, будто пытаетесь забить гвоздь микроскопом? Примерно такие же ощущения испытывает владелец малого бизнеса, когда открывает демо-версию «Битрикс24» или amoCRM. Сотни кнопок, десятки вкладок, и тарифы!, и обещания «полной автоматизации всего и вся», после которых хочется автоматизировать только одно — закрытие этой вкладки.

Знакомая ситуация? А нам-то нужно было всего-навсего навести порядок в клиентах, перестать терять заявки из мессенджеров и не держать в голове, кому и когда нужно позвонить. А вместо этого вам предлагают построить на своем компьютере филиал Центра управления полетами в Роскосмосе. И вот вы сидите, смотрите на этот «космический корабль» и думаете: «А может, ну его? Excel-табличка ведь тоже работает… вроде бы«

И еще один очень немаловажный момент: персональные данные и 152-ФЗ. При использовании любой облачной CRM (модель SaaS) вы доверяете ядро своего бизнеса — клиентскую базу — сторонней компании. Все данные, включая имена, телефоны и историю сделок, физически хранятся на ее серверах. Это порождает несколько конкретных, а не гипотетических рисков. Давайте отметим:

• Ваша клиентская база вам не принадлежит в полной мере. Вы лишь арендуете доступ к ней. И в любой момент времени ваш аккаунт может быть просто заблокирован (забыли оплатить, нарушили какие-то их правила, компания закрылась и т. п.).
• Перенести данные из одной CRM в другую — сложная и дорогая задача. Провайдер это знает и может безнаказанно повышать тарифы, зная, что вы уже никуда не денетесь.
• Вы не контролируете (да и вообще не знаете!), как именно защищены серверы и службы провайдера CRM. Если взломают не вас, а вашего CRM-провайдера, вся ваша клиентская база (контакты, история покупок, суммы сделок) может быть украдена и продана конкурентам или мошенникам. Репутационный ущерб и прямые финансовые потери в этом случае несете вы. Не бывает такого? Ну-ну…

Сегодня мы поговорим о «темной лошадке» в мире CRM — Jetpack CRM, очень простой и бесплатной CRM, но решающей начальные проблемы малого бизнеса.

Что еще за Jetpack CRM?

Это бесплатный плагин для вашего сайта на WordPress от компании Automattic (собственно, авторов самого WordPress). Это уже внушает определенное доверие.

У него есть две ключевые особенности, которые делают его особенным для российского малого бизнеса.

Особенность №1: Ваши данные — ваши правила

Большинство CRM-систем работают по модели «облака». Это удобно, но все ваши клиенты, сделки и переписки хранятся где-то на чужих серверах. С Jetpack CRM все иначе. Это self-hosted решение.

Говоря по-человечески, все данные лежат на вашем хостинге или на вашем сервере, в базе данных вашего сайта.

• Полный контроль. Никто не заблокирует вам доступ к вашей базе, не поднимет внезапно цены. Ваш дом — ваши правила.
• Безопасность и ФЗ-152. Вопрос хранения персональных данных россиян на территории РФ решается автоматически, если ваш сервер и так  расположен в России. Никаких головных болей с законом. В любой момент времени данные могут быть удалены по первому требованию со стороны их обладателя.

Особенность №2: Бесплатно, но не сыр в мышеловке

Основной функционал Jetpack CRM полностью бесплатный. И это не демо-версия на 14 дней. Вы ставите плагин на свой сайт WordPress и пользуетесь им столько, сколько нужно.

Конечно, у него есть платные расширения (они в основном — для западного сегмента) или, возможно, придется автоматизировать свои пожелания усилиями программистов. Но базовое ядро, которое закрывает львиную долю потребностей малого бизнеса, не стоит ни копейки. Это как шведский стол: берите то, что нужно сейчас, а за деликатесами вернетесь потом, если захотите.

Что вы получаете «из коробки» бесплатно?

Вот основные функциональные особенности Jetpack CRM.

Учет лидов и клиентов

• Учет клиентов. Удобная картотека, где можно хранить всю информацию о клиентах, добавлять теги, заметки и видеть всю историю взаимодействий.
• Воронка продаж. Есть простая и понятная воронка. Вы можете создавать этапы сделок и перетаскивать их, при этом наблюдая на какой стадии находится каждый клиент.

Режим B2B для работы с компаниями

Режим B2B. Этот режим позволяет отдельно вести юридических контрагентов и контакты в них. Например, у ООО «Ромашка» мы знаем трех контактов: Пупкин В., Сумкин Ф. и Морковкина М. CRM позволяет выставлять счета на ООО «Ромашка» и вести отдельный учет контактов с различными сотрудниками этого ООО.

Коммерческие предложения и согласования сметы

Коммерческие предложения и согласования. Создавайте и отправляйте КП, сметы, предложения своим клиентам прямо из админки WordPress. Можно настроить шаблоны писем и вложенных в них PDF. Клиент может принять ваши предложения или отказать в них.

За счет реализации так называемого Клиентского портала ваш контакт, получив такое предложение, может очень легко, буквально одним кликом, принять или отклонить предложение уже без вашего участия. Более того, это приравнивается к использованию простой электронной подписи (ПЭП) и по российским законам (если это отражено в вашем договоре с клиентом) приравнивается к собственноручной подписи со стороны клиента и может иметь юридическую силу.

Выставление и учет счетов

Счета клиентам. Выставляйте счета своим клиентам и отслеживайте их оплату. Счета могут отправляться сразу на почту, или их можно просто скачать в виде красивого PDF-файла и отправить в любой мессенджер.

Дизайн и внешний вид счета полностью настраиваемые и могут быть приведены к общему фирменному стилю компании. Это очень удобная функция для малого и среднего бизнеса, связанного с любыми услугами.

Само собой, все статусы счетов (оплачен, не оплачен) отслеживаются.

Учет оплат

Финансовый учет. Базовое отслеживание транзакций. Кто, когда и сколько вам заплатил.

Интеграция с WooCommerce

Полная и прозрачная интеграция с WooCommerce. Все клиенты, все заказы, вся предыдущая история вашего магазина на базе WooCommerce полностью синхронизирована с CRM.

Но CRM может работать и без WooCommerce, то есть он не является обязательным.

Доступ и права сотрудников

Гибкий доступ сотрудников к CRM. Вы всегда решаете, какой сотрудник к каким функциям CRM имеет доступ. Сотрудники авторизуются своими учетными записями WordPress.

А это значит, что может использоваться любой современный способ надежной авторизации, включая беспарольную авторизацию по ключам доступа (passkeys). Это может быть и биометрический вход на мобильных устройствах, Windows Hello и др., когда вы просто прикладываете палец к сканеру в ноутбуке (смотрите в камеру или вводите ПИН в Windows) для входа на сайт.

Забудьте про пароли на желтых бумажках на мониторе у тети Клавы из бухгалтерии! Это не просто камешек в огород слонов типа «Битрикс» или amoCRM. Это булыжник им в окно! На ноябрь 2025 года ни «Битрикс24», ни amoCRM, ни RetailCRM официально не поддерживают авторизацию через passkeys — современные методы входа без пароля, работающие на базе WebAuthn/Passkey-устройств. Во всех системах реализована двухфакторная аутентификация (2FA) через одноразовые коды, SMS, e-mail или мобильное приложение, но до современных методов они еще не доросли.

Задачи и напоминания для команды

Задачи и напоминания для сотрудников позволяют не забыть позвонить клиенту, оформить счет и многое другое.

По сути, Jetpack CRM — это крепкая база, чтобы навести порядок в своих контактах, продажах и перестать всё держать в голове.

Сравнение в лоб: Jetpack CRM vs. Битрикс24 vs. amoCRM

Чтобы понять место Jetpack CRM в мире, давайте сравним её с тяжеловесами.

Что в итоге? Это не соревнование, кто лучше. Это вопрос, какой инструмент подходит именно вам. Если вам нужен комбайн с тысячей функций и у вас есть бюджет — «Битрикс24» ваш выбор. Если вы сфокусированы на отделе продаж и коммуникациях —amoCRM. А если у вас сайт на WordPress, ограниченный бюджет и вы цените простоту и контроль — Jetpack CRM становится очевидным фаворитом.

Ложка дегтя: Ограничения для российского рынка

Давайте по-честному: идеальных решений не бывает. У Jetpack CRM есть свои минусы, особенно для нашего рынка.

• На момент написания этой статьи у Jetpack CRM нет локализации на русский язык. Но это не проблема: наша компания достаточно давно выполнила перевод (локализацию) CRM на великий и могучий, и мы бесплатно по запросу предоставим вам файлы локализации, после чего CRM будет полностью на русском. Но из коробки она английская.
• Интеграции с мессенджерами. Готовой интеграции с WhatsApp и Telegram «из коробки» нет. Это, пожалуй, главный минус. Решить можно, но через сторонние сервисы-коннекторы (типа Zapier или n8n), что требует дополнительных настроек и, возможно, денег.
• Интеграции с российскими сервисами. Оплаты, выполненные в WooCommerce через любые платежные сервисы в России (ЮKassa, «Робокасса» и т. п.), Jetpack CRM зафиксирует без проблем, но интеграции со счетами в 1С или другой бухгалтерии нет. Всё это потребует помощи программиста, который напишет кастомное решение через API.
• Масштабируемость. Это решение для малого бизнеса. Если у вас в планах вырасти до размеров «Газпрома», в какой-то момент придется переезжать.

Вердикт: кому идеально подойдет Jetpack CRM?

Несмотря на ограничения, есть целые пласты бизнеса, для которых Jetpack CRM — это просто находка.

• Фрилансеры и ИП. Идеально для учета клиентов и выставления счетов. Просто, понятно и бесплатно.
• Небольшие компании, предлагающие услуги (ремонт, клининг, ландшафтный дизайн, электрика, сантехника и подобное). Гибкие счета и сметы делают Jetpack CRM просто незаменимой.
• Небольшие агентства и студии, у которых сайт и так на WordPress. Зачем плодить сущности?
• Интернет-магазины на WooCommerce. Есть готовая интеграция, которая позволяет видеть всех клиентов из магазина прямо в CRM.
• Онлайн-школы и инфобизнес для базового управления клиентами.
• Все, кто ищет «простую CRM для начинающих» и не хочет разбираться в сложных системах.

Jetpack CRM — это не «убийца» «Битрикс24». Это как швейцарский нож против ящика с инструментами. Он не сделает всё на свете, но то, что делает, он делает хорошо, просто и лежит в вашем кармане (или в данном случае, на вашем сайте). Это достаточно мощный, бесплатный и очень недооцененный инструмент для тех, кто ценит простоту, экономию и полный контроль над своими данными.

Финальный вердикт: если ваш бизнес живет на WordPress, вы ищете свою первую CRM и готовы мириться с отсутствием готовых российских интеграций (или решать эти вопросы точечно с помощью разработчика), то Jetpack CRM — это, возможно, лучший выбор для старта. Он поможет навести порядок в делах, не разорив вас и не сломав вам мозг. А это, согласитесь, уже немало.

Запись Легкая CRM для малого бизнеса — обзор Jetpack CRM впервые появилась Иван Никитин и партнеры.

Что нам понадобится:

1. Сайт на WordPress с установленными формами Contact Form 7. В моем случае, это сайт seodogs.ru, где используются две формы CF7.
2. Плагин WP Webhooks (или аналог) — он позволит отправить данные форм в n8n.
3. Аккаунт Telegram и Telegram-бот (его можно создать через @BotFather).
4. Ваш Telegram Chat ID, получить можно в @getmyid_bot
5. Аккаунт в n8n (облако или локально). Я использую виртуальный сервер с предустановленным n8n от Бегета.

Шаг 1. Создайте Webhook в n8n

Перейдите в свой n8n.

Создайте новый рабочий процесс (Workflow) и добавьте Webhook-ноду. Нажмите «+» в верхнем левом углу (или нажмите красную кнопку Create Workflow) → выберите «Webhook»

Нажмите «+» → выберите «Webhook».

Настройте Webhook-ноду:

• HTTP Method: POST
• Path: укажите, например, cf7 (путь вы задаете сами, главное, чтобы он был уникален.)
• Включите галочку «Respond immediately» (иначе форма может «зависнуть»)

Скопируйте Production URL, он будет иметь вид:

https://n8n.вашдомен/webhook/cf7

Сохраните Workflow и активируйте его “Active”.

Шаг 2. Подключение Contact Form 7 к n8n

1. Перейдите в админку WordPress.
   
2. Установите и активируйте плагин WP Webhooks:
   В админке: Плагины → Добавить → WP Webhooks
   
3. Перейдите: WP Webhooks → Send Data
   
4. Нажмите “Add Webhook URL”

• Название: n8n (можно указать любое имя, важно, чтобы вы различали, какой Webhook куда отправляет данные).
• URL: вставьте Production URL из n8n.

Сохраните и проверьте — отправьте форму CF7 на сайте

? Если в n8n появятся данные → значит, связь работает!

Шаг 3. Идентификация форм (если их несколько)

Если у вас на сайте несколько форм, добавьте в каждую из них скрытое поле. На моем сайте всего две формы обратной связи. Чтобы n8n мог отличать формы form1 и form2, я передаю ID форм в самих формах CF7 с помощью скрытого поля.

Пример для формы 1:

[hidden form-id "form1"]

Пример для формы 2:

[hidden form-id "form2"]

Шаг 4. Добавляем условие — определить, из какой формы пришли данные.

На этом этапе мы настраиваем проверку содержимого заявки, чтобы понять, из какой именно формы CF7 пришли данные — form1, form2 и т.д.

После ноды Webhook добавьте IF-ноду для проверки, из какой формы CF7 пришли данные.

1-я IF-нода (проверка form1):

Настройте условие в IF-ноде. Перейдите во вкладку Parameters → Conditions.

Включите режим выражения Expression, в поле Value 1 вставьте

{{ $json.body.form_submit_data['form-id'] }}

Operation: is equal to

Value 2: form1

IF-нода проверяет form1, и если это не она, сработает ветка false.

2-я IF-нода (проверка form2):

Если заявка приходит не из form1, n8n передаёт её во вторую IF-ноду, которая проверяет не из form2 ли пришла заявка:

Настройки второй If-ноды аналогичны первой. В поле Value 1 вставьте

{{ $json.body.form_submit_data['form-id'] }}

Operation: is equal to

Value 2: form2

Шаг 5. Создаем Telegram-бота

Telegram не разрешает сторонним сервисам (например, n8n) писать вам напрямую —
поэтому Вы создаёте бота, через которого n8n будет отправлять уведомления.

1. Перейдите в Telegram и найдите @BotFather
2. Отправьте команду: /newbot
3. Дайте имя и username боту (например: seodogs_cf7_bot — любое разрешенное имя).
4. BotFather пришлёт вам токен (пример: 123456:ABC-DEF...)
5. Скопируйте токен — он потребуется в n8n в следующем шаге.
6. Активируйте бота — нажмите Start или напишите /start . По правилам Telegram:
   Бот не сможет отправить Вам сообщение, пока Вы не начнёте с ним диалог
   

Шаг 6. Telegram Node: отправка сообщения — Отправка сообщения в Telegram из n8n

Если срабатывает условие TRUE при проверке форм, нужно подключить Telegram-ноду (Send a text message) к TRUE-выходу каждой IF-ноды.

В n8n нажмите «+» → выберите Telegram

Выберите “Send Message”

Credentials: нажмите «Create New credential» → вставьте токен, который выдал Вам @BotFather. Нажмите Connect.

Chat ID:

Если Вы отправляете сообщение себе — используйте свой Chat ID. Узнать свой ID можно с помощью @getmyid_bot →этот бот пришлёт ваш ID

Text – текст сообщения: я перечислила все поля обеих форм в сообщении для телеграма.

Новая заявка с сайта Seodogs
{{ $json.body.form_submit_data['tel-363'] }}
{{ $json.body.form_submit_data['text-954'] }}
{{ $json.body.form_submit_data['email-954'] }}
{{ $json.body.form_submit_data['textarea-675'] }}

Остался последний шаг — протестируйте!

Заполните форму на сайте и получите мгновенное сообщение в Telegram. Всё работает!))

Запись Настройка отправки заявок из Contact Form 7 в Telegram через n8n (пошаговая инструкция) впервые появилась Иван Никитин и партнеры.

Вступление

Сегодня (25.02.2025) мне посчастливилось стать участником закрытой конференции Яндекс Рекламы, которая проходила в бизнес-центре «Аврора» (Садовническая набережная, 77с1, зал «Компьютерный клуб»). Хочу поделиться ключевыми моментами, наблюдениями и выводами, которые могут быть полезны для бизнеса и специалистов в digital-сфере.

О мероприятии

Конференция собрала около 20-30 участников — преимущественно владельцев бизнеса и маркетологов, уже работающих с персональными менеджерами Яндекса. Организация была на высоте: удобный зал с качественным звуком, фуршетные столики для неформального общения и плотный график выступлений.

Спикеры

5 экспертов, каждый представлял отдельный сервис Яндекса для привлечения клиентов. Все они — персональные менеджеры (ПМ) платформы, которые курируют крупных рекламодателей. Интересно, что в зале также присутствовали 10-15 других ПМ, чей офис расположен в этом же БЦ.

Ключевые темы

1. Единая Performance-кампания (ЕПК)
   Основной акцент спикеров был на ЕПК — инструменте, объединяющем рекламу в Поиске, РСЯ, YouTube и других площадках Яндекс.Рекламы в одну стратегию. Упомянули, что для подключения сервиса требуется значительный бюджет — стартовый порог может превышать 200 тыс. рублей.
2. Роль персональных менеджеров
   ПМ — это бесплатные эксперты Яндекса, которые помогают клиентам с бюджетом от 200 тыс. рублей в месяц оптимизировать рекламные кампании. Их задача — проектировать стратегии, тестировать гипотезы и масштабировать успешные решения. Как правило, у одного клиента одновременно запущено несколько кампаний.

1. Был проведен обзор популярности Яндекса и разнообразие сервисов Яндекса.
2. Рассказывалось об Яндекс Персональных Менеджерах.
3. Тестировании Рекламных площадок.
4. Performance Реклама.
5. Обсуждались Яндекс Карты, Яндекс Навигаторы, Яндекс Навигация, Яндекс Маршруты…
6. Были ответы на вопросы.

Личные впечатления

• Атмосфера: Менеджеры Яндекса активно поддерживали клиентов, подчеркивая индивидуальный подход. Многие участники — представители B2B и B2C сегментов — уже добились значимых результатов с ЕПК.
• Забавный момент: Меня пригласила менеджер из Click.ru (партнерской сети Яндекса), но из-за ее отсутствия я некоторое время слышал предположения, что представляю fashion-индустрию ?.

Итоги и выводы

1. Яндекс делает ставку на комплексные решения. ЕПК и интеграция сервисов (Карты, Навигатор) позволяют охватить аудиторию на всех этапах воронки.
2. Персональные менеджеры — ключевое преимущество. Для крупных клиентов это не просто поддержка, а полноценный аутсорс рекламной стратегии.
3. Высокий порог входа. Большинство инструментов рассчитаны на бизнес с бюджетом от 200–500 тыс. рублей в месяц.

Бонус для читателей

Делюсь 5 докладами-презентациями с Конференции Яндекс Рекламы 25.02.25г. собранными в общий единый PDF.

Фото с конференции Яндекс.Реклама 2025

Запись Конференция Яндекс Рекламы 2025 впервые появилась Иван Никитин и партнеры.

Конференция All in Top, основанная в 2010 году Василием Ткачевым, стала барометром цифровых трансформаций для рунета. В 2025 году мероприятие собрало рекордное количество участников, включая представителей Яндекс и стартапов в области генеративного ИИ. Главной темой стал переход от «SEO 2.0» (эпохи семантического ядра и ссылочной массы) к «SEO 3.0», где доминируют нейросети-трансформеры, способные анализировать интенты пользователей в реальном времени.

• Смерть традиционных метрик: Никитин подчеркнул, что традиционные SEO-метрики, такие, как позиции в поисковой выдаче и количество ссылок, теряют свою актуальность. На первое место выходит динамический контент, адаптирующийся под индивидуальные поведенческие паттерны пользователей.
• Нейрооптимизация: Алгоритмы теперь оценивают не только техническое совершенство сайта, но и его способность «резонировать» с ИИ-моделью, имитируя взаимодействие с живым человеком. Это подразумевает создание контента, вызывающего эмоциональный отклик и удовлетворяющего скрытые потребности пользователей.
• Реальные кейсы. Примеры, приведённые Иваном Никитиным, демонстрируют, как правильно распределять бюджеты на продвижение, выбирать стратегии и оценивать результаты. Эти кейсы стали настоящим гидом для специалистов, стремящихся идти в ногу со временем.

• Тренды 2026 года:
  • Поиск без запросов: Развитие систем, предугадывающих потребности пользователя до ввода текста (например, пилотный проект Google «Silent Search»). Это означает, что SEO-специалистам необходимо будет предвидеть потребности пользователей и создавать контент, который будет соответствовать их интересам еще до того, как они сформулируют свой запрос.
  • Этика ИИ: Уделение внимания регулированию нейросетей и обсуждению рисков манипуляций через нейростимуляцию контента. Вопросы этики и ответственности при использовании ИИ в SEO становятся все более актуальными.

Участники конференции оценили высокий уровень практической направленности и ясность изложения. В социальных сетях и на специализированных форумах эксперты отмечают, что:

Многие специалисты подчеркнули, что рекомендации Ивана Никитина актуальны для быстрого реагирования на изменения алгоритмов поисковых систем.

Доклад был насыщенным и конкретным, без избыточных теоретических рассуждений.

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

Запись SEO 3.0: Искусственный интеллект кардинально меняет правила игры в поисковой оптимизации. Анализ ключевых трендов с конференции All in Top 2025 впервые появилась Иван Никитин и партнеры.

Интернет как феномен XXI века тоже не исключение. Как и поиск в интернете, так и всё, что с ним связано — поисковая оптимизация сайтов, реклама в поиске и прочее. Целая индустрия, существующая последние двадцать пять лет полностью зависит от простого факта: есть огромное количество информационных ресурсов, которым нужны посетители и клиенты. И есть огромное количество людей, которые хотели бы быстро получить доступ к требуемой информации.

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

Поиск v0. Рождение

Когда только-только стали появляться сайты, тем более коммерческие сайты, сразу возникла задача донести до потенциальных клиентов информацию о них. Появились списки, каталоги сайтов, в которых они были просто перечислены в алфавитном или ином виде.

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

Но такой сценарий работает если сайтов (записей в списке) сотни или тысячи, но не сотни тысяч и уж тем более не миллионы. Понятно что практически сразу появилась необходимость поиска в списке сайтов. И интернет поиск родился.

Поиск v1.0. Детство

В середине и конце 90х годов появились действительно удобные системы поиска в интернете — AltaVista и позже Google на западе, Рамблер и Яндекс у нас. И это стало просто открытием для рядовых пользователей Сети. Просто введи ключевые слова и сразу получи готовый список сайтов, которые тебе нужны.

Пользователи в своей ежедневной практике начали думать категориями ключевых слов и, надо сказать, эта тенденция продолжается по сей день. Что пользователь наберет в строке поиске? «Купить холодильник недорого Москва» . Наш пользователь в обычной жизни так не говорит, но когда он открывает поисковик, он начинает так думать! Это и есть тот самый устоявшийся ментальный шаблон, паттерн поведения. Именно эти шаблоны в конечном итоге и определяют в итоге функции поисковых систем в целом. Ведь для конечного пользователя удобным будет не то что совершенно, а то, что более привычно, что соответствует его шаблонам поведения.

Поисковые системы в то время работали крайне примитивно: поиск по ключевым словам на страницах и анализ ссылок, ведущих на эти страницы.

Вот здесь и появилось SEO — поисковая оптимизация сайтов, ее первая эпоха.

Определение SEO 1.0

SEO 1.0 — это оптимизация ключевых слов и ссылок для повышения позиций в поисковой выдаче, представляющей собой список сайтов.

Это было золотое время! Детство всегда кажется счастливым, деревья такие высокие, а небо такое голубое. Обычные проблемы решаются сами собой (точнее родителями, но мы их не замечаем), а каждый день открывает нам что-то новое. И если это новое интересно и полезно нам, то мы с той самой детской непосредственностью приписываем это себе в актив, что опять же повышает собственную значимость в глазах ребенка. Я лично в детстве делал от трех до пяти гениальных изобретений в день, правда позже оказывалось, что это а) всем давно известно, и б) не очень то и нужно.

Точно так же и в SEO: подобрал и написал самые популярные сочетания ключевых слов в TITLE и на странице, поставил сотню, другую ссылок на нужную страницу с этими же словами и — вуаля! Сайт в ТОП, заказчик доволен, клиенты на сайте идут толпой, а SEO-шник купается в заказах.

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

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

Это важно, интернет поиск в то время не решал проблемы пользователей, он лишь давал список ссылок, которые могли помочь в решении этой проблемы.

Однако детство не может продолжаться вечно, и оно рано или поздно станет юностью.

Поиск v2.0. Юность

Юность в поиске наступила примерно в середине 2000х. Эта эпоха характеризуется значительными изменениями в поисковых машинах интернета, а именно:

• Поиск не только по ключевым словам и ссылкам. Поисковики начинают учитывать множество других факторов, которые прямого отношения к словам «Купить холодильник» не имеет — это и географическое расположение пользователя, и поведение пользователей на странице поисковой машины, и предыдущая история пользователя.
• Поисковики начинают пытаться отвечать на вопрос пользователя. Они предлагают ему готовые варианты решения проблемы в виде рекламных объявлений, точек на карте, расширенные ответы, выдача товарных карточек в магазинах.

Конечно же, качество интернет поиска с новым факторами выросло, а работы SEO-шникам прибавилось, ведь к просто манипуляциям словами и ссылками добавился сложный процесс оптимизации пользовательского опыта или UX (User Experience) и интерфейса взаимодействия или UI (User Interface), то есть эргономики сайта.

Определение SEO 2.0

SEO 2.0 дополняет SEO 1.0, и является оптимизацией поведенческих факторов, техническую оптимизацию (UI), микроданные документов и общую оптимизацию пользовательского опыта (UX). Поисковая выдача становится разнообразнее, включая сниппеты и рекламу, а фокус смещается с ключевых слов на UX.

В эту эпоху SEO значительно усложнилось, сам процесс оптимизации стал сложным поиском компромиссов во всём.

Это и как писать контент, короткие страницы или длинные простыни, ну и конечно же священная корова — «продающие тексты». Что включать в эти тексты и как сделать их уникальными?

Как улучшить структуру и дизайн сайта, если заказчик упирается и видит это всё по своему? Как обосновать эти достаточно объемные работы, если точных гарантий результата нет?

Как привести пользователей на страницу, чтобы поисковики зафиксировали их качественное поведение? Как накрутить ПФ в выдаче по тем или иным запросам? Как выбирать запросы? И прочее, прочее, прочее.

Собственно то, что делается сейчас большинством специалистов и агентств, это и есть SEO 2.0.

Но давайте вернемся к пользователю. Сначала пользователи не приняли изменения поисковых машин. Вспомните свое же поведение лет пятнадцать назад — я по рекламе в поиске не щелкаю, сразу ищу результаты выдачи! Было такое?

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

Зато что мы видим сейчас?

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

Но что осталось неизменным в этой схеме, так это необходимость перехода на другой сайт! Не обязательно непосредственно на сайт магазина или бизнеса, это могут быть и маркетплейсы, карточки бизнеса или услуги, но мы все равно уходим от результата на какой-то ресурс, которой может решить проблему.

Это важно, поисковики помимо выдачи списка ссылок стали делать первые попытки решения проблемы, и это привело к изменению шаблонов поведения пользователей и их интеграции в повседневный опыт:

• Сегодня мы не покупаем на сайтах, а сразу идём в маркетплейсы.
• Мы не бронируем гостиницы на сайтах, а пользуемся специализированными сервисами.
• Мы не вызываем такси по телефону с сайтов…

Само наше представление о получении услуг в интернете изменилось!

Ключевым моментом здесь, на мой взгляд, является переход ответа поисковика от «где можно найти решение» к ответу «как можно решить мою задачу«, что закономерно привело к интеграции такой функции в метальный шаблон и изменению самого поведения пользователя. И именно это изменение толкает нас к следующему шагу, к следующей эпохе поиска.

Поиск v3.0. Зрелость

Пользователи уже не ищут сайты в интернете, сайты неинтересны им! Пользователи ищут как решить свою задачу и по общему счету им, пользователям, всё равно кто и как поможет в этом решении.

Более того, переход на другие сайты для пользователя некомфортен! И это объяснимо всё теми же ментальными шаблонами. Привычное для нас лучше удобного. А любой внешний сайт с другим интерфейсом для нас изначально непривычен, а значит всё начинается со стадий сопротивления и дезориентации. Знакомо?

Так зачем уходить из поисковой системы? Мы живем в эру генеративных нейросетей, а они легко могут обобщить и представить удобном виде любой большой объем данных. И не просто обобщить, а именно подсказать готовое решение проблемы пользователя.

Такие поисковики существуют уже какое-то время, например:

• Perplexity — поисковая система на базе генеративных нейросетей, работает с 2022 года.
• Яндекс Нейро — сервис для поиска информации в интернете на базе модели YandexGPT, работает с апреля 2024 года.
• SearchGPT — поисковая система на базе моделей OpenAI, анонсирована в июле 2024 года.
• Gemini 2.0 — генеративная модель, представленная Google в декабре 2024 года, и, как обещают, будет доступна в приложении чат-бота Gemini в январе 2025 года. Эта модель может вызывать для работы дополнительные инструменты, включая Google Search.

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

Но Perplexity это уже больше чат с нейросетью, чем поиск:

А вот здесь мы получили готовый ответ, который сразу решает поставленную задачу. Мне уже не нужно ничего открывать, никуда переходить, я могу сразу брать телефон и звонить. Что я и сделаю. Помните, выше мы отмечали, что пользователя не интересуют внешние сайты? Так вот это отличное подтверждение этого тезиса.

Итак, новая эпоха поисковой оптимизации уже наступила. Так что же такое SEO 3.0?

Определение SEO 3.0

SEO 3.0 — это оптимизация ресурсов для искусственного интеллекта и нейросетей, которые формируют законченный ответ и решение задачи пользователя. Фокус смещается с ключевых слов на семантическое понимание и полноту информации, а результаты поиска представляют собой готовые ответы, а не ссылки. SEO 3.0 тесно связано с контент-маркетингом.

Конечно же, это лишь первые шаги, но и они не могут не сказаться на SEO как процессе и поисковой оптимизации как бизнесе. Например, по словам руководителя SEO-отдела в компании INET Production, уже сейчас наблюдаются и колебания метрик трафика Яндекса и откровенные просадки в трафике. Эти изменения связаны с введением Нейро.

Если сравнить результаты, которые генерирует Нейро и результаты обычного поиска Яндекс, нетрудно увидеть, что они не совпадают. А это значит, что Нейро использует другие способы извлечения и анализа информации, нежели обычный поиск. И старые SEO методики уже не работают.

Но я не планирую в рамках этой статьи подробно погружаться в такое исследование, однако вот некоторые моменты, которые мне удалось проверить эксперементально:

• Полнота контента;
• Семантическая близость контента к вопросам пользователей;
• Наличие признаков авторитетности представленной информации;
• Готовые решения, примеры с объяснениями.

Прежде всего это полнота контента и его семантическая (смысловая) близость к проблеме пользователя, обычно сформулированной как вопрос или просьба. Под полнотой контента понимаются не столько хорошо нам знакомые портянки SEO-текстов, сколько значительно более глубоко проработанный материал. Не забываем, что этот контент анализируется нейросетью, а для неё абсолютно не важны ни плотность слов, ни тошнота, ни использование ключей. Но важен смысл текста, то есть семантика в своем исходном значении.

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

Итак, полнота и семантическая близость к запросу — это первостепенные факторы. Понятно почему хорошо работают описания примеров применения чего-то или описание решения. Еще бы, для нейросети это прямо готовая шпаргалка, по которой она может сгенерировать ответ.

Для информационных запросов очень полезными оказываются признаки авторитетности, например, признаки научной работы, характерный стиль научной публикации. К тому же можно добавить что отличным источником таких данных могут быть тексты книг, доступных в интернете. Ниже это будет показано на примере.

Таким образом, SEO 3.0 можно описать как:

• Изучение и глубокий анализ предметной области;
• Прогнозирование потребностей целевой аудитории и ожиданий, то есть методов их решения (маркетинг чистой воды!);
• Изучение конкурентного окружения, источников, которые сейчас используются нейросетями;
• Оптимизация контента, представления товаров или услуг с учётом особенностей механизмов извлечения данных нейросетями;
• Мониторинг влияния выполненных изменений на общую эффективность работы (ох как непросто!)

А вот визуальное представление информации особой роли не играет. Хоть просто текст прямо сплошным потоком (я пока не говорю про анализ изображений, а они тоже очень хорошо анализируются!). Более того, Perplexity и SearchGPT могут брать документы, например, PDF, доступные в интернете, для генерации ответа. Нейро пока такого не умеет, по крайней мере в моих экспериментах он откровенно засыпался на сложных вопросах, ответ на которые можно получить только из текста книг в PDF. А Perplexity легко отвечал на такие вопросы.

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

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

Заметьте, я получил сразу всё, и цены и возможность его купить.

Что характерно для такого пользовательского сценария, так это возможность продолжения диалога после ответа. Если в Нейро эта возможность не очень очевидна, то в Perplexity такое продолжение прямо поощряется.

Более того, в Perplexity всегда можно вернуться к любому прошлому диалогу и продолжить его, что называется с того же места. А это очень интересная функция для пользователя! Это реализация сценария: я помню что что-то подобное искал, но не помню какими словами. И теперь это легко восстанавливается.

Обратите внимание, в таком виде интернет-поиска переход на сайт-источник информации практически не нужен и, как правило, такой переход и не требуется. То есть, ваши сайты пользователю уже сейчас вообще не нужны. А это нас опять неуклонно ведет к следующей ступени развития…

А завтра?

За зрелостью обычно наступает старость. Не быстро, может даже незаметно, не в один день, но неуклонно и неотвратимо. Это закон природы и отменить его нельзя. А дальше — смерть.

Смотрите сами, если переходы на ваши сайты пользователю больше не нужны, то отсюда следует что:

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

И всё. Интернет-поиск в том виде, в котором мы его знаем, умрёт. А вместе с ним умрёт и SEO. Точнее оно окончательно сольётся с маркетингом, растворится в нем и вы с набежавшей слезой на уже плохо видящие глаза будете рассказывать своим внукам об анкорных ссылках, об оптимизации TITLE, о ключах в заголовках. На что внуки будут громко звать бабушку: «Ба, неси таблетки, дед опять свою пургу несёт!«

Но это будет не завтра, а чуть-чуть позже. Но завтра будет еще один, последний шажок нейросетей, который фактически станет последним гвоздем в гроб интернет-поиска и SEO. И имя ему — транзакции.

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

— Я собираюсь поехать в гости к дочери. Сколько сейчас стоит такси, сколько потребуется времени на дорогу?
— На текущий момент стоимость поездки из Королева до Люблино составляет 1200 рублей. Загруженность дорог средняя, ориентировочное время в пути 50 минут.
— Хорошо, закажи мне машину через 20 минут.
— Такси заказно, оплата картой, готовьтесь выйти через 20 минут, я оповещу Вас на телефоне, когда машина будет подана.

Вот это последнее действие и есть то самое отсутствующее сейчас звено. Звено цепи превращения интернет-поиска в личного агента, помощника и персонального ассистента. Который знает и ваши привычки, и любимый сорт кофе, и ваш календарь, и ваши контакты. И может не просто советовать, как сейчас, а помогать, выполняя ряд рутинных действий.

По словам Мустафы Сулеймана, генерального директора подразделения искусственного интеллекта Microsoft, виртуальные помощники (агенты) заменят браузеры и поисковые системы в течение трех, пяти лет. То есть направление развития очевидно — радикально упростить нашу повседневную работу, выполняя рутинные операции и действия средствами агента. Действия, включая поиск информации и общение данных как промежуточный шаг. А это окончательно уводит нас от традиционного пользовательского поиска.

То есть виртуальный помощник (агент) сделает всё сам, найдет, выберет и предложит готовое решение на ваше утверждение. Это касается всего — и покупки товаров, и заказ услуг, сбор сведений и обобщение данных, досуг, развлечения и всё, что нам обычно требуется. И мне как пользователю совершенно всё равно, где мой ассистент купит кофе Lavazza Oro, главное чтобы не дороже 800 рублей за банку. Мне всё равно как и на каких сайтах он найдёт новый холодильник или найдёт услуги мастера по ремонту стиральной машинки. Добро пожаловать в XXI век.

Запись SEO 3.0: Будущее поисковой оптимизации впервые появилась Иван Никитин и партнеры.

Всё сказанное в этой статье является исключительно личным мнением автора и не претендует на Истину В Последней Инстанции. Тем более такой Истины не существует.

Приложение Obsidian потрясает своими возможностями, и даже не столько функциями и «фишками», которые оно умеет, сколько открытиями для себя, к которым рано или поздно приходишь при активном использовании этой программы и накоплении в ней некоторого объема информации.

Содержание

В этой статье рассматриваются темы:

• Граф Obsidian
• Диалог с картотекой по Н. Луману
• Смысловые связи и MOC карточки
• Поиск в графе Obsidian
• Использование плагина Graph Analysis
• Использование методов анализа:
  • Индекс Адамик — Адар
  • Ошибки несмысловых ссылок
  • Коэффициент Жаккара
  • Лувенский метод
  • Поиск взаимных упоминаний
• Заключение и выводы

Граф Obsidian и умение готовить кошек

Одной из самых сильных сторон Obsidian являются ссылки и граф, который строится на их основании.

С одной стороны, граф Obsidian выглядит очень эффектно, особенно если его раскрасить по произвольным группам. Говорят, в Discord есть специальный канал, где пользователи хвастаются друг перед другом своими графами (я вот сейчас тоже хвастаюсь).

А с другой стороны что? А ничего! Раскрасили граф, ну может быть фильтры поставили и, как правило, на этом всё! Здесь для большинства пользователей граф Obsidian и заканчивается. Вот уже и Федоров пишет: «… в Evernote нет графов (говорят их значение переоценено) …«.

Позволю себе не согласиться, ведь неумение использовать граф не является показателем его бесполезности, точно как в анекдоте про неумение готовить кошек. Для меня граф Obsidian – это мощнейший инструмент для поиска ассоциаций и даже идей, в том числе и для этой статьи.

Диалог с картотекой

Говорят, что при наборе некой критической массы (400-500 заметок) с картотекой в Obsidian можно вести диалог, и она будет подсказывать множество того, что раньше упускалось из вида. И это правда, я сам почувствовал такой момент на собственном опыте, правда на несколько большем количестве заметок. Автор Zettelkasten, Никлас Луман называет это диалогом с картотекой (Kommunikation mit Zettelkästen — Luhmann, Niklas (1981) — это очень тяжелая для чтения и сложная статья, но вот ее хороший перевод).

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

Это очень важно. Ассоциативный поиск (графовый поиск, поиск по связям) ищет ассоциации между элементами вашей картотеки. Он очень отличается от лексического поиска (поиска по словам), и этот факт всегда нужно помнить: ассоциативный поиск не заменяет обычный, это просто другой инструмент.

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

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

Смысловые связи и MOC карточки

Связи, с одной стороны, пожалуй, самая простая вещь: пишешь заметку – поставь в ней ссылки на те термины или идеи, которые упоминаются или предполагаются в заметке. А с другой стороны, это самая сложная вещь – на что ставить ссылки, если карточек нет? Или они есть, но они очень общие, типа «Универ», «Дела», «Моя супер-пупер красивая хоумпейдж», и всё.

MOC-карточки! Связные карточки – вот ответ на этот вопрос! Всегда их делайте! Не бойтесь переборщить, это просто невозможно.

MOC с прямыми ссылками

Когда создают MOC-карточку, обычно идут по прямому пути. Задаются неким вопросом (проблематикой), например, «Какие способы поиска я знаю?». Создают карточку «Способы поиска» и в ней просто перечисляют те заметки, которые у вас уже есть на эту тему, или упоминают эту тему. А если нет таких заметок? Так создайте их! Создайте и кратко опишите их назначение, буквально одной фразой. Это пока, потом вы к ним еще вернётесь…

Такой подход прямого создания элемента карты контента (MOC – Map Of Content) очень наглядный, понятный и простой. Главное здесь в том, чтобы не запоминать, зачем и почему вы поставили ту или иную ссылку в своей MOC-карточке. Поэтому постарайтесь кратко описывать это в самой MOC-карточке: «для этого решения мне понадобится то-то и то-то, потому что так и так«.

Но у такого способа прямого создания MOC-карточек есть очень существенный недостаток – их может быть много (и их должно быть много!). И когда вы создаете новую заметку для новой идеи, проекта, доклада, статьи и т.п., которая захватывает десяток тем, вам нужно будет открыть десяток MOC-карточек и каждую из них модифицировать, вписав новую ссылку. На самом деле это делается быстро, но проблема в том, что это пугает, и мы интуитивно, подсознательно отторгаем такую модификацию, игнорируем или максимально упрощаем эту важную часть работы с картотекой. Вот здесь и появляется главная ошибка в полноте связей между заметками. В результате мы получаем так называемый одуванчик (ромашка, ёжик), то есть одну или несколько больших MOC-карточек с большим количеством исходящих ссылок на десятки заметок. На графе она действительно выглядит как одуванчик весной.

Проблема одуванчиков в том, что они слишком общо, слишком грубо концентрируют связи между заметками. Сама идея ассоциаций теряется, очень сложно потом понять, почему между заметками «Обращение клиента N» и «Как крепить потолок» при глубоком анализе вдруг появилась ассоциативная связь. Я покажу это на примере далее.

Рекомендация: старайтесь делать MOC-карточки более мелкими, дробить их на отдельные темы и подтемы по проблематике, следуя принципу «от общего к частному». Например, «Мои статьи → Статьи про Obsidian → Поиск в Obsidian», или «Телеграм → Боты Телеграм → Разработка ботов → Мои боты → Бот синхронизации Obsidian» и т.п. И не забывайте в каждой такой MOC-карточке хотя бы одним предложением описывать, зачем вы ее создали и что она показывает.

MOC с обратными ссылками

Другой, более быстрый способ организации MOC-карточек базируется на обратных ссылках из заметки на MOC-карточку (ссылка на проблематику). Суть метода в том, что здесь не требуется открывать эту карточку и в нее что-то вписывать, это делается намного быстрее и проще. На самом деле графу и ассоциативному поиску всё равно, какой тип связи используется – прямая ссылка или обратная. А чтобы лишний раз не открывать боковую панель «Обратные ссылки» при работе с MOC-карточкой, я просто добавляю в нее вот такой несложный Dataview-запрос:

```dataview 
LIST FROM [[]]
WHERE (file.name != this.file.name) AND (!contains(this.file.outlinks, file.link))
SORT file.ctime ASC
```

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

Простановка ссылок на MOC

Теперь при написании заметки (создании новой карточки) можно сделать два очень простых действия: сразу проставить ссылки на желаемые карточки (затронутые вопросы или проблематика) и после написания заметки проставить ссылки на упомянутые вопросы в тексте. Это делается буквально в два клика.

Исторически у меня сложилась привычка в каждой заметке указывать ее тематику (родителя) в виде ссылки из свойств заметки (фронтматтер) и основные темы, планируемые в этой заметке в виде ссылок на MOC-карточки. Я для себя называю эти свойства «Тема» и «Ссылки». Свойство «Тема» создается сразу же (оно задано в шаблоне для любых новых заметок), а свойство «Ссылки» добавляется простой горячей клавишей при необходимости.

Не обязательно именно такое разделение или такие названия, у меня просто так сложилось. Главное, что следует понять: это и есть ссылки и связи моей заметки. И неважно, где они проставлены. То есть, как только я начинаю работать с заметкой, я сразу указываю ее связь с родительской темой и вопросы, которые я планирую использовать. И главное! Все возможности ассоциативного поиска мне уже доступны в этой новой, пока полностью пустой заметке. Но эти возможности я покажу чуть позже, пока давайте продолжим ставить ссылки.

Когда я напишу заметку более-менее полно, я обычно делаю еще одну итерацию простановки исходящих ссылок. Здесь здорово помогает панель «Исходящие ссылки» и раздел в ней «Упоминания без ссылки». В этом разделе Obsidian сам предлагает поставить ссылки на другие заметки по тексту. Конечно же, здесь следует подходить вдумчиво, ведь Obsidian выбрал просто все упоминания, а ставить ссылку нужно по смыслу. Например, в этой статье я упомянул Телеграм, и мне тут же предлагается поставить эту ссылку. Но я этого делать не буду, эта статья не про Телеграм, ТГ упоминался только в качестве примера. Мне такая ассоциативная связь в этой заметке не нужна.

Итак, MOC-карточки – это основной способ создания ассоциативных связей в вашей картотеке. Создавайте MOC-карточки на любую тему, большую или маленькую, и не бойтесь переборщить. При создании MOC-карточки старайтесь описывать ту проблематику, тот вопрос, который перед вами стоял, когда вы ее создавали, и очень желательно описывать, почему вы включили в нее ту или иную прямую ссылку. Не следует думать, что MOC-карточка всегда будет такой связной карточкой. У меня не раз было, когда MOC-карточка из одного предложения со временем вырастала в интересную и развитую карточку по определенной теме. Так картотека и растёт.

Поиск в графе

Собственно, предыдущие параграфы были просто подготовкой к использованию графа. Они позволили нам создать сеть связей, то есть сформировать рабочий граф. И сейчас им уже можно пользоваться для решения наших вопросов. Здесь хорошо бы еще упомянуть расположение карточек (папки, которые великолепно могут использоваться для фильтрации в графе) и теги карточки, то есть мягкие связи в графе (терминология автора). Но это тема отдельной статьи, и я к ней вернусь несколько позже. Пока будем использовать просто связи.

Самый простой (и грубый) способ поиска в графе – это поставить фильтр в нём. Например, выбрать всё, что относится к графам в моей картотеке, а потом указывать мышкой на отдельные узлы и смотреть их ассоциации.

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

Попробуем другой способ. Ведь я не зря же сразу при создании новой заметки указал в свойствах «Тему» и «Ссылки» на планируемые заметки. Открою локальный граф. В фильтрах графа сразу установлю глубину поиска 2, а может даже и 3. Как видно, число заметок резко увеличилось, но связи с ними начинаются от текущей, то есть это те самые ассоциации текущей заметки, которые появляются через связанные темы. Это уже намного интереснее. Но их много, поэтому попробуем вписывать в фильтр ключевые слова или даже их части, чтобы увидеть интересующие нас темы.

Даже на скриншоте видно, что для текущей статьи мне предлагается рассмотреть индекс Адамик — Адар на примере поиска связей в социальных сетях (это следующая тема в этой статье). Еще раз хочу отметить, что для этого предсказания темы (запомним это слово!) текст исходной заметки вообще не использовался. Она может быть вообще пустой, это исключительно анализ связей и поиск в них. Собственно, это и есть ассоциативный поиск.

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

Плагин Graph Analysis

Как ни странно, но в огромном количестве плагинов Obsidian таких инструментов раз-два и обчёлся. Точнее, раз и обчёлся. Я нашел только один плагин Graph Analysis. Правда, он не обновлялся уже два года, но работает исправно.

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

Смысл и назначение этого плагина, как можно понять из названия, в анализе графа Obsidian, причем множеством способов, плотно замешанных на математике. Вообще способов анализа у него 11, но некоторые из них требуют дополнительных компонентов NLP (natural language processing или обработка естественного языка), не очень хорошо документированных в его репозитории, поэтому пока я не стал с ними заниматься и экспериментировать.

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

• Adamic-Adar – предсказание связей на основе индекса Адамик — Адар
• Jaccard – определение схожести заметок по коэффициенту Жаккара
• Louvain – кластеризация заметок Лувенским методом
• Co-Citations – поиск взаимных упоминаний

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

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

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

• Укажите ссылки на основные темы (заметки), с которыми вы собираетесь работать в текущей карточке.
• Если в заметке уже есть текст, проверьте «Упоминания без ссылки» в панели «Исходящие ссылки» и проставьте рекомендуемые ссылки по смыслу.

Это важно! Без ссылок никакой ассоциативный поиск и анализ графа работать не будет! И чем точнее и полнее стоят ссылки на родственные темы, тем более впечатляющие результаты вы получите.

Adamic-Adar – предсказание связей на основе индекса Адамик — Адар

Индекс Адамик — Адар — это метод, разработанный в 2003 году Ладой Адамик и Эйтаном Адаром для прогнозирования связей в социальных сетях. Описание можно найти в статье Википедии Adamic-Adar Index.

Метод позволяет находить новых друзей по связям с уже существующими друзьями в социальной сети. Грубо говоря, если мы дружим с Сашей и Машей, а и Саша, и Маша имеют в друзьях Петю, то вполне возможно нам тоже следует задружиться с Петей. Метод Адамик — Адар анализирует все связи в социальном графе, но только намного детальнее. Алгоритм учитывает влияние каждого пользователя на общую рекомендацию в виде некоего коэффициента важности рекомендации. Предположим, Саша из примера выше дружится со всеми подряд и у него 100500 каких-то левых друзей. Влияние Саши на рекомендацию Пети для нас будет заведомо ниже, чем факт дружбы Пети с Машей.

В графе Obsidian анализируются связи между заметками, и метод Адамик — Адар предлагает новые связи между ними с определенным коэффициентом важности этой рекомендации. Рассмотрим это на двух примерах.

Связи с существующей заметкой

Откроем заметку (карточку), в которой уже есть связи. Например, я открыл эту заметку, здесь немного ссылок (я их проставлю значительно позже, уже после публикации), а именно, сейчас эта заметка ссылается:

• На один из переводов статьи Лумана «Диалог с картотекой»
• На общую MOC-карточку «Статьи по поиску в Obsidian» (родительская тема)
• На заметку «Плагин Graph Analytics»
• На заметку «Граф Obsidian»
• На заметку «Ассоциативный поиск»

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

А теперь посмотрим, что предложит мне анализ графа методом Адамик — Адар:

Очень впечатляет! Смотрите, этот метод мне прямо подсказывает темы, которые нужно упомянуть или связать с этой статьей (я не перечисляю все, их 26 в списке, я выбрал только те, которые меня зацепили):

• Zettelkasten, принципы и связи в нем – да, это верно, без этого граф не будет нормально строить связи.
• Продуктивность в Obsidian – да, это верно. Использование ассоциативного поиска повышает продуктивность. Собственно, сейчас об этом и пишу.
• Индекс Адамик — Адар, Мера Жаккара и Лувенский метод – этих связей сейчас нет, но это темы, которые я буду рассматривать здесь же чуть ниже. И мне нужно будет обязательно проставить ссылки на эти карточки!
• Запоминание, соединение и создание – это цитата и мои заметки к ней из книги Тьяго Форте «Создай свой «второй мозг»». Заметьте, какая интересная идея! Ее можно очень хорошо развить – роль ассоциативного поиска в соединении идей и создании новых. Вот реально надо эту мысль сейчас записать и проработать идею!
• Теги Картотеки – надо бы мне рассказать в этой статье о мягких связях в графе через общие теги. Тоже хорошая рекомендация, расскажу, если не забуду и объем статьи позволит.

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

Связи в новой, пустой заметке

Рассмотрим другой пример. Завтра я, написав об ассоциативном поиске, задумываюсь о других видах поиска (вообще я выделяю минимум три вида поиска в Obsidian). И открываю новую карточку, чтобы набросать мысли и идеи о семантическом поиске (смысловой поиск, это еще один вид, он к графу не имеет практически никакого отношения). Что мне предложит моя картотека?

Создаю новую пустую заметку и сразу ставлю в ней связь с темой, о чем собираюсь писать (свойство «Ссылки») и вторую ссылку на родительскую тему (свойство «Тема»): обратите внимание, заметка пустая, в ней всего две ссылки. Вопрос: а почему не одна (для чистоты эксперимента)? Ответ очевиден – если в заметке будет одна единственная ссылка, алгоритмы анализа графа просто возьмут расчет той страницы, на которую ссылается наша экспериментальная заметка. А вот при наличии двух и более ссылок уже начнется «магия».

Итак, что нам предлагает метод Адамик — Адар для новой статьи?

Результат более чем правильный! Прямо готовый план статьи!

Итак, мне предложено:

• Сделать отсыл на предыдущую статью про ассоциативный поиск (на эту, которую вы сейчас читаете) и отметить, что это продолжение.
• Указать, что семантический поиск (да и любой поиск) повышает продуктивность работы, возможно привести примеры.
• Рассмотреть основные способы реализации – плагины Copilot и Smart Connections и их настройки.
• Упомянуть о важности атомарности и самодостаточности заметок.
• Рассмотреть эмбеддинги и алгоритмы RAG, описать их принципы.
• Рассказать о своих опытах тестирования различных моделей нейросетей для расчета эмбеддингов.

Еще раз хочу отметить: это результат на пустой, только что созданной заметке с двумя тематическими (смысловыми) ссылками. Реально я поставил бы их чуть больше, и возможных идей было бы тоже больше.

Еще раз отмечу: ассоциативный поиск использует только связи и ссылки, он не учитывает текст самой заметки.

Ошибки с не-смысловыми ссылками

Когда я открыл для себя этот инструмент анализа графа, я очень вдохновился и начал активно им пользоваться, попутно «причесывая» свою картотеку и массово расставляя смысловые ссылки в карточках. Но быстро наткнулся на совершенно неожиданные результаты. В разных местах и разными алгоритмами анализа графа мне предлагались абсолютно неадекватные связи. Например, в заметке «Методы сегментации аудитории» предлагалась связь с заметками «Крепление потолка в ванной» или «Рецепт осетинского пирога Фыджын» . Причем эти связи были с высоким значением коэффициента Value. Достаточно быстро я заметил закономерность, что это проявляется тем сильнее, чем более узкая тема рассматривается в заметке.

С помощью взаимного цитирования (рассмотрено ниже) я достаточно быстро нашел «виновника» такого поведения – им оказались ежедневные заметки. Когда я их пишу, я могу указать ссылки на какие-то моменты в этот день или при планировании дня указать ссылки на задачи или материалы, с которыми собираюсь работать. А поскольку в любой ежедневной заметке ссылок немного, то по индексу Адамик — Адар вес этих рекомендаций (этих ссылок) становится высоким. Так и появляются нерелевантные связи в графе.

Таким образом, мы имеем дело с разными типами ссылок в графе: с одной стороны есть семантические (смысловые) ссылки, с другой стороны есть фактографические (дневниковые, фиксация факта) ссылки. Можно еще сюда добавить и служебные ссылки, например, ссылки на операционные, служебные карточки типа «Список задач«, «Накопитель» и т.п.

Понятно, для анализа графа нам нужны только семантические ссылки, а остальные нужно просто исключить из анализа. Благо плагин Graph Analysis это позволяет сделать.

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

\/\d{4}-\d{2}-\d{2}

Во-вторых, ввел новый тег «nofollow» (как у поисковых машин в интернете) и исключил из анализа все заметки с этим тегом. И далее пометил служебные карточки типа «Накопитель» этим тегом.

Проблема решена. Теперь качество рекомендаций стало высоким.

Jaccard – определение похожести по коэффициенту Жаккара

Еще одним способом поиска связанных заметок является определение сходства на основе коэффициента Жаккара. Этот коэффициент, или мера Жаккара, был предложен в 1901 году профессором ботаники Полем Жаккаром (Paul Jaccard) в Цюрихе. Описание можно найти в статье Википедии Коэффициент Жаккара.

Простое объяснение этого принципа сравнения следующее. Во-первых, коэффициент или мера Жаккара – это всегда бинарное сравнение, то есть поиск сходства между двумя объектами. У каждого объекта есть ряд признаков, и эта мера представляет собой простую дробь: отношение количества совпадающих признаков объектов к общему количеству признаков обоих объектов. Например, Саше нравятся яблоки, клубника и шашлык, а Маше нравятся манго, клубника и Петя. Общее (суммарное) число признаков у обоих объектов – пять, один из них общий (клубника). Таким образом, сходство вкусов Саши и Маши по мере Жаккара – 1/5, то есть 0.2.

Применительно к графу Obsidian объектами являются заметки, а признаками – связи (ссылки) между ними. Важно еще раз подчеркнуть, что направление ссылки (входящая она или исходящая) роли не играет, то есть если две несвязанные между собой заметки ссылаются на некоторый примерно одинаковый набор других заметок, то степень схожести по Жаккару у них будет очень высокая, вне зависимости от их содержания. Вот здесь очень важно еще раз вернуться к утверждению, сформулированному выше: чем более детально и обширно сформированы узкие, конкретные MOC-карточки по различным тематикам и вопросам (проблематике), тем более точно будут работать алгоритмы анализа графа. Если же у вас лишь несколько больших одуванчиков (ромашек) с большим количеством ссылок, то и результаты будут более чем посредственные.

Давайте повторим эксперимент с двумя заметками из предыдущего примера – текущей заметкой (статья, которую я сейчас пишу), у которой пока небольшое количество ссылок, и пустая заметка о семантическом поиске с двумя ссылками. Что нам предложит определение похожести на основе меры Жаккара?

Вот текущая статья, обратите внимание, существующие ссылки отмечены в списке, остальные заметки – это похожие на основе связей в графе (по ссылочным признакам) заметки, отсортированные по мере убывания схожести:

Итак, какие рекомендации я получил (перечислю те, которые меня явно заинтересовали):

• Во-первых, ссылки на описание меры Жаккара и индекса Адамик-Адар, как родственные темы (напомню, сейчас ссылки из этой статьи на эти темы отсутствуют, но алгоритм их предсказывает).
• Далее, общая тема – Поиск в Obsidian.
• Опять рекомендуются ссылки (темы) о связях в Zettelkasten и на цитату Тьяго Форте «Запоминание, соединение и создание». Это интересная идея для развития темы – ассоциативный поиск в графе и методика CODE (Capture, Organize, Distill, Express).
• Далее отсылка на новую статью о семантическом поиске (напомню, я создал просто пустую заметку для нее и сослался на планируемые темы).
• Показалась ссылка на второй перевод статьи Лумана «Диалог с картотекой».
• И опять напоминание про использование тегов как мягких ссылок (по-хорошему бы надо эту тему осветить, но, видимо, уже не в этой статье).

Что ж, результат очень правильный.

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

Итак, ассоциативный поиск на основе похожести по мере Жаккара мне предлагает следующие тезисы для новой статьи:

• Поиск в Obsidian – это вам не фунт изюму.
• Правильное использование поиска повышает продуктивность в Obsidian.
• Есть ассоциативный поиск, рассмотрен ранее.
• Есть семантический поиск, который может базироваться на RAG и эмбеддингах.
• Атомарность и самодостаточность заметок играет важную роль в качестве поиска.
• Можно использовать плагины Copilot и Smart Connections, но очень важно их правильно настроить.
• Также важно выбрать правильную модель расчета эмбеддингов, рассказать про свои тесты и эксперименты.

Опять я получил прямо готовый план статьи. Напомню, я просто поставил в пустой заметке две ссылки на общую и планируемую тему. Как вам такой результат?

Louvain – кластеризация заметок Лувенским методом

Еще один очень интересный метод анализа графа – это кластеризация узлов алгоритмом Лувена (Louvain algorithm). Метод был разработан в 2008 году Винсентом Д. Блаувельтом, Жан-Ксавье Кабаном и другими исследователями в университете Лувена (Katholieke Universiteit Leuven) в Бельгии. Собственно своё имя алгоритм получил по названию города Лёвен (по-голландски Leuven, по-французски Louvain, в русском языке укоренилось название Лувен). Это один из университетских центров Бельгии, недалеко от Брюсселя. Описание алгоритма можно найти в статье Википедии Louvain method.

Суть метода базируется на оптимизации модульности (термин modularity в оригинале, часто неверно переводимый как модулярность). В данном случае модульность – это некий показатель меры кластеризации модуля, то есть набора нескольких узлов графа, в диапазоне от -0.5 (узлы не объединены в группу, кластера нет) и до 1 (все узлы плотно собраны в группу, в кластер, и могут рассматриваться как единое целое). Фактически, это метод поиска сообществ в графе (в оригинале community detection). Сам метод итерационный, то есть он выполняет похожие расчеты снова и снова много раз над результатами предыдущего шага, делая сообщества всё более крупными, при этом при добавлении нового узла или модуля в сообщества на каждом шаге проверяется, увеличивает ли это степень модульности или, наоборот, уменьшает ее, и на этом основании принимается решение, следует ли добавлять узел или модуль в существующий кластер.

Алгоритм очень быстрый и вообще идеально может быть отображен в виде графа, например, вот частичный граф интернета по состоянию на 2005 год. Однако плагин Graph Analysis работает более примитивно. Он просто считает модульность для групп (кластеров) заметок за несколько итераций (регулируется) и показывает те заметки, соединение (связь, ссылка) с которыми повышает модульность графа. Фактически он предсказывает ссылки, которые желательно бы поставить.

Давайте повторим наш эксперимент с текущей заметкой и новой заметкой о семантическом поиске.

Текущая заметка, статья, которую вы читаете, дает вот такой результат:

А вот для пустой заметки о семантическом поиске:

Что ж, результаты очень хорошо совпадают с предыдущими методами:

• Плагин Graph Analysis и ассоциативный поиск.
• Методы: Адамик — Адар, Жаккар и Лувен.
• Ссылка на плагин Graph Presets, который упрощает работу с графами.
• Опять же упущенная мною тема мягких ссылок в графе через теги.
• Цепи Маркова. А вот это уже новенькое в наших экспериментах! Цепи Маркова – это, в том числе, граф вероятностей перехода системы из одного состояния в другое. Интересная идея, ассоциативный поиск на базе вероятностных моделей, весьма интересная тема для обдумывания!

Обратите внимание на ползунок сверху – это количество итераций расчета. Передвигая его вправо, вы заставляете алгоритм более жестко кластеризировать заметки в графе. Обычно хватает среднего положения, но можно играть с ним, смещая его влево и вправо. Особенно интересно смещение влево, то есть уменьшение числа итераций. Начинают всплывать слабосвязанные темы, но именно здесь могут появляться неожиданные и интересные ассоциации, хотя зачастую бредовые. Например, в моем графе каким-то образом появилась некая ассоциация текущей статьи с заметкой о размерах ручной клади в авиакомпании S7:

Чушь, конечно же, на первый взгляд, но ведь наша цель в таком исследовании – поймать и продумывать все варианты, или как говорил Витька Корнеев у Стругацких «Экземпляр экземпляру люпус эст!» (Перифраз латинской поговорки «человек человеку – волк»), и почему бы нам не замахнуться на «Ассоциативный поиск вещей для ручной клади в командировку»? А почему бы и нет? Создадим заметки что хотелось бы взять с собой и что нужно взять с собой, добавим им какие-нибудь признаки (вес, габариты, допустимость в ручной клади) и будем их крутить и так и сяк. Интересная идея применения Obsidian! Честно скажу, она пришла мне в голову прямо сейчас, когда разбирал результаты расчета моего графа методом Лувена.

Co-Citations – поиск взаимных упоминаний

Ну и наконец еще один инструмент анализа графа – это поиск взаимных упоминаний. Дословно можно перевести этот режим как «взаимное цитирование», но мне кажется термин «взаимное упоминание» более уместным, ведь никаких цитат в заметках нет, мы работаем исключительно со связями. А связь, ссылка – это больше упоминание, чем цитата.

Что делает этот режим? Он просто показывает ссылки по имени заметок в других заметках, в которых упоминается и текущая, и искомая. Грубо говоря, он отвечает на вопрос: а что еще упоминается для этой темы и через какую связную заметку? Это поиск родственных, сопутствующих тем.

Давайте посмотрим на примере текущей заметки:

Ну результат интересный. Обратите внимание на то, что несвязанные заметки, точнее связанные через третью, можно быстро увидеть по отсутствию иконки связи (ссылки). Например, родственная тема для этой моей статьи – плагин Graph Presets, а с темой Zettelkasten моя статья связана через подтему «Граф Obsidian».

Теперь посмотрим на пустой заметке с двумя ссылками. Пусто! Взаимного упоминания пока нет, результат пустой. Но это понятно. По легенде я только-только собираюсь прорабатывать тему семантического поиска и только-только создал заметку практически без ссылок. Взаимных упоминаний еще просто нет, тема семантического поиска требует проработки на моей стороне. Это чистая правда! Отсутствие результата в этом случае – это самый лучший результат, который говорит мне, как автору собственной картотеки, о явном пробеле и необходимости его проработки. И это круто!

Заключение

Граф Obsidian и связи между заметками – это мощнейший инструмент работы с картотекой. К великому сожалению, этот инструмент очень часто недооценивается и игнорируется пользователями и совершенно напрасно! Ведь он открывает дверь в ассоциативный поиск знаний и идей.

Мы на практических примерах рассмотрели возможности ассоциативного поиска в Obsidian, и я очень надеюсь, что мне удалось показать вам, что граф Obsidian – это фантастический инструмент для работы с собственными знаниями.

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

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

Запись Ассоциативный поиск, связи и граф в Obsidian впервые появилась Иван Никитин и партнеры.

Доклад «Практическое импортозамещение Google» охватил широкий спектр вопросов: от анализа проблем, возникающих при отказе от Google Analytics (GA4), Looker Studio и BigQuery, до подробного обзора альтернативных решений, таких как ClickHouse, Datalens, Power BI и Metabase. Были сравнены функциональность сервисов, выделены их преимущества и недостатки.

Особое внимание уделялось обработке больших данных, сквозной аналитике и интеграции с Яндекс.Метрикой, Яндекс.Директом и CRM-системами. Рассматривались вопросы сэмплирования данных, согласования метрик и построения эффективной аналитической системы на базе отечественных технологий.

В качестве примера была представлена архитектура аналитической системы на основе ClickHouse (хранение и обработка данных), Datalens, Metabase и Power BI (визуализация), а также преимущества использования облачных платформ VK Cloud и Selectel.

В заключение были сформулированы рекомендации по переходу на отечественные инструменты, с акцентом на оптимальные решения и стратегию миграции. Эксперт рекомендовал VK Cloud в качестве основной платформы и Datalens для визуализации данных.

Доклад вызвал большой интерес у аудитории клуба SEO PROFI. Участники активно задавали вопросы о практических аспектах импортозамещения и работе с различными инструментами. Материалы доклада (включая презентацию) доступны участникам клуба.

Запись Иван Никитин рассказал о практическом импортозамещении Google-сервисов в SEO впервые появилась Иван Никитин и партнеры.

Место проведения

ВТБ Арена, расположенная в сердце Москвы, стала идеальной площадкой для проведения конференции. Просторные залы, современное оборудование и удобная инфраструктура обеспечили комфортное пребывание участников. Арена, известная своими спортивными событиями, в этот раз превратилась в центр знаний и идей в области цифрового маркетинга.

Программа конференции

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

Тренды в цифровой рекламе

Спикеры обсудили актуальные тенденции, такие как использование искусственного интеллекта, автоматизация процессов и персонализация контента.

Кейсы успешных рекламных кампаний

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

Работа с данными

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

Спикеры и эксперты

Конференция собрала ведущих экспертов в области цифрового маркетинга, включая представителей Яндекса, успешных предпринимателей и практиков. Среди делегатов на этой конференции офлайн присутствовал ведущий SEO специалист нашей компании «Иван Никитин и партнеры» — Дмитрий Афанасьев. Его участие добавило дополнительную ценность мероприятию, так как он поделился своим опытом и знаниями в области поисковой оптимизации, что вызвало большой интерес у участников.

Нетворкинг и взаимодействие

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

Отзыв участника Яндекс конференции Дмитрия Афанасьева

О том, как проходила конференция рассказывает Дмитрий Афанасьев, присутствовавший на мероприятии офлайн от начала и до конца.

Подготовка и регистрация

Заявки на участие начали принимать примерно за полтора месяца до начала конференции, что позволило многим заранее запланировать свое участие.

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

Написать в Telegram

Подробнее

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

Организация пространства

Весь стадион был оформлен с учетом удобства участников: по кругу были расставлены столики и мягкие лавочки, что создавало уютную атмосферу. Однако, к сожалению, раздачи еды практически не было, а количество кафе ограничивалось четырьмя-пятью платными заведениями, которыми я не пользовался.

Программа мероприятия

Начало конференции было запланировано на 10:00 или 10:30, но, как это часто бывает на крупных мероприятиях, старт сильно задержался. Программа была насыщенной: множество интересных выступлений, среди которых выделялась дискуссия с участием пяти маркетологов, представляющих разные каналы и подходы в маркетинге. Каждый из них защищал свой выбор, что напоминало круглый стол в центре зала. После их выступлений последовало обеденное время.

Все выступающие высоко оценивали Яндекс и его инструменты, что подчеркивало значимость компании в сфере цифрового маркетинга.

Подарки и нетворкинг

В рамках мероприятия было приготовлено 100 подарков для участников, оставивших отзывы в социальных сетях с хештегом Яндекса. В завершение конференции всех пригласили на РеКонфу 2025, что добавило нотку ожидания будущих событий.

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

Заключение

Большая Конференция Яндекс Рекламы на ВТБ Арене стала важным событием для всех, кто интересуется цифровым маркетингом и рекламой. Участники получили не только новые знания и идеи, но и возможность расширить свою профессиональную сеть. Несмотря на некоторые организационные недочеты, мероприятие оставило положительное впечатление и подтвердило, что Яндекс продолжает оставаться одним из лидеров в области цифровой рекламы, предлагая своим пользователям актуальные решения и инструменты для успешного продвижения бизнеса.

С нетерпением ждем следующей встречи на РеКонфе 2025!».

Закажите Контекст Директ в компании «Иван Никитин и Партнеры»

Не упустите возможность увеличить свою прибыль уже в этом месяце! Закажите контекстную рекламу в компании «Иван Никитин и партнёры» и получите мгновенные результаты. Мы создадим целевую рекламную кампанию, которая привлечет именно тех клиентов, которые вам нужны. Наши эксперты проведут глубокий анализ рынка и конкурентов, чтобы максимизировать вашу видимость и ROI. Свяжитесь с нами сегодня для бесплатного аудита вашей текущей стратегии и начните получать клиентов уже завтра!

Написать в Telegram

Директ подробнее

Запись Большая Конференция Яндекс Рекламы на ВТБ Арене — Москва (Динамо) впервые появилась Иван Никитин и партнеры.

• Obsidian и нейросети
• Настройка Copilot в Obsidian
• Сценарии использования Obsidian Copilot
• Использование режимов QA в Obsidian Copilot

Однако совсем недавно Obsidian Copilot обновился до версии 2.7.0, которая привнесла множество изменений его функций и сценариев его работы. Вероятно мне придется обновить предыдущие статьи, или отметить в них те моменты, которые изменились в текущей версии плагина.

Ниже я постараюсь показать самые значительные функции Copilot и сценарии их применения, поэтому статья обещает быть длинной.

Вот ее краткое содержание, точнее самые важные части статьи:

• Зачем нужен Copilot в Obsidian
• Основные режимы работы Copilot
• Сценарии использования Copilot
• Поиск смысловых связей в заметках
• Работа с текстом заметки
• Обработка данных

Назначение и применение Obsidian Copilot

Obsiaian Copilot — это ваш помощник при работе с заметками на основе искусственного интеллекта. Копилот может работать практически с любыми моделями нейросетей (ChatGPT, Claude 3.5 Sonnet, Google Gemini и множество других), и точно также Copilot может использовать локальные модели, работающие прямо у вас на компьютере, например, LLAMA3.2, Gemma2.5, mistral-nemo и другие. Если Копилот настроен на использование локальных моделей, никакая информация в интернет не передается, всё происходит исключительно на вашем компьютере, но это может требовать определенных вычислительных ресурсов и, как правило, работает медленнее, чем облачные модели.
Более подробно о настройке можно почитать в статье — Настройка Copilot в Obsidian.

Но Copilot это не просто встроенный интерфейс чата с нейросетью в Obsidian, это инструмент со значительно большим набором функций. Copilot — это прежде всего тесная интеграция с Obsidian и, самое главное, тесная интеграция с самим процессом написания и работы с заметками. Я постараюсь показать этот важный момент в статье несколько подробно, насколько смогу.

Итак, Obsidian Copilot — мощный, умный помощник, который упрощает и расширяет работу с заметками в Obsidian. И это его главное назначение.

Режимы работы Copilot

В новой версии плагина режимы несколько изменились. Их по-прежнему три, но они другие:

• Чат
• Vault QA (базовый)
• Copilot Plus

Режим Long Note QA упразднён в этой версии, но все его функции всё равно доступны в режиме Vault QA, просто с помощью небольшого трюка, который я сейчас покажу.

Более подробно о режимах QA с подробными объяснениями можно прочитать в статье Использование режимов QA в Obsidian Copilot, здесь лишь кратко отметим важные моменты:

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

Режим Vault QA — большее сложный. Он использует механизм RAG (Retrieval Augmented Generation), который базируется на эмбеддингах. Для того, чтобы Copilot работал в этом режиме, сначала необходимо настроить расчет эмбеддингов, затем нужно разово просканировать все без исключения заметки в вашем Obsidian и посчитать для них эмбеддинги (или векторы), то есть некое цифровое представление фрагментов текста из всех ваших заметок. Все эмбеддинги (векторы) рассчитываются с помощью специальной модели нейросети (работает локально, ничего в интернет не передается) и хранятся исключительно локально. При запросе в режиме QA Copilot на основании посчитанных эмбеддингов выбирает несколько наиболее близких по смыслу фрагментов заметок и отправляет их нейросети вместе с вашим запросом. Это позволяет спрашивать нейросеть о любой информации, которая есть в ваших заметках, не выгружая заметки целиком.

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

Режим Vault QA потрясающий по возможностям, но у него есть ряд ограничений, о которых надо помнить.

Во первых, в режиме Vailt QA Coplot использует НЕ ВСЮ найденную информацию (фрагменты ваших заметок наиболее близкие по смыслу к запросу), а лишь ее небольшую часть. Это устанавливается параметром Max Sources в настройках плагина и по умолчанию равно 3. То есть использовать информацию не более чем из трех выбранных заметок. Бессмысленно спрашивать «Перечисли даты, когда я получал премии в прошлом году«, нейросеть не получит полной информации из ваших заметок и не сможет правильно ответить.

Сам автор об этом прямо пишет в сообщении, которое появляется при переключении режима:

Обратите внимание, что система вопросов и ответов QA работает на основе извлечения информации RAG. Мы рекомендуем задавать конкретные вопросы. Для общих вопросов, таких как «дай мне резюме» или «проведи мозговой штурм на основе содержания», более подходящим выбором будет режим чата с прямым упоминанием `[[название заметки]]`.

К тому же режим Vault QA требует некоторого времени для предварительных расчетов перед каждым запросом и он работает медленнее, чем обычный чат.

Во-вторых, качество работы режима Vault QA и качество ответов напрямую зависят от:

• Качества используемой вами модели для расчета эмбеддингов (спойлер для тех, кому лень читать указанные выше статьи — используйте модель bge-m3);
• Полноты информации в ваших заметках. Чем полнее и понятнее написаны ваши заметки, тем лучше. Структура хранилища и связи заметок роли практически не играют (точнее играют, но не первостепенную роль. Я эту тему как-нибудь раскрою отдельной статьей).

Здесь очень важно отметить: при индексации и расчете эмбеддингов никакие запросы Dataview, Tasks и т.п. НЕ ВЫПОЛНЯЮТСЯ, а рассматриваются просто как текст!

В третьих, режим Long Note QA упразднён. Отличие этого режима от Vault QA было в том, что он использовал эмбеддинги (фрагменты текста) только из текущей заметки, а не из всего хранилища. Этот режим предназначался для ответов на вопросы по содержанию очень большой заметки. Важно, если объем заметки меньше размера контекстного окна выбранной вами модели, этот режим бесполезен. Например, у GPT-4o-mini размер контекстного окна 128 тысяч токенов. То есть, заметки объемом менее примерно 60 тысяч слов (!) можно просто целиком грузить в контекст, что будет и быстрее и лучше.

Но если заметка по объему больше этого значения, режим Long Note QA здорово помогал. Несмотря на то, что его упразднили, его очень легко включить. Для этого переключитесь в режим Vault QA и в запросе явно укажите заметку, набирая [[. И всё! Если вы явно укажите заметку в режиме Vault QA, то Copilot будет использовать эмбеддинги только этой заметки.

В четвертых нужно помнить, чтобы режим Vault QA работал вообще, требуется сначала проиндексировать всё хранилище Obsidian, а потом регулярно индексировать изменения. Полная переиндексация выполняется командой «Copilot: Foce re-index vault for QA» и может занимать значительное время, например, у меня это занимает около 5 часов для примерно 5000 заметок. Индексация изменений выполняется намного быстрее, несколько секунд, реже минут и запускается командой «Copilot: Index (refresh) vault for QA». Но это надо делать регулярно.

Вообще это настраивается режимом Auto-index vault strategy в настройках плагина. Автор рекомендует поставить значение ON MODE SWITCH, но это несколько замедляет переключение режимов Copilot, поэтому я предпочел поставить NEVER и регулярно выполняю переиндексацию измененных заметок руками, примерно раз в день/два.

И наконец, анонсирован новый режим Copilot Plus. Но он пока в альфа-версии и доступен только некоторым пользователям, которые спонсируют проект Копилота. В описании на Github есть небольшое видео, демонстрирующее работу этого режима, но я решил дождаться его общедоступной версии, поэтому сейчас пока ничего не могу рассказать об этом режиме.

Сценарии использования Copilot

Для меня Copilot стал если не основной, то очень часто используемой функцией Obsidian при ежедневой работе с заметками. Наиболее частные действия и команды я давно вынес на горячие клавиши и активно ими пользуюсь. Надо отметить, что число команд в новой версии Copilot увеличилось, но не следует сразу их все назначать на горячие клавиши — запутаетесь. Советую вызывать команды стандартно, через Ctrl + P и просто писать ключевое слово команды, как будет показано ниже. И только самые часто используемые назначать на горячие клавиши.

Сценариев использования Obsidian Copilot очень много! Это и большие сценарии, которые могут поменять все заметку (например, корректура текста и стиля), и сценарии анализа заметки (например, создание плана действий и задач по тексту запроса заказчика) и короткие сценарии (перевод на другие языки, подбор синонимов, быстрая обработка части текста заметки). Некоторые сценарии я описывал и показывал ранее, в предыдущих статьях (ссылки в самом начале), некоторые покажу здесь ниже. Но важно помнить, что это лишь небольшая их часть. Возможности ИИ и Copilot намного шире и глубже. Я и по сей день открываю для себя всё новые и новые сценарии и каждый раз удивляюсь «А что, так можно было?«.

Генеративные сценарии

Это создание нового контента, новых заметок, новых идей. Конечно, при лобовом подходе типа «Напиши мне статью на тему Использование ИИ в обучении» вы получите достаточно черновой, необработанный материал, далеко не всегда пригодный к публикации. Но его дальнейшая обработка даст вам достаточно качественный материал.

Я часто использую генеративные сценарии в следующих случаях:

• Создание плана статьи, публикации, лекции, доклада и т.п. Сами статьи я всё же пишу сам;
• Задачи связанные с маркетингом (анализ ЦА, концепции и коррекции стратегии и т.п.);
• Письма и ответы на запросы клиентов (у меня прямо промпт есть, который описывает требуемый корпоративный стиль такого текста);
• Генерация отчетов по выполненным задачам, активностям в проектах и т.п. В свое время это было для меня открытием. Я часто конспектирую подробности решения и хронологию задач в проектах (о! это отдельная тема Obsidian!) и нашел, что если при закрытии очередной задачи написать клиенту развернутый отчет по ней, то это крайне положительно сказывается на дальнейшей работе. Теперь я очень часто именно так и делаю.

Вот несколько примеров использования генеративных сценариев в обучении. Я регулярно читаю лекции в ряде образовательных заведений и пришел к выводу, что очень удобно делать не просто план лекции, презентации и доп. материалы (вопросы для самопроверки, задания для выполнения) с помощью Copilot, но и писать развернутые конспекты этой лекции с глоссарием (списком ключевых моментов и их объяснением) и после лекции отдавать их студентам. Как оказалось, это очень эффективно сказывается на обучении.

По поводу презентаций для выступлений, докладов и лекций. Я сейчас на спор могу сделать презентацию в PowerPoint для 4-часовой лекции (две академические пары), оформленную в корпоративном стиле учебного заведения минут этак за пятнадцать-двадцать. И это всё в Obsidian Copilot. Вот последовательность действий для этого:

• Создается план выступления, доклада, лекции (промпт простой, главное обязательно указать основные тезисы выступления) и сохраняется как заметка;
• Обязательная корректура этого плана вручную (что-то меняется местами, что-то удаляется, что-то дописывается);
• Создается презентация в формате Obsidian Slides на основе полученного плана (промпт прямо такой и есть: «Создай презентацию Obsidian Slides на основе плана в заметке такой-то«);
• Обязательная корректура презентации вручную и ее тестовый прогон для себя чтобы посмотреть как слайды будут смотреться;
• Экспорт полученной презентации в формат PowerPoint (одна команда Export to PowerPoint, плагин Pandoc);
• Коррекция шаблона (мастер-слайды) полученной презентации PowerPoint для придания ей нужного корпоративного стиля.

Всё! Можно идти и выступать.

Поиск связанных заметок

Это очень нужная и интересная задача. У меня в Obsidian большое число материалов и при добавлении новой заметки часто бывает необходимо связать по смыслу с существующими записями.

Вообще для этого есть плагин Smart Connections, но по ряду причин я от него отказался. Не оправдал он моих ожиданий. Ранее я для нахождения семантической (смысловой) связи использовал Vault QA, но с переменным успехом: иногда это получалось найти с первого раза, иногда приходилось делать несколько запросов.

И вот в новой версии Obsidian Copilot эта функция появилась! Поиск связанных заметок использует уже существующее векторное хранилище (эмбеддинги) Copilot, но в отличие от Vault QA число найденных фрагментов текста из ваших заметок не ограничивается.

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

• Максимально подробно и понятно для себя и своими словами описываю сохраненную цитату или мысль (помним о самодостаточности заметки в Zettelkasten);
• Индексирую изменения хранилища (Ctrl + P, «Index (Refresh) vault for QA»). Если вы делаете это регулярно, но это быстро — несколько секунд;
• Выполняю команду Ctrl + P, «Copilot: Find similar notes to active note» (достаточно набрать «simil», я вообще эту команду на горячую клавишу повесил);
• Через секунду-другую вы получите результат, как показано ниже;
• Изучаем его и при необходимости ставим ссылки на найденные заметки. Обращайте внимание на параметр Scope — это степень смысловой похожести.

Обратите внимание, одна и та же заметка дублируется несколько раз. Это связано с тем, что Copilot нашел похожие чанки (фрагменты текста из заметок) и в одной заметке может быть несколько похожих по смыслу чанков.

Уже второй день с момента выхода новой версии Copilot играюсь с этим режимом и могу сказать, что он находит заметки и фрагменты намного качественнее, чем тот же плагин Smart Connections. Это связано с тем, что Copilot использует заведомо более мощную и качественную модель эмбеддингов (в моем случае bge-m3), нежели Smart Connections из коробки.

Работа с текстом заметки

Работа с текстом текущей заметки или выделенным текстом была возможна в Copilot и ранее, через настраиваемые промпты. Но в новой версии автор расширил число готовых предустановленных команд и это оказалось весьма удобным. Рассмотрим часть их них.

Перевод на разные языки

Это команда «Copilot: Translate selection». Как пользоваться:

• Откройте окно чата с Copilot и убедитесь, что выбран режим чата, а не Vault QA.
• Выделите любой фрагмент текста;
• Нажмите Ctrl + P, введите transl и выберите команду;
• Выберите язык из списка, введя одну-две буквы;
• Вставьте полученный текст в заметку.

Вот пример перевода предыдущего абзаца:

Working with the text of the current note or selected text was possible in Copilot before, through customizable prompts. However, in the new version, the author has expanded the number of ready-made preset commands, and this has proven to be quite convenient. Let’s take a look at some of them.

Упрощение и объяснение текста

Это команды «Copilot: Simplify selection» и «Copilot: Explain selection like a’m 5». Последовательность действий такая же как и в предыдущей команде.

Давайте попробуем на тексте:

**RAG (Retrieval Augmented Generation)** — это подход, который использует текстовые подсказки из существующих документов или других данных для генерации ответов. Метод применяет векторные эмбеддинги для поиска наиболее релевантной информации, которая затем используется для генерации ответов на запросы.

Упрощаем этот текст:

**RAG (Улучшенная генерация с помощью поиска)** — это способ, который использует текстовые подсказки из уже существующих документов или данных, чтобы создавать ответы. Этот метод ищет самую подходящую информацию и использует её, чтобы отвечать на вопросы.

Объясняем этот текст пятилетнему ребенку:

**RAG (Улучшенная генерация с помощью поиска)** — это как волшебная книга, которая помогает находить нужные слова из других книг, чтобы отвечать на вопросы. Она ищет самые подходящие слова и использует их, чтобы дать правильный ответ.

Ну что ж, вполне себе неплохо.

Сокращение и увеличение объема текста

Это команды «Copilot: Make selection shorly» и «Copilot: Make selection longer». Последовательность действий точно такая же, как и предыдущих сценариях.

Попробуем сократить абзац из этой статьи выше о Smart Connctions:

Для этого есть плагин Smart Connections, но я от него отказался, так как он не оправдал ожиданий. Ранее я использовал Vault QA для нахождения семантической связи, но с переменным успехом: иногда удавалось найти с первого раза, иногда требовалось несколько запросов.

А теперь увеличим первый абзац этого раздела:

Это команды, которые называются «Copilot: Make selection shortly» и «Copilot: Make selection longer». Первая команда предназначена для того, чтобы сделать выбранный текст более кратким и сжато изложить его суть. Вторая команда, наоборот, помогает расширить выбранный текст, добавляя к нему больше деталей и информации. Последовательность действий для использования этих команд остается точно такой же, как и в предыдущих сценариях, что делает их применение простым и понятным для пользователей. Вы просто выбираете текст, а затем выбираете одну из этих команд, чтобы получить желаемый результат.

Очень удобно, как мне кажется!

Обобщение текста

Попробуем обобщить весь текст раздела «Генеративные сценарии» из этой статьи. Для этого я выделил весь раздел, нажал Ctrl + P и выбрал команду «Copilot: Summarize selection» (я просто ввел «summ»). Вот что получилось:

• Генеративные сценарии создают новый контент, заметки и идеи.
• Прямой запрос может дать черновой материал, который требует доработки.
• Частое использование генеративных сценариев включает:
• Создание планов статей, публикаций, лекций и докладов.
• Задачи по маркетингу, включая анализ целевой аудитории и коррекцию стратегии.
• Написание писем и ответов на запросы клиентов с учетом корпоративного стиля.
• Генерация отчетов по выполненным задачам и проектам, что положительно сказывается на дальнейшей работе.
• Примеры использования в обучении:
• Создание планов лекций и дополнительных материалов с помощью Copilot.
• Написание развернутых конспектов лекций с глоссарием для студентов.
• Для презентаций:
• Быстрое создание презентации в PowerPoint для 4-часовой лекции за 15-20 минут с помощью Obsidian Copilot.
• Последовательность действий включает создание плана, корректуру, создание слайдов, тестовый прогон и экспорт в PowerPoint с последующей корректировкой шаблона.

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

Создание глоссариев

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

Я выделил абзац, нажал Ctrl + P, ввел «glos» и выбрал «Copilot: Generate glossary for selection». Вот результат:

• Глоссарий — список ключевых терминов и их определений, используемый для объяснения сложных понятий.
• Обучение — процесс получения знаний или навыков.
• Анализ — изучение и разбор информации для лучшего понимания.
• Сложный текст — текст, содержащий трудные для понимания идеи или термины.
• Заметка — запись информации в текстовом формате, используемая для хранения и организации данных.
• Obsidian — программа для ведения заметок и организации информации.

Мечта студента!

Изменение тона выделенного фрагмента

Очень интересная функция Copilot, которая позволяет менять тональность текста. Например, я старался писать весь текст этой статьи в простом, но максимально нейтральном стиле, без излишней эмоциональной окраски. А теперь попробуем это изменить на примере текущего абзаца.

Выделяю абзац, нажимаю Ctrl + P и выбираю «Copilot: Change tone of selection».

Тон Professional:

Очень интересная функция Copilot, которая предоставляет возможность изменять тональность текста. Например, в данной статье я стремился придерживаться простого, но максимально нейтрального стиля, избегая излишней эмоциональной окраски. Теперь мы можем продемонстрировать эту функцию на примере текущего абзаца.

Тон Friendly:

Очень интересная функция Copilot, которая позволяет менять тональность текста! Например, я старался писать весь текст этой статьи в простом и нейтральном стиле, без лишних эмоций. А теперь давайте попробуем изменить это на примере текущего абзаца!

А можно и так, по-пацански (я просто написал запрос после выполнения команды: «Напиши это по-пацански, в стиле уличных хулиганов«):

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

Там еще много вариантов, попробуйте их самостоятельно.

Сокращение выделенного фрагмента для короткого сообщения

Эта функция сокращает выделенный текст для публикации в Twitter, на форум и т.п. Попробуем сократить всю эту статью. Для этого я выделил весь текст целиком и выбрал команду «Copilot: Rewrite selection to a tweet». Вот результат:

Обновилась версия Obsidian Copilot до 2.7.0. Это мощный инструмент для управления заметками. В новой версии изменились режимы работы: чат, Vault QA и Copilot Plus. Copilot помогает создавать контент, генерировать отчеты и упрощать работу с текстом. Он также находит связанные заметки и позволяет изменять тональность текста.

Очень интересная функция, особенно для меня, так как я часто увлекаюсь и начинаю писать графоманские лонгриды.

Коррекция грамматики и стиля в выбранном тексте

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

А вот коррекция этого текста. Я выделил текст и использовал команду «Copilot: Fix grammar and spelling of selectiion»:

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

Результат на лицо!

Конечно же, указанными командами возможности Obsidian Copilot не ограничиваются. Их можно произвольно расширять, например, сделать команду объяснения текста не для пятилетнего малыша, а для школьника. Это делается с помощью настраиваемых промптов, которые описаны в статье Сценарии использования Obsidian Copilot.

Обработка данных

В качестве примера обработки и визуализации данных я использую пример генерации деловой графики в ваших заметках. Этот пример навеян одним из вопросов на форуме русскоязычного сообщества Obsidian.

Для начала создадим Custom Prompt генерации деловой графики по данным, которые будут указываться в выделенном тексте. Для этого выполним команду «Copilot: Add Custom Prompt» и введем следующее:

Название: Генерация графика
Текст:

Сейчас ты аналитик данных. Последовательно выполни следующие шаги:

1. Проанализируй эти данные;
2. Выбери наиболее подходящий тип графика для визуализации этих данных;
3. Нaпиши код mermaid для вставки этого графика в заметку Obsidian.
4. Вот данные:
   {}

Сохраним наш промпт.

Теперь подготовим данные. Для этого я загрузил целиком всю эту статью в контекст чата. Я просто в чате ввел двойные квадратные скобки и выбрал текущую заметку. Далее написал следующее:

Проанализируй эту заметку, выпиши основные разделы этой заметки и посчитай количество слов в каждом из них. Ответ дай в виде списка:

• Название раздела — число слов.

Вот результат:

• Встречаем Obsidian Copilot 2.7.0 — 36 слов
• Назначение и применение Obsidian Copilot — 164 слова
• Режимы работы Copilot — 153 слова
• Сценарии использования Copilot — 61 слово
• Генеративные сценарии — 134 слова
• Поиск связанных заметок — 134 слова
• Работа с текстом заметки — 92 слова
• Обработка данных — 83 слова
• Коррекция грамматики и стиля в выбранном тексте — 104 слова

Теперь я выделил этот результат и выбрал команду «Copilot: Apply Custom Prompt» и далее выбрал созданный нами промпт «Генерация графика».

Вот результат:

1. Анализ данных:
   Данные представляют собой список разделов статьи с указанием количества слов в каждом из них. Это позволяет увидеть, какие разделы более объемные, а какие — менее. Наиболее длинный раздел — «Назначение и применение Obsidian Copilot» с 164 словами, а самый короткий — «Сценарии использования Copilot» с 61 словом.
2. Выбор типа графика:
   Для визуализации этих данных наиболее подходящим типом графика будет столбчатая диаграмма. Она позволяет легко сравнить количество слов в разных разделах и наглядно увидеть, какие разделы длиннее, а какие короче.
3. Код mermaid для вставки графика в заметку Obsidian:

graph TD;
    A[Разделы статьи] -->|36| B[Встречаем Obsidian Copilot 2.7.0]
    A -->|164| C[Назначение и применение Obsidian Copilot]
    A -->|153| D[Режимы работы Copilot]
    A -->|61| E[Сценарии использования Copilot]
    A -->|134| F[Генеративные сценарии]
    A -->|134| G[Поиск связанных заметок]
    A -->|92| H[Работа с текстом заметки]
    A -->|83| I[Обработка данных]
    A -->|104| J[Коррекция грамматики и стиля в выбранном тексте]

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

Ну, так себе результат, я бы всё же круговую диаграмму использовал. Попрошу его это сделать. Прямо в чате пишу «Используй круговую диаграмму«.

И вот результат:

Код mermaid для вставки круговой диаграммы в заметку Obsidian:

pie
    title Количество слов в разделах статьи
    "Встречаем Obsidian Copilot 2.7.0": 36
    "Назначение и применение Obsidian Copilot": 164
    "Режимы работы Copilot": 153
    "Сценарии использования Copilot": 61
    "Генеративные сценарии": 134
    "Поиск связанных заметок": 134
    "Работа с текстом заметки": 92
    "Обработка данных": 83
    "Коррекция грамматики и стиля в выбранном тексте": 104

А вот это уже совершенно другое дело!

Заметьте, на всю задачу ушло около минуты времени.

Заключение

Итак, Obsidian Copilot 2.7.0 очень мощный инструмент для работы с заметками любой сложности. Но очень важно помнить, что это лишь инструмент, а не волшебная кнопка «Сделай мне хорошо». Понимая возможности и принципы этого инструмента, можно и облегчить свою повседневную работу и значительно расширить горизонты. А оно того стоит! Ведь фактически границы Obsidian и Copilot определяются лишь вашей фантазией.

Я с большим удовольствием отвечу на любые ваши вопросы, которые вы можете задать здесь в комментариях, или в чате Obsidian, в разделе «Искусственный интеллект: ChatGPT».

Примечание

Завершая работу над статьей, я выполнил следующий запрос в Copilot:

Проанализируй [[Встречаем Obsidian Copilot 2.7.0]], напиши краткое обобщение статьи для анонса (не более 500-600 символов).
Далее действуй как опытный SEO специалист и напиши привлекательные TITLE и DESCRIPTION для этой статьи.
Далее действуй как художник и придумай концепцию иллюстрации для этой статьи. Напиши промпт для генерации этого изображения длиной не более 1000 символов.

И это тоже иллюстрация использования Copilot в повседневной практике.

Запись Встречаем Obsidian Copilot 2.7.0 впервые появилась Иван Никитин и партнеры.

В отличие от обычного режима чата, режимы 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 может значительно повысить эффективность поиска и обработки информации, а также улучшить качество ваших заметок. Рекомендуется экспериментировать с различными подходами и методами, чтобы максимально раскрыть потенциал этого инструмента и адаптировать его под свои нужды.

Запись Использование режимов QA в Obsidian Copilot впервые появилась Иван Никитин и партнеры.