Привет, Хабр!
В своей работе мне приходится держать в голове очень много информации, иногда настолько, что нельзя не полагаться на современные технологии. В этот раз я хочу проверить, можно ли собрать для автора рабочую систему, в которой заметки, черновики и готовые статьи живут в хранилище Obsidian, а локальная большая языковая модель DeepSeek-R1 помогает работать с этим массивом знаний прямо внутри хранилища. Смысл эксперимента не в том, чтобы переложить письмо на нейросеть, а в том, чтобы быстрее доставать уже осмысленную информацию, а не каждый раз заново разбирать сырые источники. Готовый текст затем уходит в рабочий GitLab, где ту же базу видит другой автор и может продолжить работу по той же схеме.
Меня здесь интересует не очередной сервис «всё в одном», а воспроизводимый процесс, в котором каждый инструмент закрывает свой участок авторской работы. В предыдущем тексте о «Втором мозге» уже был важный вывод: нейросеть не заменила автора, но стала полезным усилителем там, где есть заметки, структура и понятные правила работы с текстом. Настало время для нового опыта с применением ИИ.
В этот раз я применяю ту же логику к локальному сценарию. Вместо облачного помощника использую DeepSeek-R1 через Ollama на своем рабочем компьютере. Подключаю модель к Obsidian через плагин Copilot и проверяю, насколько удобно создавать новые материалы на основе существующей базы знаний и корпуса текстов.
По сути, эта статья тоже является частью эксперимента: я собираю её из уже существующих заметок, связанных .md-файлов и ручной редактуры после диалога с локальной моделью.
Зачем автору вообще нужен такой «второй мозг»
Быстрый сбор фактов даёт ответ «здесь и сейчас». Настоящее понимание появляется позже: когда просто пересказать идею своими словами, связать её с другими темами, применить в новой задаче и не потерять смысл даже тогда, когда дословная формулировка уже выветрилась. Поэтому мне нужен не склад ссылок, а рабочая память, в которой сырая фактура превращается в наши собственные знания в виде пригодных к повторному использованию заметок.
Кроме того, я хочу лучше понять, каким образом можно добиться того, чтобы получилось максимально погрузить модель в контекст рабочих материалов и получать полноценные ответы с учётом всей предоставленной информации из хранилища.
Именно здесь локальная связка из Obsidian, заметок по Цеттелькастену и локальной модели становится не только техническим увлечением и попыткой понять как всё будет работать, а практическим инструментом. Она помогает меньше зависеть от сырых внешних данных и чаще опираться на уже обработанную информацию: то есть на то, что уже понятно, проверено, связано и заранее сохранено.
А ещё бывает так, что иногда сторонние сервисы могут «вдруг» оказаться недоступными или для взаимодействия с ними могут понадобиться дополнительные шаги или встроенный прокси-навигатор 😉
В рамках текущего процесса обычно теряется больше всего времени при сборке структуры и дополнением описаниями кейсов из реальной практики. Поэтому для меня актуально автоматизировать и упростить эти звенья.
Почему мы собираем свою экосистему, а не живём в одном сервисе
У готовых платформ вроде Notion или Google Docs есть свои плюсы, но для нас важнее доступность, контроль и разумные затраты. Поэтому мы собираем систему из отдельных инструментов: так проще понимать роль каждого звена, при необходимости менять его без поломки всего процесса и не переплачивать за лишнюю оболочку.
Это особенно удобно, потому что база знаний хранится в простых .md-файлах. Их можно открыть в любом редакторе, они не привязывают нас к одному сервису и нормально работают с системой контроля версий. Поэтому для нас умные инструменты — не самоцель, а способ улучшить рабочий процесс.
По сути, так получается выстроить понятную и гибкую среду под свои задачи. В этом и есть смысл эксперимента: проверить, насколько далеко можно зайти без лишней подписочной нагрузки, а заодно честно описать, что в такой системе действительно работает.
Какие платные сервисы эта связка уже позволила не использовать или использовать реже
Мы не преследуем цель прорекламировать какие-то инструменты, мы пользуемся теми, что есть в свободном доступе. Да, у нас есть как личные, так и профессиональные предпочтения, однако мы отмечаем, что это «вкусовщина», и не призываем точь-в-точь повторять наш опыт. Напротив, своим примером мы призываем пробовать новое, находить свои решения и лайфхаки.
Благодаря этой связке нам удаётся обойтись без коммерческой лицензии Obsidian, Copilot Premium, Cursor Pro, API для DeepSeek/ChatGPT/Claude и т.д.
С чего начинается эксперимент: локальная модель на рабочем компьютере
Технически всё начинается с сервиса Ollama, который в данном сценарии представлен не как отдельный предмет исследования, а как локальный слой, откуда скачивается модель, запускаю её на своей машине и подключаю к заметкам через специальный плагин.
ollama run deepseek-r1:7bБиблиотека Ollama предлагает модель 'deepseek-r1:7b' объемом около 4,7 ГБ. Обратите внимание: даже бесплатная локальная версия этой модели требует значительных ресурсов от вашего компьютера.
У Ollama есть графический интерфейс, где можно общаться с выбранной моделью. Однако он меня не интересует, так как я хочу использовать текст и ИИ в одном окне Obsidian.
Мне же достаточно просто фоновой работы, запускаю в терминале командой ollama serve.
Я выбрал конкретно эту модель не потому, что хочу устроить сравнительный тест всех локальных моделей подряд. Важнее другое: модель не слишком требовательная, широко доступна, уже хорошо встроена в экосистему Ollama и в рамках эксперимента соотносится с возможностями моего рабочего компьютера.
Кроме того у нас на это 5 причин в пользу локального развертывания:
Совместимость — подходит по системным требованиям;
Безопасность — защита от внешних угроз;
Приватность — контроль над тем, что происходит внутри нашей собственной среды;
Конфиденциальность — ограничение доступа третьих лиц к рабочим материалам;
Гибкость — возможность заменить и настроить при необходимости.
Для авторской контентной среды это звучит особенно хорошо. Черновики, наработки, служебные заметки и неопубликованные материалы не хочется лишний раз выносить за пределы хранилища.
Но у такого решения есть и понятная цена. Чем модель крупнее, тем выше требования к памяти и тем дольше мы ждём ответ. При запуске локальных LLM в случае нехватки видеопамяти можно перейти в CPU-режим: это рабочий, но более медленный путь. Поэтому в эксперименте нас интересует не мгновенный отклик любой ценой, а общий выигрыш по задаче. Если ответ в итоге экономит больше времени на поиске и сборке материала, его всё ещё можно считать полезным. Однако следует оценить, что можно назвать «медленным», это я и сделаю по итогу эксперимента.
Конфигурация рабочего компьютера
Процессор: AMD Ryzen 7 8845H
Видеокарта: Radeon 780M Graphics (3.80 GHz)
Оперативная память: 16,0 ГБ
Жесткий диск: SSD 1 ТБ
Пусть это и не самый мощный аппарат, но достаточно шустрый, чтобы попробовать. В среднем отвечает модель на короткий запрос за пару секунд, на разбор статьи и на длинную правку может уйти 5–7 минут.
Что такое Obsidian Copilot и зачем он нужен внутри хранилища
Следующее звено — плагин Copilot for Obsidian. Он открывается прямо в Obsidian, умеет работать в чате, искать по заметкам, обрабатывать контекст файлов и поддерживает как локальные, так и OpenAI-совместимые модели.
После установки через Community Plugins в интерфейсе появляется отдельная кнопка, которая открывает чат-панель внутри Obsidian.
Плагин предлагает несколько функций, идеально подходящих для работы автора. Режим чата позволяет добавлять заметки через @ и обсуждать их. Vault QA Mode задает вопросы ко всему хранилищу. Командная палитра и быстрые команды отправляют выделенные фрагменты на обработку. Relevant Notes автоматически подбирает связанные записи по смыслу и ссылкам. Плагин также умеет искать по хранилищу без предварительной индексации, что удобно для начала эксперимента: порог входа ниже, а результат виден быстрее.
Нам здесь важна не только функциональность сама по себе, но и её форма. Copilot помогает не переключаться между заметками, редактором и моделями. В результате диалог с нейросетью становится продолжением работы с материалом, а не отдельной задачей на другом экране.
Кстати, мой коллега @mikhail-lankin уже описал свой опыт перевода текста через этот плагин в другой статье.
Как устроена наша локальная база знаний
Основа всей схемы — локальный репозиторий, который мы клонируем на рабочий компьютер и открываем в Obsidian как обычное хранилище. Внутри лежат не только статьи, но и черновики, заметки по исследованиям, глоссарий, FAQ, служебные файлы, стайлгайд, ToV, а также холсты с картой тем и связей. Чем лучше устроен такой репозиторий, тем полезнее контекст для модели: в предыдущем тексте про связку репозитория и ИИ прямо отмечалось, что глоссарий, конвенции именования, гид по стилю и ToV помогают модели вписываться в уже существующий контент, а не отвечать обобщённо.
Obsidian хорошо подходит для такой базы именно потому, что хранит данные в простых .md-файлах. В первой статье было показано, что поверх этой простой структуры можно наращивать связи, wiki-ссылки, холсты и граф. Каждый элемент на холсте может быть связан с отдельным файлом и обновляться вместе с ним. Это удобно не только для исследования, но и для редакционной работы: план статьи, набор смысловых блоков и будущие разделы можно видеть не как линейный список, а как связанную карту.
Формат Markdown здесь важен не меньше, чем сам Obsidian. .md проще читать, сравнивать, искать и версионировать, чем .docx. В статье о командной работе с контентом отдельно подчёркивалось, что Git позволяет управлять не только готовым текстом, но и всей подводной частью: заметками, наработками, черновиками и связанными материалами. Поэтому другой автор после обновления локальной копии получает не просто новую версию файла, а обновлённый контекст целиком.
Обычно папку .obsidian при совместной работе разумно исключают из контроля версий, если команде не нужно жёстко делить одинаковые настройки. Но это уже деталь конкретной договорённости. Главное — чтобы структура хранилища была прозрачной и предсказуемой для всех, кто в ней работает.
Как заметки по Цеттелькастену превращают фактуру в понимание
Метод Цеттелькастен полезен здесь не как модная теория, а как способ не теряться в больших объёмах информации. Одна заметка — один источник, одна заметка — одна идея, затем всё это связывается ссылками. Сначала появляются выписки по исходным материалам. Потом — отдельные записи, где мы формулируем мысль уже своими словами. После этого между идеями возникают связи, и база знаний начинает работать как сеть, а не как свалка файлов.
Для автора контента этот подход полезен по той же причине, по которой он работает в исследовании. Хороший текст почти всегда строится из точной выборки идей, понятных формулировок и связи между разными фрагментами знания. Если мы пишем серийно, регулярно возвращаемся к документации, исследованиям, продуктовым заметкам и старым статьям, то связанная сеть маленьких записей начинает окупаться. Если пишем редко и разово, накладные расходы могут не оправдаться.
Отдельный вопрос — фильтр. В базу стоит класть не всё подряд, а только то, что помогает решать повторяющиеся задачи, отвечает на частые вопросы, критично для качества текста или безопасности работы, опирается на проверяемые источники и не устаревает через неделю.
Есть и обратная сторона: такая система ускоряет работу только до тех пор, пока полезные связи находятся быстрее, чем собираются заново из сырых источников. Если обслуживание структуры начинает съедать заметную долю времени, значит, её пора упрощать. Это один из важных критериев нашего эксперимента.
Как написать новую статью поверх старых материалов
Дальше начинается самое интересное. Я открываю в Obsidian уже существующую статью, заметки по смежной теме и чат Copilot. Затем задаю вопросы модели, которая получает контекст из нашего собственного хранилища. Без премиум-подписки можно работать в двух режимах. Chat Mode позволяет добавить конкретную заметку через @, а Vault QA Mode — спросить о повторяющихся мотивах и связях во всём массиве материалов.
На этом этапе мне важна не сама возможность генерации, а проверка понимания. Наблюдаю, как локальная DeepSeek поняла уже существующий текст, какие недостающие блоки она видит, где замечает логические провалы, может ли найти полезные пересечения с другими .md-файлами и насколько уверенно держит общий контекст репозитория.
Один из показательных сценариев в эксперименте проходит так: я задаю вопросы к тексту, его разным частям, чтобы понять, что в нём хорошо раскрыто, чего не хватает и какие смежные темы можно добавить для усиления материала.
Потом прошу предложить изменения: добавить FAQ, встроить два-три блока из связанных заметок и вынести спорные места в отдельные подзаголовки. После этого вручную редактирую предложенный вариант, проверяю фактуру, убираю всё лишнее и проверяю общий нарратив статьи.
Когда нужен не общий совет, а точечная правка, удобно работать с выделенным фрагментом. Командная палитра и быстрые команды в Copilot позволяют отправить в обработку конкретный абзац, сократить его, переписать более ясно или встроить в него недостающий контекст без долгих переключений между окнами.
Именно здесь проходит граница между редакторской помощью и размыванием авторского видения. Модель может ускорить переформулировку, подсветить пробел и предложить ход мысли, но не должна подменять замысел. Реальная выгода появляется только тогда, когда в центре остаётся человек, а не инструмент.
Да, на не самом мощном рабочем компьютере локальная модель не отвечает мгновенно. Иногда это прям раздражает. Но в эксперименте мы оцениваем не скорость одной реплики, а весь цикл задачи. Если модель помогает реже возвращаться к сырым источникам, быстрее вытаскивает нужный контекст из базы и даёт осмысленный заготовочный ход, то даже медленный ответ может оказаться выгодным.
Что происходит после черновика: git и рабочий GitLab
После правок я отправляю изменения в рабочий репозиторий GitLab. Система контроля версий нужна не только ради финального текста, но и ради всей накопленной среды вокруг него.
В этом и состоит одно из главных преимуществ такого подхода для команды. Второй автор после обновления локальной копии видит не только новую версию статьи, но и добавленные заметки, обновлённые смысловые блоки, новые связи и все сопутствующие материалы.
В предыдущей статье о Втором мозге отдельно назывались преимущества такого сценария: участники не мешают друг другу, есть история правок, понятный механизм ревью, ветки, разрешение конфликтов и сохранность данных. Для текстовой команды это не менее важно, чем для разработчиков.
Ещё один плюс — резервирование. Даже если один инструмент подводит, сама база знаний не исчезает вместе с ним: есть локальная копия, есть удалённый репозиторий, есть история коммитов. Риски потери контекста, перегрузки инструментами и ложного доверия к модели остаются, но становятся управляемыми.
Дальше процесс устроен так: под каждый текст заводится отдельная ветка, чтобы у материала было своё рабочее пространство со своей логикой правок. Потом создаётся merge request, и именно в нём начинается полноценное ревью: появляются комментарии, обсуждаются формулировки, уточняются спорные места, вносятся последние смысловые и редакторские коррективы. Так текст проходит через несколько итераций, постепенно собираясь в итоговую версию. А финальная сборка происходит уже ближе к публикации — когда все замечания закрыты, решения приняты, и материал можно выпускать.
По каким признакам я определяю, удался ли эксперимент
Для меня главный вопрос здесь очень практичный: действительно ли стало проще работать. Я не пытаюсь доказать, что локальная модель всегда лучше облачной. Мне важно понять, хватает ли локальной DeepSeek для повседневной работы с собственной базой знаний, когда критичны контроль, безопасность и доступность, или в какой-то момент облачные модели всё же оказываются сильнее по скорости и качеству.
Я смотрю на несколько признаков. Получается ли быстрее собирать первый рабочий черновик. Приходится ли реже возвращаться к сырым внешним источникам. Стало ли коллегам проще подхватывать материал после очередного push. Не стала ли сама система заметок слишком дорогой в поддержке. И не превратилась ли локальная модель в красивую, но медленную прослойку между мной и текстом.
Если на части задач локальная модель не дотягивает, я не считаю эксперимент провальным. Наоборот, это помогает точнее провести границу: что удобно и безопасно делать локально, а что в отдельных случаях разумнее отдавать облачной модели — конечно, только там, где это не нарушает требования к конфиденциальности и не создаёт лишних рисков.
Коротко о главном: что (не) получилось в итоге
Этот эксперимент был нужен не ради технической экзотики и не ради самой идеи «запустить локальную модель у себя». Я хотел добиться вполне практичной вещи: чтобы наши материалы не приходилось каждый раз вручную подсовывать в запрос, а чтобы сама система изначально работала на основе уже накопленной и организованной базы знаний. На этом месте и выяснилось главное: локальная модель в том виде, в котором она работает через Copilot, закрывает задачу лишь частично. Она умеет помогать точечно, но не даёт того уровня встроенной опоры на хранилище, которого нам хотелось изначально. Поэтому дальше логика ведёт уже не просто к промптам с приложенными фрагментами, а к более глубокой работе с RAG и добавлением новых материалов в YAML-файлы. Эту тему мы, скорее всего, вместе с @mikhail-lankin вынесем в отдельный материал, потому что сами уже движемся в эту сторону и не хотим превращать одну статью в путаницу из нескольких разных подходов.
Если говорить совсем честно, в какой-то момент я даже немного расстроилися. Хотелось, чтобы эксперимент сработал чище и убедительнее. Но тем важнее было рассказать всё как есть, без попытки cгладить углы:
а) подобная идея наверняка приходила в голову не только мне;
б) возможно, вы открыли этот текст ровно затем, чтобы попробовать у себя похожую связку;
в) если наш опыт сэкономит вам время, нервы или хотя бы скорректирует ожидания, значит, всё это было не зря.
Ещё один вывод оказался очень прозаичным и потому особенно полезным. С такой конфигурацией Obsidian в реальной работе оказался для нас удобнее, чем Cursor. А локальная модель на рабочем ноутбуке — слишком прожорливой. Она ощутимо съедает ресурсы, мешает параллельно пользоваться другими программами, нагружает систему, разогревает ноутбук и включает тот самый раздражающий сценарий, когда сидишь рядом с горячей машиной и слушаешь, как гудят кулеры, вместо того чтобы спокойно работать.
И ладно бы это всегда окупалось качеством. Но нет: иногда ответа приходится ждать слишком долго, а потом ещё и допиливать его вручную с мыслью: «Да проще самому было сделать». На этом фоне облачные модели выглядят не уступкой, а нормальным рабочим выбором: можно дать им нужные фрагменты, получить результат быстрее, а порой и лучше — просто потому, что локально не удаётся развернуть более сильную модель без аппаратных ограничений.
При этом локальный подход нельзя назвать бесполезным. На коротких задачах он действительно неплохо справлялся. Быстрый вопрос к отдельной заметке, работа с выделенным фрагментом, черновая правка, поиск неожиданных связей, генерация идей — тут такая модель вполне уместна. Иногда она полезна даже не потому, что сразу даёт нормальный ответ, а потому, что запускает мысль. Пока она думает, можно заниматься другими делами. А потом вернуться и либо зацепиться за удачную находку, либо, наоборот, увидеть явную глупость, оттолкнуться от неё, перевернуть ответ на 180°, перепроверить факты и в процессе заметить то, что раньше вообще не приходило в голову. Такой эффект тоже нельзя списывать со счетов.
Но граница применимости у локальной модели для нас теперь стала намного яснее. Она проходит там, где вместо помощи начинается трение: где всё тормозит, где неудобно, где хочется открыть что-то привычнее типа агента в Cursor, онлайн-клиент или другую облачную модель, и просто сделать задачу быстрее и спокойнее. Для крупных сценариев, глубокого сканирования больших массивов текста и серьёзной интеллектуальной сборки локальный вариант в нашем случае пока не даёт того комфорта и качества, чтобы брать его за основную рабочую опору.
В итоге вывод довольно простой. Не нужно подстраиваться под ИИ любой ценой, а ИИ должен экономить силы и время. Если инструмент помогает — отлично, в работу его. Если он превращает процесс в борьбу с горячим ноутбуком, шумящим кулерами и затянувшимся ожиданием, значит, красная черта уже пройдена. Поэтому дальше я предпочитаю держаться не за один конкретный стек, а за принцип: использовать самые удобные и продуктивные инструменты в нужном месте. Похоже, что токены для ChatGPT или Claude через Obsidian Copilot могли бы оказаться более удачной заменой Cursor. Плюс остаётся вариант с подключением Gemini по API с вполне вменяемыми лимитами. Возможно, об этом мы расскажем в будущих статьях. Ведь главное, чтобы технологии помогали расширять мышление и ускорять работу, а не заставлять тратить лишние часы только ради того, чтобы доказать, что «и так тоже можно».
