Comments 18
Я как человек, который тоже пытался скормить ИИ огромные заметки и потом ловил странные ответы «не в ту степь», прям понял боль. Особенно понравилась мысль, что агенту мало просто найти похожий текст ему надо понимать роль этого текста в системе. Иначе реально черновик и готовый вывод для него одинаковы. Выглядит уже не как просто RAG, а как попытка сделать нормальную рабочую память для агента.
2730 строчек в одном питон файле, который еще и залит в один репозиторий дважды - добро пожаловать в клуб изобретателей памяти для LLM.
Отличная идея, и применима, видимо, не только к личному архиву. У меня похожая проблема - документация, общая, историческая и рабочая, по достаточно большим софтверным проектам. Дефекты, история принятия решений, текущая архитектура, планы на будущее.. Похоже, это все хорошо ложится на вашу концепцию. Надо будет попробовать!
Вопрос - а можно будет вместо SQLite опционально использовать что-то текстовое, чтоб в Git-e держать?
Благодарю, применение действительно планируется достаточно широкое. Для вашего кейса система отлично подойдёт, главное настроить эталоны под предметную область! Да, можете хранить документацию, связи и метаданные в Git, тогда SQLite будет использоваться как локальный пересобираемый кэш. Если нужен именно текстовый JSONL‑индекс вместо SQLite, то это уже отдельная доработка: нужно добавить text storage backend, сейчас такого переключателя в конфиге нет.
.
Интересно. Одно смущает , почему все до сих пор используют Обсидиан и куча статей про него идет и идет , я нашел более интересный инструмент TrilliumNext , жаль что про него почти нет статей , как по мне на голову лучше Обсидиана.. у меня тысячи заметок , в какой то момент все это дело стало жутко тормозить , поиск даже с плагинами вроде Omnisearch мог повиснуть на секунд 20-30 (и это у меня пк около-топ). А тут я свои заметки перенес в trillium и поиск выдает за секунду , т.к база данных не файловая , а в SQLite. А в плане синхронизации .. развернул на своем vps простой докер контейнер (сервер) и с него синхронизируюсь по токену с любого ПК (телефон не проверял , не пользуюсь) , ну и автобэкапы делает программа.
PS: Уж простите не удержался)) Я подумал про скорость работы и если дать тому же агенту шурудить* тысячи файлов , сколько времени это займет , пока он там будет grep делать и т.п в поисках нужной информации , а тут нужную инфу найдет за секунды.
Слушайте, это интересно будет попробовать. Кажется, Обсидиан популярен не только из‑за интерфейса, а потому что сам формат Markdown популярен. Папка.md файлов остаётся читаемой без приложения, добавляется в Git, её можно обрабатывать любыми скриптами и агентами. TriliumNext, судя по всему, сильнее как приложение‑БД: быстрее поиск, нормальная синхронизация, SQLite, но это уже чуть другая философия хранения.
Обсидиан тоже индексирует все. При поиске не читает все файлы
Лол занимается семантикой но не знает хотя бы двадцать видов связей и лепит вектора на файл
Справедливо, если говорить о действительно зрелой онтологии. Сейчас используется минимальный набор связей и не используются чанки, так как это подходит моей текущей базе. Для MVP этого уже достаточно, чтобы агент перестал смотреть на всю папку целиком, что и было изначальной целью. Ваши замечания в любом случае уже в задачах, спасибо, это логичное продолжение разработки.
У самого есть нечто подобное, внимательно изучу. Спасибо!
Для 2nd Brain (под этим я имею в виду не базу знаний, а систему для поиска и развития инсайтов по цепочке "идея > заметка > проект" ) я остановился на таком шаблоне:
---
date:
type: # enum: idea | note | project
status: # enum: draft | active | drop
priority: # enum: 1 (high) | 2 (medium) | 3 (low)
tags: []
related: [[]]
---
# Title
## Idea or Summary
Коротко: в чем суть 2-3 тезиса
## Why
Почему это важно / к чему ведет
## Context
Откуда это, зачем, при каких условиях
## Next
- [ ] Что с этим делать (или ничего)в вашем шаблоне что заполняет система?
---
type: квант # ядро | паттерн | модуль | квант | артефакт
level: 4 # 0-5; числовой дубль type для алгоритмов
sign: Σ # смысловое ядро/домен: Ψ | Δ | Σ или их смесь
artifact_sign: β # для артефактов/квантов: заметка, лог, гипотеза, источник и т.д.
status: draft # draft | active | superseded | drop
tags: []
parents: []
parents_meta:
- entity: NOUZ
link_type: hierarchy # hierarchy | semantic | temporary
---Type и level по сути дублируются для удобства чтения обеими сторонами. Я один раз назначаю семантические ядра, определяю иерархию, допустимые связи. Агент заполняет YAML, обозначает теги, определяет тип связи, ищет семантические мосты, классифицирует роль материала, показывает дрифт (если заметка или её дочерние заметки съезжают по смыслу от заданного ядра). Текст заметки без явного указания система не трогает. Возьму вашу идею с приоритетом, этого не хватает.
Спасибо, надо будет затестить ваш MCP, как раз не хватает автосвязей. Ядра и дрифт отличная идея. Интересно посмотреть как будет работать дрифт, если ядра заданы не как крупные независимые домены, а как взаимосвязанные кластеры внутри одного тематического домена или как разные домены но с прикладными пересечениями. Priority у меня закрывает тайм-менеджмент, точнее матрицу принятия решений, заодно делает сортировку в дашборде Obsidian.
Как я превратила Obsidian в структурированную память для ИИ‑агентов