Вроде заработало. Я с ним давно вожусь, и это было прямо больно -- через впн к моделям обращаться с большим контекстом. А недавно случайно зашел без впн и оно работает. Уже несколько дней работает, не знаю как будет дальше
качество ответов зависти от модели LLM. Здесь на SQL сохраняется онтология фактов, причем делается это для того, чтобы сохранять факты, которых нет в интернете, а следовательно нет в памяти модели. Так что сравнивать "с памятью -- без памяти" вообще не получится. Система будет предсказуемо галлюцинировать о тех вещах, которых не знает. Измерять можно качество ответов существующей базы знаний и вновь создаваемой. А тут существующей базы по моим фактам еще нет. Следующую версию уже будет с чем сравнивать
Ой, только заметил, у меня опечатка: " чем меньше угол, тем больше расстояние между точками в семантическом пространстве". Правильно будет , чем меньше значение косинуса, тем больше косинусное расстояние, тем меньше они похожи.
Все правильно, на гитхабе есть скрипт на SQL для создания базы. Но я не пробовал его на стандартном postgres, а в AlloyDB уже встроены нужные расширения, там есть индексы для поиска приблизительным ближайшим соседям, которых не будет в postgres. AlloyDB Omni опенсорс, ставится на локальную машину, никаких проблем с ним нет, но его надо сначала ставить. А в скилл добавлять установку СУБД так себе идея)
почему не косинус, это косинус. косинусное расстояние вычисляется по формуле . Значок `<=>` -- это косинусное расстояние -- чем меньше угол, тем больше расстояние между точками в семантическом пространстве, тем они меньше похожи. Там в скриптах на гитхабе прописано (1 - (f.embedding <=> query_embedding)), это более привычный подход: чем больше число, тем больше сходство. Поэтому 0.84 -- это большое сходство.
В скилле сидят строки подключения к SQL, и он подключается к уже созданной базе, так что выложить в таком виде я его не могу. А на github лежит весь проект со скриптами создания базы, правда, для AlloyDB Omni. это PostgreSQL от Гугла. Он opensource, я его на слабую виртуалку поставил в докере, его можно локально ставить себе на linux
Бот написал себе скилл, в котором прописана строка подключения к AlloyDB, скрипт на Python и инструкция по запуску в markdown. Когда я ему говорю что-то типа "занеси ключевые факты из такой-то статьи в omni-memory", он другим скиллом читает статью, выделяет там то, что посчитал интересным и отправляет в этот скилл, в котором абзац разбивается на subject->predicat->object и уже в виде json отправляется в базу.
Чтение статьи и выявление фактов не отлажено и пока больше похоже на аттракцион, потому что факты из статьи он выбирает довольно своеобразно. Но это всё допиливается. Сам скилл, если ему передать конкретный факт, отрабатывает хорошо.
В общем, векторные базы знаний, как я понял -- это тот же SQL, только с векторным поиском. И если в SQL уже всё для этого встроено, то для предприятий он будет удобнее, у них уже есть оплаченные сервера и готовые специалисты, там доучиться надо совсем немного
Попробуйте везде где возможно поменять мультиагнтность на одного агента с несколькими скиллами. Тогда агент будет работать с одним контекстом, сохраняя состояние.
Извините, может быть вы уже использовали этот трюк, но вторая половина статьи у вас - нередактированная генерация, я не могу это читать
Судя по формату входных данных, DeepSeek-OCR спилена у Google, я в Gemini API такие промпты писал. И Gemini как раз читает документы этих форматов: pdf, doc и картинки. Возможно, DeepSeek-OCR -- это урезанная Gemma 3 4B. Только у Gemma контекст 128K. Я ее тоже на 24GB GPU ставил и тюнил
Вроде заработало. Я с ним давно вожусь, и это было прямо больно -- через впн к моделям обращаться с большим контекстом. А недавно случайно зашел без впн и оно работает. Уже несколько дней работает, не знаю как будет дальше
качество ответов зависти от модели LLM. Здесь на SQL сохраняется онтология фактов, причем делается это для того, чтобы сохранять факты, которых нет в интернете, а следовательно нет в памяти модели. Так что сравнивать "с памятью -- без памяти" вообще не получится. Система будет предсказуемо галлюцинировать о тех вещах, которых не знает. Измерять можно качество ответов существующей базы знаний и вновь создаваемой. А тут существующей базы по моим фактам еще нет. Следующую версию уже будет с чем сравнивать
На чем перфоманс, на сервере VPS c 8Гб ОЗУ с пингом в 150мс? С клиента, который к LLM через впн ходит? Ну вот потому наверное и не сравнил
Ой, только заметил, у меня опечатка: " чем меньше угол, тем больше расстояние между точками в семантическом пространстве". Правильно будет , чем меньше значение косинуса, тем больше косинусное расстояние, тем меньше они похожи.
Все правильно, на гитхабе есть скрипт на SQL для создания базы. Но я не пробовал его на стандартном postgres, а в AlloyDB уже встроены нужные расширения, там есть индексы для поиска приблизительным ближайшим соседям, которых не будет в postgres. AlloyDB Omni опенсорс, ставится на локальную машину, никаких проблем с ним нет, но его надо сначала ставить. А в скилл добавлять установку СУБД так себе идея)
почему не косинус, это косинус. косинусное расстояние вычисляется по формуле
. Значок `<=>` -- это косинусное расстояние -- чем меньше угол, тем больше расстояние между точками в семантическом пространстве, тем они меньше похожи.
Там в скриптах на гитхабе прописано
(1 - (f.embedding <=> query_embedding)), это более привычный подход: чем больше число, тем больше сходство. Поэтому 0.84 -- это большое сходство.В скилле сидят строки подключения к SQL, и он подключается к уже созданной базе, так что выложить в таком виде я его не могу. А на github лежит весь проект со скриптами создания базы, правда, для AlloyDB Omni. это PostgreSQL от Гугла. Он opensource, я его на слабую виртуалку поставил в докере, его можно локально ставить себе на linux
там есть и наоборот, можно переключить
Бот написал себе скилл, в котором прописана строка подключения к AlloyDB, скрипт на Python и инструкция по запуску в markdown. Когда я ему говорю что-то типа "занеси ключевые факты из такой-то статьи в omni-memory", он другим скиллом читает статью, выделяет там то, что посчитал интересным и отправляет в этот скилл, в котором абзац разбивается на subject->predicat->object и уже в виде json отправляется в базу.
Чтение статьи и выявление фактов не отлажено и пока больше похоже на аттракцион, потому что факты из статьи он выбирает довольно своеобразно. Но это всё допиливается. Сам скилл, если ему передать конкретный факт, отрабатывает хорошо.
В общем, векторные базы знаний, как я понял -- это тот же SQL, только с векторным поиском. И если в SQL уже всё для этого встроено, то для предприятий он будет удобнее, у них уже есть оплаченные сервера и готовые специалисты, там доучиться надо совсем немного
Попробуйте везде где возможно поменять мультиагнтность на одного агента с несколькими скиллами. Тогда агент будет работать с одним контекстом, сохраняя состояние.
Извините, может быть вы уже использовали этот трюк, но вторая половина статьи у вас - нередактированная генерация, я не могу это читать
Судя по формату входных данных, DeepSeek-OCR спилена у Google, я в Gemini API такие промпты писал. И Gemini как раз читает документы этих форматов: pdf, doc и картинки. Возможно, DeepSeek-OCR -- это урезанная Gemma 3 4B. Только у Gemma контекст 128K. Я ее тоже на 24GB GPU ставил и тюнил