TL;DR. Obsidian + Gemma4 локально = база знаний инженера, которую можно спрашивать. Без облака, без подписок, без потери знаний при смене людей.
Что внутри: принцип LLM-wiki (raw → wiki → query), структура хранилища, шаблон страницы инцидента, настройка Gemma4 через Ollama за 3 команды, ежедневный флоу INGEST/QUERY/LINT.
Для кого: инженер АСУ ТП, ОВК или любой технический специалист, у которого «документация» — папка с файлами на сетевом диске.
Время: 12 минут на чтение, 45 минут на первую настройку.
Это случилось на заводе по производству кормов в Краснодарском крае. Меня позвали разобраться, почему линия дозирования компонентов периодически уходит в аварийный останов без внятной причины. Предыдущий инженер уволился три месяца назад. Его документация — папка на сетевом диске, 847 файлов, из них 200 с названием вроде СХЕМА_v2_ФИНАЛ_правки_Иваненко.dwg.
Я потратил две недели на поиск причины. Ещё неделю — на восстановление логики изменений, которые вносились без единой записи. Оказалось: предыдущий инженер поменял уставку реле давления с 4,2 бар на 3,8, потому что срабатывало ложно. Причина разумная. Но никто не знал, что при 3,8 срабатывает защита компрессора при пуске в мороз. Вся информация — у него в голове. Папка молчала.
С тех пор у меня жёсткое правило: документация — это не место хранения файлов. Это место хранения решений.
Почему папки и Word перестают работать
Стандартный инженерный архив выглядит примерно так:
Проект_Завод_А/
Исходники/
Финальные/
Согласовано/
Правки_после_согласования/
ФИНАЛЬНАЯ ВЕРСИЯ/
ТОЧНО_ФИНАЛЬНАЯ/
Никто в этом не виноват. Мы документируем хронологически — так удобно в моменте. Сохранил, назвал, положил. Но спустя полгода эти файлы перестают быть источником знаний. Они становятся архивом артефактов, из которого невозможно вытащить ответ на вопрос.
Первая проблема — документ не помнит контекст. В протоколе написано «уставка изменена на 3,8 бар». Не написано почему. И уж точно не написано, что об этом нужно предупреждать следующего инженера.
Вторая — v1, v2, v2_правки — это история файла, не история решения. Когда тебе нужно найти «почему выбрали Siemens S7-1200, а не ОВЕН ПЛК110», ни одна версия документа не ответит.
Третья — при смене людей знания исчезают. По данным ISA (2023), 60–70% критических знаний о проектах хранится в головах ключевых специалистов, а не в документации. Когда человек уходит — уходят и знания.
Выход не в том, чтобы писать больше документов. Выход — писать иначе.
LLM-wiki: принцип, который меняет подход
Идея проста: разделить три вещи, которые обычно смешивают.
Сырой материал — всё входящее: PDF от производителя, протокол пусконаладки, письмо от заказчика, лог ошибок из SCADA. Это документы, которые нельзя менять. Факт есть факт.
База знаний — переработанный слой. Здесь не хранятся файлы, здесь хранятся смыслы. Страница «почему выбрали S7-1200» — это аргументы плюс контекст плюс ссылка на протокол, а не скан самого протокола. Страница «авария 2024-03-11» — причина, диагностика, решение, что изменили, чтобы не повторилось.
Выходы — отчёты и ответы на вопросы, которые формируются из базы.
Три операции поддерживают эту систему живой:
- INGEST — пришёл новый документ, ты его «перевариваешь»: создаёшь или обновляешь страницы, добавляешь ссылки
- QUERY — задаёшь вопрос базе, получаешь ответ со ссылками на конкретные страницы
- LINT — периодическая проверка: что устарело, что противоречит друг другу, на что никто не ссылается
Разница с обычным архивом — как разница между библиотекой и складом. На складе лежат книги. В библиотеке они связаны между собой, проиндексированы, и есть система, которая знает, где что искать.
Этот принцип работает в любом инструменте. Но лучше всего — в Obsidian.
Почему Obsidian, а не SharePoint и не Notion
У каждого есть своя ниша. SharePoint спасает, если на предприятии уже стоит Microsoft 365 и есть IT-отдел, который им управляет. Notion — для тех, кого не беспокоит, что данные хранятся на американских серверах. Но у инженера на промышленном объекте часто совсем другие ограничения: закрытый периметр, требования службы безопасности, объект вообще без стабильного интернета.
Obsidian хранит всё локально. Ни одна заметка не уходит на сторонний сервер. Для многих промышленных объектов это не предпочтение, а требование безопасности.
Формат .md читается в любом редакторе без установки программ. Через 10 лет эти файлы будут читаться так же. Это не проприетарный формат, который исчезнет вместе с продуктом.
Двусторонние ссылки создают граф знаний. Когда страница «авария 2024-03-11» ссылается на «реле давления Danfoss RT260», а та — на «регламент обслуживания компрессоров», ты видишь связи, которые в папках с файлами принципиально невидимы.
И всё это бесплатно.
Структура хранилища для инженера
Вот минимальная рабочая структура, которую я использую:
vault/
raw/
# Исходники: PDF, протоколы, спецификации — неизменны
2024_pusk_kotelnaya.pdf
siemens_s7-1200_manual_ru.pdf
wiki/
schema.md # Правила: как называть страницы, какие поля обязательны
index.md # Каталог всех страниц
log.md # Журнал операций INGEST/LINT
concepts/ # Понятия: что такое PROFIBUS, что такое Safety PLC
entities/ # Конкретные вещи: контроллер S7-1200, датчик Endress+Hauser
incidents/ # Аварии и их разборы
patterns/ # Повторяемые решения: как подключаем датчики, как оформляем ТЗ
projects/
kotelnaya_2023/
liniya_dozirovaniya_2024/
outputs/
lint-2024-11.md
Папка raw — неприкосновенна. Это источники. Папка wiki — живая база знаний.
Темплейт страницы инцидента
Каждый аварийный останов заслуживает страницы. Вот минимальный шаблон:
---
type: incident
date: 2024-03-11
object: Котельная ул. Строителей, 12
severity: P2
status: resolved
---
# Авария: ложное срабатывание защиты компрессора
## Симптом
Компрессор уходил в E27 при пуске в мороз ниже -12°C. Частота: 3 раза за зиму.
## Диагностика
Уставка реле давления — 3,8 бар. По паспорту компрессора при пуске давление
кратковременно падает до 3,6 бар. Защита срабатывает штатно, но некорректно
для данного применения.
## Причина
Уставка понижена в марте 2023 (см. [[протокол-правки-2023-03]]). Причина
правки задокументирована. Последствие для пуска в мороз — нет.
## Решение
Уставка возвращена на 4,2 бар. Добавлена задержка 8 сек на реле пуска.
## Что изменили в системе
- [[реле-давления-danfoss-rt260]] → обновлена уставка и примечание
- [[регламент-пусконаладки-компрессоров]] → добавлен пункт про зимний пуск
Следующий инженер потратит на понимание этой аварии 10 минут, а не три недели.
Настройка Gemma4 локально через плагин Obsidian
Локальная LLM делает базу знаний интерактивной. Вместо чтения 30 страниц wiki в поисках ответа — задаёшь вопрос, модель читает за тебя.
Gemma4 от Google DeepMind вышла в апреле 2025-го и уже доступна в Ollama. Это мультимодальная модель — понимает текст и изображения, что пригодится, если в базу попадают схемы или фотографии с объекта. Базовая версия e4b весит 9,6 ГБ и работает на видеокарте с 10 ГБ VRAM. Для машин послабее есть e2b — 7,2 ГБ, и через CPU тоже поднимается, просто медленнее.
Шаг 1: Установка Ollama
Ollama — это локальный сервер для LLM. Установка на Windows:
# Скачать установщик с ollama.com, затем:
ollama pull gemma4 # стандарт: 9.6 ГБ, 128K контекст
# или лёгкая версия:
ollama pull gemma4:e2b # 7.2 ГБ, подходит для 8 ГБ VRAM
# Проверить запуск:
ollama run gemma4 "Привет, ты работаешь?"
Сервер слушает на http://localhost:11434. Без интернета, без облака, без токенов. Контекстное окно Gemma4 — 128K токенов, что важно: модель удержит в памяти несколько десятков страниц вики одновременно.
Шаг 2: Плагин Smart Connections в Obsidian
- Obsidian → Settings → Community Plugins → Browse
- Найти Smart Connections (автор: Brian Petro), установить
- В настройках плагина:Chat Model Platform → Ollama
Ollama Endpoint → http://localhost:11434
Model Name → gemma4 (или gemma4:e2b для слабого железа)
Плагин индексирует все .md-файлы в хранилище и передаёт релевантные фрагменты модели как контекст. Альтернатива — Copilot for Obsidian, тот же принцип, чуть другой интерфейс.
Шаг 3: Первый запрос
Открываешь панель чата Smart Connections и пишешь:
Почему компрессор в котельной уходил в аварию зимой?
Модель находит страницу incidents/2024-03-11-avaria-kompressor.md и отвечает:
«Уставка реле давления снижена до 3,8 бар в 2023 году. При пуске в мороз давление падает до 3,6 бар — защита срабатывает. Решение: уставка 4,2 бар плюс задержка 8 секунд на реле пуска.»
Это не магия. Это твоя собственная документация, с которой теперь можно разговаривать.
Как это работает в реальной жизни: INGEST, QUERY, LINT
INGEST: каждый новый документ — в базу
Пришёл PDF с завода — пусконаладочный протокол нового теплообменника. Последовательность действий:
- Кладём PDF в raw/2024_pnr_teploobmennik.pdf — без изменений
- Создаём страницу entities/teploobmennik-SWEP-B25THx40.md
- Записываем: модель, характеристики (мощность 180 кВт, теплоноситель — этиленгликоль 40%), особенности подключения, условия гарантии
- Добавляем ссылки на связанные страницы
- Обновляем log.md: дата, файл, что добавлено
На это уходит 15–20 минут. Зато через год ты задашь вопрос «какой теплообменник стоит в котельной на Строителях и какой у него гликоль?» — и получишь ответ за 30 секунд.
QUERY: задать вопрос базе
Звонит заказчик: «Почему в 2022-м выбрали ОВЕН ПЛК110, а не Siemens?». Открываешь чат Smart Connections:
Почему на объекте 2022 года выбрали ОВЕН ПЛК110?
Если в базе есть страница с этим решением — модель найдёт и объяснит. Если нет — это сигнал: решение не задокументировано. Добавь его сейчас, пока ещё помнишь.
LINT: раз в квартал — проверка базы
Каждые три месяца создаю файл outputs/lint-YYYY-MM.md и прохожу по базе:
- Противоречия. Страница «датчик Endress+Hauser Cerabar M» — рабочее давление до 40 бар. Страница «регламент монтажа» — до 25 бар. Кто прав?
- Сироты. Страницы, на которые никто не ссылается — возможно, устарели
- Пустые ссылки. В тексте есть [[протокол-испытаний-2022]], а файла нет — кто-то забыл создать страницу
LINT занимает час-полтора. После него база становится точнее.
Чек-лист: база готова, если...
- [ ] Новый инженер за 1 час находит, почему выбрали конкретное оборудование
- [ ] У каждого аварийного останова есть страница с причиной и решением
- [ ] Ты можешь задать вопрос своей базе и получить ответ со ссылками
- [ ] Документы хранятся как артефакты, знания — как связанные страницы
- [ ] Ни одно техническое решение не существует только в чьей-то голове
- [ ] Последний LINT нашёл меньше 5 противоречий
Главный критерий прямой: если тебя завтра не будет на объекте, сможет ли следующий инженер за день разобраться в системе по одной только базе? Если нет — база не готова. Не потому что файлов мало. А потому что в ней хранятся файлы, а не решения.
У вас в команде как устроена передача знаний при смене инженера? Папка на диске, корпоративная wiki, устная передача — или что-то ещё? Напишите в комментариях, интересно сравнить практики.