стартап "Anthropic" запускался как исследовательская группа по созданию understandable AI, кажется и термин этот они придумали. Возможно, тоже сначала думали, что быстро на линейной алгебре всё порешают, там же математика уровня 2 курса бакалавров, просто никто не брался
я смотрел на него, но для AlloyDB нет готового рсширения apache age. Возможно, это политика гугла, и на голый postgres оно ставится, но я решил вообще пока не заморачиваться с графовыми запросами, а посмотреть как это работает на чисто реляционных отношениях. Эта субд хвалится новыми индексами, хочется понять, что там на самом деле происходит
вообще правильнее было бы делать полноценные triples subject-predicat-object на входе и писать классическую онтологию, но это уже вообще другая задача. Здесь связи классифицируются только чтобы расставить веса для ранжирования выдачи, и эти веса не вносят очень большого вклада. Больше урона здесь наносит то, что все связи направленные, а функция классификации выбирает концепты как source и target в порядке их следования, и только потом начинает классифицировать связи между ними конечным списком классов отношений. То есть, если название технологии попадет в source а автор попадет в target, то связь "authored_by" там ляжет правильно, а если они зайдут в функцию наоборот, то связи "author_of" там нет. Ну это всё будем допиливать, пока и так ищется, просто хопов в контекст попадает больше, токены лишние тратятся
Да, именно так — двухэтапный retrieval. Вот механика:
Seed: Запрос - эмбеддинг - cosine similarity находит top-K (стоит хардкодом 5) страниц из graph_nodes. Это seed-ноды.
Hop : Каждая seed-нода раскрывается через graph_edges — прямые соседи (hop1) и соседи соседей (hop2). Глубина по умолчанию 1.
Дедупликация: SELECT DISTINCT ON (wp.path) — если одна и та же страница пришла и как seed, и как hop, остаётся seed (приоритет по relevance: seed > hop1 > hop2).
Веса: заранее заданная таблица внутри SQL-функции:
Да, именно так — двухэтапный retrieval. Вот механика:
Seed: Запрос - эмбеддинг - cosine similarity находит top-K (стоит хардкодом 5) страниц из graph_nodes. Это seed-ноды.
Hop : Каждая seed-нода раскрывается через graph_edges — прямые соседи (hop1) и соседи соседей (hop2). Глубина по умолчанию 1.
Дедупликация: SELECT DISTINCT ON (wp.path) — если одна и та же страница пришла и как seed, и как hop, остаётся seed (приоритет по relevance: seed > hop1 > hop2).
Веса: заранее заданная таблица внутри SQL-функции:
steering vector, не стирлинг. Правдоподобность вы, конечно, уронили, учитывая, что это пересказ статьи от авторов метода с описанием результатов применения
Вроде заработало. Я с ним давно вожусь, и это было прямо больно -- через впн к моделям обращаться с большим контекстом. А недавно случайно зашел без впн и оно работает. Уже несколько дней работает, не знаю как будет дальше
качество ответов зависти от модели LLM. Здесь на SQL сохраняется онтология фактов, причем делается это для того, чтобы сохранять факты, которых нет в интернете, а следовательно нет в памяти модели. Так что сравнивать "с памятью -- без памяти" вообще не получится. Система будет предсказуемо галлюцинировать о тех вещах, которых не знает. Измерять можно качество ответов существующей базы знаний и вновь создаваемой. А тут существующей базы по моим фактам еще нет. Следующую версию уже будет с чем сравнивать
Ой, только заметил, у меня опечатка: " чем меньше угол, тем больше расстояние между точками в семантическом пространстве". Правильно будет , чем меньше значение косинуса, тем больше косинусное расстояние, тем меньше они похожи.
Все правильно, на гитхабе есть скрипт на SQL для создания базы. Но я не пробовал его на стандартном postgres, а в AlloyDB уже встроены нужные расширения, там есть индексы для поиска приблизительным ближайшим соседям, которых не будет в postgres. AlloyDB Omni опенсорс, ставится на локальную машину, никаких проблем с ним нет, но его надо сначала ставить. А в скилл добавлять установку СУБД так себе идея)
почему не косинус, это косинус. косинусное расстояние вычисляется по формуле . Значок `<=>` -- это косинусное расстояние -- чем меньше угол, тем больше расстояние между точками в семантическом пространстве, тем они меньше похожи. Там в скриптах на гитхабе прописано (1 - (f.embedding <=> query_embedding)), это более привычный подход: чем больше число, тем больше сходство. Поэтому 0.84 -- это большое сходство.
добавил
стартап "Anthropic" запускался как исследовательская группа по созданию understandable AI, кажется и термин этот они придумали. Возможно, тоже сначала думали, что быстро на линейной алгебре всё порешают, там же математика уровня 2 курса бакалавров, просто никто не брался
добавил
я смотрел на него, но для AlloyDB нет готового рсширения apache age. Возможно, это политика гугла, и на голый postgres оно ставится, но я решил вообще пока не заморачиваться с графовыми запросами, а посмотреть как это работает на чисто реляционных отношениях. Эта субд хвалится новыми индексами, хочется понять, что там на самом деле происходит
Добавил.
Интересно, а как получилось, что у меня два ваших аккаунта в гитхабе отображается на один ник?
вообще правильнее было бы делать полноценные triples subject-predicat-object на входе и писать классическую онтологию, но это уже вообще другая задача. Здесь связи классифицируются только чтобы расставить веса для ранжирования выдачи, и эти веса не вносят очень большого вклада. Больше урона здесь наносит то, что все связи направленные, а функция классификации выбирает концепты как source и target в порядке их следования, и только потом начинает классифицировать связи между ними конечным списком классов отношений. То есть, если название технологии попадет в source а автор попадет в target, то связь "authored_by" там ляжет правильно, а если они зайдут в функцию наоборот, то связи "author_of" там нет.
Ну это всё будем допиливать, пока и так ищется, просто хопов в контекст попадает больше, токены лишние тратятся
пригласил
согласен. Хотя рекурсивные запросы на SQL тоже не легкое чтение
Да, именно так — двухэтапный retrieval. Вот механика:
Seed: Запрос - эмбеддинг - cosine similarity находит top-K (стоит хардкодом 5) страниц из
graph_nodes. Это seed-ноды.Hop : Каждая seed-нода раскрывается через
graph_edges— прямые соседи (hop1) и соседи соседей (hop2). Глубина по умолчанию 1.Дедупликация:
SELECT DISTINCT ON (wp.path)— если одна и та же страница пришла и как seed, и как hop, остаётся seed (приоритет по relevance: seed > hop1 > hop2).Веса: заранее заданная таблица внутри SQL-функции:
Rank:
rank_score = similarity × edge_weight / (depth + 1). У seed-нод rank = чистый cosine (edge_weight=1, depth=0). У hop-нод — discount по типу ребра и глубине.Контент для LLM: страницы, обрезанные по relevance:
Общий лимит
max_chars =8000 символов на весь результат.seed:
left(content, max_chars / top_k)hop1: 500 символов
hop2: 200 символов
Если нужен код, скажите ваш гитхаб аккаунт, я вас добавлю
Да, именно так — двухэтапный retrieval. Вот механика:
Seed: Запрос - эмбеддинг - cosine similarity находит top-K (стоит хардкодом 5) страниц из
graph_nodes. Это seed-ноды.Hop : Каждая seed-нода раскрывается через
graph_edges— прямые соседи (hop1) и соседи соседей (hop2). Глубина по умолчанию 1.Дедупликация:
SELECT DISTINCT ON (wp.path)— если одна и та же страница пришла и как seed, и как hop, остаётся seed (приоритет по relevance: seed > hop1 > hop2).Веса: заранее заданная таблица внутри SQL-функции:
Rank:
rank_score = similarity × edge_weight / (depth + 1). У seed-нод rank = чистый cosine (edge_weight=1, depth=0). У hop-нод — discount по типу ребра и глубине.Контент для LLM: страницы, обрезанные по relevance:
Общий лимит
max_chars =8000 символов на весь результат.seed:
left(content, max_chars / top_k)hop1: 500 символов
hop2: 200 символов
Если нужен код, скажите ваш гитхаб аккаунт, я вас добавлю
steering vector, не стирлинг. Правдоподобность вы, конечно, уронили, учитывая, что это пересказ статьи от авторов метода с описанием результатов применения
а, я понял, спасибо, исправлю
все картинки из оригинальной статьи
https://transformer-circuits.pub/2026/nla/#misreported-tool-calls
но у OpenClaw уже есть десктоп под MacOS, и голосовой интерфейс тоже реализован
Вроде заработало. Я с ним давно вожусь, и это было прямо больно -- через впн к моделям обращаться с большим контекстом. А недавно случайно зашел без впн и оно работает. Уже несколько дней работает, не знаю как будет дальше
качество ответов зависти от модели LLM. Здесь на SQL сохраняется онтология фактов, причем делается это для того, чтобы сохранять факты, которых нет в интернете, а следовательно нет в памяти модели. Так что сравнивать "с памятью -- без памяти" вообще не получится. Система будет предсказуемо галлюцинировать о тех вещах, которых не знает. Измерять можно качество ответов существующей базы знаний и вновь создаваемой. А тут существующей базы по моим фактам еще нет. Следующую версию уже будет с чем сравнивать
На чем перфоманс, на сервере VPS c 8Гб ОЗУ с пингом в 150мс? С клиента, который к LLM через впн ходит? Ну вот потому наверное и не сравнил
Ой, только заметил, у меня опечатка: " чем меньше угол, тем больше расстояние между точками в семантическом пространстве". Правильно будет , чем меньше значение косинуса, тем больше косинусное расстояние, тем меньше они похожи.
Все правильно, на гитхабе есть скрипт на SQL для создания базы. Но я не пробовал его на стандартном postgres, а в AlloyDB уже встроены нужные расширения, там есть индексы для поиска приблизительным ближайшим соседям, которых не будет в postgres. AlloyDB Omni опенсорс, ставится на локальную машину, никаких проблем с ним нет, но его надо сначала ставить. А в скилл добавлять установку СУБД так себе идея)
почему не косинус, это косинус. косинусное расстояние вычисляется по формуле
. Значок `<=>` -- это косинусное расстояние -- чем меньше угол, тем больше расстояние между точками в семантическом пространстве, тем они меньше похожи.
Там в скриптах на гитхабе прописано
(1 - (f.embedding <=> query_embedding)), это более привычный подход: чем больше число, тем больше сходство. Поэтому 0.84 -- это большое сходство.