VibeVM и дискуссия у меня в чате телеграма об “оптимальном для LLM доступе к знаниям”
Этот пост можно назвать по-разному, ибо в нём клубок вечно повторяющихся тем:
- Ваш рубрикатор готов к прошлой войне
- Как найти знание, которое не догадался искать
- Сжать знания и не выжать из них смысл
- Знаний много. Разного доступа к ним мало
- Ленивая загрузка для неленивого мышления
- Библиотека (Конгресса, FPF) большая, а контекст у нас маленький
- Больше входов в знания – хороших и разных!
Олег Чирухин сделал VibeVM как менеджер пакетов с ленивой подгрузкой для корпусов знаний в LLM. Библиотека FPF – именно такой “корпус знаний”: знания о мышлении и действии в формате языка паттернов, почти 30 MB, 834 паттерна с предисловиями и пояснениями (выгрузить файлами – GitHub - ailev/FPF: First Principles Framework (FPF): AI-native pattern languages for systems engineering, research and management. Shared human-AI reasoning for architecture decisions, evidence, trade-offs and method engineering. FPF Core and domain frameworks (DPFs). · GitHub, полистать глазами и поиск – https://fpf.tools). Это идеально укладывается в его постановку задачи, и он просто компилирует это для LLM в одну строчку запроса “vibe install ai.lev/fpf” – Telegram: View @tg_1red2black. Я перепостил это к себе в канал телеграма, и в чате случилась большая дискуссия про доступ к корпусам знаний (Telegram: View @ailev_blog_discussion, не вся дискуссия видна из комментов в канале, а при входе в чат аккуратней – спаморезка банит сразу всех без telegram username, как раньше говорил, coward anonymous). Мой комментарий – “больше доступов к корпусам знаний хороших и разных, в том числе хороших и разных доступов к библиотеке FPF”. Вариант там – “больше сжималок хороших и разных, для разных целей”. В чате там обсуждались аналогичные работы, у меня даже есть страница на новом сайте библиотеки FPF для подобных разработок (русскоязычные туда не вошли, пока на сайте только те, кто хоть что-то написал на английском, таких портов оказалось восемь, не включая моих собственных): Uses and community projects, Uses and community projects · fpf.tools.
Я там отмечал сложность проблемы (ибо я уже писал на эту тему много раз, занимался этим много лет) и обещал сделать пост. Вот этот пост и есть, но вместо того, чтобы много писать руками, я даю:
- обзор по тематике, включающий теорию доступа к динамически меняющимся корпусам знаний, практические реализации и их опыт, советы по тому, как это сделать для FPF – ниже постановка задачи и основные выводы (начало файла), но также доступен и полный текст для всех 98K знаков, FPF_Library_situational_retrieval_Jev_2026-10-02-2.md — Яндекс Диск. Исследование сделалось по одному и тому же промпту в Astra Pro и Astra Pro DeepResearch, затем результат Astra Pro был дополнен идеями и источниками из результата Astra Pro DeepResearch, а итоговый файл почищен по F.19 (кто пробовал, тот поймёт) и переструктурирован, чтобы чётче отделять общую теорию и инженерную практику, выделять специфику экосистемы FPF. Промпт задачи на исследования публикую ниже, он короткий, но обратите внимание: там ссылки на мои предыдущие работы по этому направлению – тут как раз тот случай “пять минут на решение задачи, но перед этим вся жизнь”.
- Но как человек ответственный, я довожу исследование до применения (если нет применения, исследование можно было бы и не проводить). Поэтому я дал это на вход конвейеру модификации библиотеки FPF. Последние изменения по архитектуре этой библиотеки были реализованы вчера, так что решение (DRR) было принято быстро: F.1 должен работать даже с бумажным архивом, без RAG и LLM. Отдельный DPF отвечает за индексы, обновления, доставку контекста и проверку всей системы доступа – Knowledge-Corpus Access Engineering DPF. Часть E не получает обязательной зависимости от этого DPF и реализует специфику экосистемы FPF, ещё какие-то специфические моменты будут реализованы в LPF и поддержаны инструментарием для внутреннего проекта работы с корпусами знаний (тут ещё вопрос, только ли с библиотекой FPF, или у нас есть и другие корпуса знаний, из которых надо что-то брать, например, дюжина наших руководств, R0-R11). Архитектурное решение шло примерно два часа, дальше реализация (тексты паттернов, проверки, выпуск), она ещё впереди, оптимистичный прогноз – завтра к вечеру уже будет готово. Полный текст промпта для выработки этого решения даю ниже постановки задачи и итогов.
Промпт задания на исследование
У нас в FPF инструкция говорит, что пользователям для работы с FPF Library надо использовать rg, ибо это самое быстрое и мощное, а также самое простое и доступное для Codex, Claude и подобных.
Посмотри решения вроде codegraph с динамической реиндексацией исходников и выводом возможных связей. В исследованиях часто оказываются лучше, чем “только греп” или LSP.
Нам это как-то может помочь?
Вообще, это всё связано с проблемой инструмента нахождения паттернов. Когда пользователь сталкивается с проблемой, которая уже есть в паттернах, нужные паттерны надо найти, а на это нельзя тратить много контекста в поиске. У тебя на странице fpf.tools/in-use есть попытки решения этой проблемы: порубить всё на отдельные паттерны и вход устроить на компактном наборе skills, компиляторы вроде VibeVM с ленивой подгрузкой необходимого (там будут доработки в эту сторону), решения для динамической реиндексации, ибо некоторые тексты (базы кода, библиотека FPF) могут быстро меняться по ходу использования, есть варианты просто “ограничиться некоторыми самыми частыми запросами”.
Тут есть осложнения:
- Пользователь не знает, что FPF ему может помочь, поэтому инструмент тут должен быть проактивен. Он должен замечать, что у пользователя проблема, а в библиотеке FPF (в общем случае – в корпусе знаний) есть решение. Простейшее – это какие-то векторные поиски, чтобы искать “по ассоциации”, но не факт, что это сработает. Интересней могло бы быть использовать что-то вроде Jev, но у нас довольно много паттернов, непонятно, как получить вероятности на столько таксонов (и даже на комбинацию этих таксонов, потому что решение иногда в применении нескольких паттернов). Посмотри вообще на тематику Jev, последнюю неделю это обсуждается более чем активно. Мне кажется, что там может быть какое-то интересное соответствие того, что там говорится и решения для чего приводятся, и того, что требуется нам.\
- Пользователь знает, но запрос у него в терминах его предметной области, что может полностью отличаться от онтологии, методологии, языка из корпуса знаний.\
- Более серьёзные возражения – это считать, что мы что-то хорошо прорубрицировали или сжали понятным способом. Если обратиться к формализму для выражения этих “дальних абстракций” (дальних по предметам/дисциплинам/теории или дальним во времени разговора и/или мышления), то будет засада: важные для одних вопросов связи и абстракции оказываются абсолютно неважными для других вопросов. Поэтому:
а) IBM Watson для Jeopardy! (это 2011, Подробности матча IBM Watson в Jeopardy!: ailev — ЖЖ) исключительно полнотекстовыми материалами пользовался, ничего не кодировал в “граф знаний” – любая обработка могла отсечь какую-то информацию (в том числе информацию по собственно тексту: в вопросах же часто была игра слов! Поэтому от оригинальных текстов отказываться было принципиально нельзя. Кодирование в соответствии с какой-то foundational и upper ontology могло запросто бы отсечь важную для какого-то вопроса информацию, поэтому ничего не кодировалось, а для полнотекстовой работы использовали суперкомпьютер, чтобы полнотекстовая работа происходила в приемлемое время).
б) все эти “каталоги” и “фолксономии” вымерли, ибо через пять лет после создания вся система рубрикации умирает – отстаёт от текущих соображений по организации знания. Выживают не каталоги и рубрикаторы, выживает только полнотекстовый поиск. То, что казалось важными отношениями 5 лет назад, полностью теряет свою значимость, и на передний план выступают совсем другие отношения, запросы идут на совсем другую тему, и “рубрикация” и “классификация” прежних лет оказываются не помогающими что-то найти и что-то вспомнить, а, наоборот, не пускающими что-то найти из важного в текущей ситуации, предлагающими находить важное в предыдущих ситуациях. Жёсткая рубрикация-онтологизация помогает выигрывать всегда в прошлой войне, хотя этот выигрыш обычно и крайне эффективен по ресурсам. Искать же новое нужно всегда мимо рубрикаторов, мимо предметных онтологий. Если вы писали и рубрицировали текст, будучи погружёнными в одну деятельность, в рамках одной онтологии, то запрос может прийти из совсем другой деятельности, другой онтологии – и вы тут пропадёте, хотя вся необходимая для ответа на запрос информация в тексте будет. Но она пропадёт при сжатии ситуации, или картинки, или текста, при формализации, при создании по ситуации, или картинке, или тексту модели. Модель, схема, онтология – это всегда неполнота, это всегда акцент на “важном” для какой-то деятельности и потеря важного для другой деятельности.\
Поэтому храним оригинальную неформальную информацию (ну, может быть, сжимаем её по-коннективистски или байесовски, а не формализацией в дискретную логическую форму), связи же устанавливаем динамически – через доступные нам абстракции (уж как можем), какие-то нейропредставления (векторы) или ещё как-то. Ну и формальную информацию (онтологии, паттерны) используем по возможности тоже не слишком формально, всё на естественном языке и нейросетях – всё одно для этой формальности в какой-то момент наступает предел, достоинства переходят в недостатки, простота и точность рассуждения (reasoning, формального вывода) по модели оборачиваются несоответствием вывода и реальности, ибо вывод в разных алгебрах несовместим, а реальность неизбежно описывается разными алгебрами.
4. Интеллект всё-таки связан с возможностью сжатия информации, поэтому что-то всё-таки надо поджимать – подробней в Жми, господь!: ailev — ЖЖ
5. У тебя ещё могут быть соображения, как всё это увязать в нашем проекте, какие идеи использовать, как это усилить, какое оригинальное решение предложить.
Отчёт делай в .md
Постановка задачи и основные выводы итогового отчёта (merge двух начальных вариантов, F.19 и переструктурирование по уровням заземления)
Извлечение знаний из изменяющихся корпусов и подбор методов FPF Library
Состояние исследований и документации — 2 октября 2026 года.
Постановка задачи и основные выводы
Большой корпус знаний приносит пользу, когда человек или AI-агент может вовремя найти в нём материал для своей работы. Наличие полнотекстового поиска решает только часть этой задачи. Пользователь может не подозревать, что в корпусе есть подходящий метод, описывать ситуацию на другом профессиональном языке или нуждаться в сочетании нескольких методов. При этом содержание корпуса и сама рабочая ситуация меняются, а поисковые попытки расходуют время, вычисления и ограниченное контекстное окно модели — объём материала, который она получает при очередном обращении.
Исследование отвечает на вопрос, как находить полезное знание при этих условиях, не заменяя исходные тексты единственной классификацией и не заполняя основное окно агента историей поиска. Рассматриваются полнотекстовый и векторный поиск, графы связей, динамическое обновление индексов, выборочная загрузка источников и модели для оценки найденных кандидатов. Особое внимание уделяется Jev — модели TypeSafe, возвращающей оценки по заданным вопросам и вариантам ответа. S01, S02
Прикладная задача — подбор методов в FPF Library, библиотеке публикаций проекта First Principles Framework (FPF). Она включает трансдисциплинарное ядро FPF Core, предметные языки паттернов — Domain Principle Frameworks, или DPF, — их тематические комплекты Suites и справочные публикации References. Паттерн описывает повторяющееся затруднение, способ работы с ним и условия применения. References, предисловия и примеры помогают связать несколько таких способов. Паттерн и описанный в нём метод различаются: найти текст ещё не значит выполнить метод и получить его результат. F01, F02, F03
В инструкции FPF для поиска предлагается rg — ripgrep, инструмент поиска строк по текстовым файлам, — либо эквивалентное средство среды. Это доступный способ найти известный идентификатор паттерна, термин или точный фрагмент. Инструкция также допускает другие поисковые системы, требует учитывать ситуацию и нужный результат, переформулировать запрос и читать условия выбранного метода. Поэтому задача развития инструментария состоит не в отмене rg, а в поддержке тех действий, которые буквальный поиск сам не выполняет. F01
Особая трудность связана со сжатием. Рубрика, краткое описание, вектор и граф выделяют различия, полезные для некоторых вопросов. Новому вопросу может понадобиться именно то, что такое представление отбросило. Сохранение оригиналов необходимо, но недостаточно: система должна позволять искать по ним без обязательного совпадения с рубрикой или кратким описанием. Вместе с тем читать весь корпус при каждом обращении слишком дорого. Нужны быстрые способы поиска и отдельный, избирательно используемый способ выйти за пределы их предположений.
Основная рекомендация — сохранить исходные публикации и развивать несколько независимых способов доступа к ним. Лексический поиск находит совпадения выражений. Векторный поиск и альтернативные формулировки помогают при несовпадении языка. Структура публикаций обеспечивает точное чтение. Модель-оценщик оценивает, стоит ли изучить найденный материал подробнее. Смысловые связи, важные для конкретной работы, устанавливаются после появления вопроса и пересматриваются при изменении оснований.
Для FPF результатом должен быть не список похожих паттернов, а обоснованный выбор метода или небольшой подборки методов. Нужно показать, какой результат даст каждый метод, для чего он нужен в работе пользователя, какие условия ещё не установлены и могут ли выбранные методы применяться совместно. Проактивное предложение требует дополнительного решения: оправдывает ли ожидаемая польза отвлечение пользователя и изменение его работы.
Jev представляет интерес как сменяемый исполнитель ограниченных оценок после предварительного поиска и при прямом просмотре текста. Исследования дают основания испытывать такую роль, но не устанавливают надёжность Jev как единственного классификатора всех паттернов и их сочетаний. Его вероятности требуют проверки на конкретной задаче; качество ранжирования, пригодность порога и согласованность нескольких вероятностей — разные свойства. S07, S11, S12, S13, S14
Численные результаты относятся к опубликованным испытаниям на указанных наборах данных. Предлагаемая система подбора методов на корпусе FPF не реализована и не испытана в рамках этого исследования. Её настройки и ожидаемые улучшения являются проектными гипотезами. Датировки источников и версии моделей ограничивают применимость приведённых результатов.
| Часть отчёта | Что она позволяет решить |
|---|---|
| I. Общие подходы к извлечению знаний, разделы 1–6 | Какие представления и инструменты можно сочетать, что подтверждают исследования и как сохранить источники при ограниченных расходах. |
| II. Выбор паттернов и их подборок в FPF Library, разделы 7–14 | Какие дополнительные проверки нужны для применимости, совместного использования и своевременного предложения методов; какую систему строить и как её испытывать. |
Ссылки [F…] ведут к материалам FPF, [S…] — к исследованиям и документации инструментов в разделе «Источники».
[далее полный текст, всего 98K знаков, повторю где брать: FPF_Library_situational_retrieval_Jev_2026-10-02-2.md — Яндекс Диск]
Промпт, по которому были запущены изменения в библиотеке FPF
Вот новый intake, поставь новую пару агентов с этим разбираться – [имя файла на моём диске]
Там надо или отдельно делать DPF по доступу к корпусам знаний в целом (теория вопроса) и инженерии доступа для текущего поколения harness для LLM (RAG, skills, динамическое индексирование, ленивые подгрузки вроде VibeVM и т.д.), но ещё ведь есть и прямые рекомендации, как это реализовать для библиотеки FPF (и шире – экосистемы FPF) в инсталляциях у пользователей. Поэтому есть архитектурная проблема: если делать в DPF “как это вообще”, а потом говорить об экосистеме в части E, то это будет обратная зависимость FPF (Core) от доменного знания, что архитектурно вроде у нас пока запрещено. Но если там сделать развёрнутые паттерны и опереться на них, то можно всё и прямо внутри FPF решить (ибо доступ к корпусам знаний вроде как трансдисциплинарный domain, общеприменимая штука). Дальше надо прописать следствия этих общих паттернов про корпуса знаний в части E в паттернах, которые говорят об организации доступа к корпусам (языкам) паттернов, в том числе паттернам экосистемы FPF. И, наконец, добавить какие-то следствия и программу работ по развитию инструментария в нашем LPF.
Конечно, это всё хорошо бы сделать в тот момент, когда архитектура библиотеки FPF уже достаточно определена, чтобы принимать архитектурное решение по размещению паттернов этой кампании по изменяющимся корпусам знаний и подбору паттернов FPF Library на базе уже как-то устаканенной архитектуры. Возможно, надо сделать дополнительную пару агентов, чтобы не тянуть с этим, увеличить число одновременно работающих в параллель агентов (разрешаю это сделать).
Что происходит прямо сейчас
- Я пишу этот пост, и участники обсуждений в чате блога получат текст исследования (я там обещал, вот выполняю).
- Агенты реализуют готовый DRR: один переписывает F.1, дополняя его поиском в корпусах знаний (работа со знаниями – прямой вопрос части F), другой агент работает с инженерией доступа в DPF, координатор готовит агентов для правок в части E (там про экосистему FPF), и, пока это всё не пройдёт, правок в LPF и нового инструментария предложено не будет.
