качество ответов зависти от модели 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 ставил и тюнил