Код в мешке
250 subscribers
8.94K photos
1.58K videos
2.11K files
42.1K links
Код в мешке - про кодинг, и не только...
Это личная записная книжка

https://t.me/joinchat/AAAAAEIy6oGlr8oxqTMS5w
Download Telegram
Forwarded from Ivan Begtin (Ivan Begtin)
Я [не так уж] недавно озадачился темой баз знаний и баз документов для работы с ИИ да и без него тоже и не то чтобы в восторге от того что есть в практическом использовании. Если посмотреть на то как об этом думают другие, например, Andrey Karpathy в его тексте LLM Knowledge Bases то там речь про связку Obsidian как личный инструмент редактирования и набор инструментов по поиску и обогащению материалов с помощью LLM.

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

Какие есть еще варианты связок редактор/интерфейс, LLM и тд. ?

Самый очевидный воспользоваться каким-нибудь Notion где AI встроен можно сказать естественным образом.

Есть еще OpenKB на базе PageIndex в котором вообще нет UI интерфейса, но есть возможность делать запросы с командной строки. Веб интерфейс это не проблема, можно поднять один из Markdown wiki продуктов вроде Docusaurus, но сам подход выглядит так:
добавляешь документ в любом формате -> он преобразуется в Markdown -> Markdown индексируется в базу знаний - > можно задавать вопросы естественным языком.

Карпатый в своих рассуждениях еще упоминал qmd любопытный тул как раз для такой базы знаний.

Я про все это тоже думаю, сразу в контексте 3-х близких задач:
1. Личная база знаний, которая у меня как и у многих на базе Obsidian и к которой хотелись бы LLM возможности что называется из коробки, а не через разные *Claw.
2. База знаний для работы доменных экспертов когда есть пул специалистов в предметной области и они готовят материалы для обучения LLM под предметную область какой бы она ни была (кулинария, юриспруденция, поэззия и тд). Тут идеально если есть Вики инструмент, на том же Markdown'е. И в который раз можно лишь посетовать про дефицит структурированных вики, хотя есть тот же Outline.
3. Хранилище документов под очень большие объёмы, условно в миллионы документов, с тем что документы могут быть разного типа с разными профилями метаданных и также подключаемыми. У этого есть разные решения, от технических, все метаданные в индекс OpenSearch, а профили описывать в разными схемами в YAML, до концептуальных через создание онтологии и использование институциональных репозиториев вроде Hyrax, DSpace, Islandora и тд. Институциональные репозитории и библиотечные системы далеки очень от инженерных паттернов и не факт что это лучшее решение.

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

#thoughts #ai #documents
Forwarded from Ivan Begtin (Ivan Begtin)
Почему я задумался про LLM Knowledge base и работу с базами знаний через LLM? У меня есть какое-то, немало количество материалов собранных из большого числа небольших записок и недописанных книг. Эти книги, изначально в формате лонгридов и страниц для Gitbook'а можно назвать существенными кусками (ядром) того что можно назвать доменной базой знаний, в понимании домена как очерченной предметной области.

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

Идеальный инструмент - это продукт работающий локально на компьютере или в локальной сети, позволяющий вносить знания по предпопределенным профилям и шаблонам, с визуальным редактированием и совместной работы от 5 редакторов. Самое очевидное тут Mediawiki/Wikibase, с оговоркой что там внутри не Markdown, что там очень консервативное API и интеграции, и с не менее консервативными инструментами метаописания и редактирования.

Тут я вспомнил что есть и другой путь. Переводить все документы в YAML и формировать их структурированными блоками. YAML/TOML файлы значительно проще редактировать сохраняя структурную целостность, заполняя метаданными и так далее, а конвертация в Markdown может быть автоматической/автоматизированной.

Это неидеальный сценарий поскольку он требует редактирования базы знаний в IDE, а не визуальном редакторе и такой редактор надо делать (что не так сложно с помощью генеративных LLM).

#thoughts #knowledge
Исковая давность по дебиторской задолженности: как считать, не пропустить и использовать в свою пользу #habr
https://habr.com/ru/articles/1032330/
Tags: срок исковой давности дебиторка, взыскание дебиторской задолж, пропуск срока исковой давн, прерывание исковой давности, приостановление исковой давн, дебиторская задолж взыскание, срок взыскания долга, арбитражный суд дебиторка, списание дебиторской задолж
Author: ddconsult
Полный гайд по dunder-методам в Python (от новичка до профи) #habr
https://habr.com/ru/articles/1033432/
Tags: ython, ООП, dunder-методы, магические методы, метапрограммирование, дескрипторы, итераторы, генераторы, контекстные менеджеры, Python 3
Author: enamored_poc
Кто автор программы: разбираю каждую роль в команде с судебной практикой #habr
https://habr.com/ru/articles/1033482/
Tags: программы для ЭВМ, авторство, творческий вклад, интеллектуальная собственность, авторское право, соавторство, архитектор программного обеспечения, графический интерфейс, служебное произведение, судебная практика
Author: aveazazello