LINUX.ORG.RU
ФорумTalks

LLM - замена мозгу, небольшой опыт

 


0

1

Друзья, я неожиданно для себя провёл интересный эксперимент. Есть qpdf. Стоит задача извлечь страницы в заданном диапазоне. Интернет - не используем. Есть qpdf.exe –help=all>qpdf_hlp.txt (сори за офтопик на десктопе, не я такой, жизнь такая). Без этого файла корректный ответ получить невозможно но с ним только одна из моделей, что у меня есть ответила верно, при условии расширения контекстного окна, это была gpt-oss-20B.

Корректная строка выглядит так:

qpdf input.pdf –pages . 93-95 – output.pdf

Поскольку сценариев манипуляций великое множество, требуется два раза упоминать входной файл, что не совесем очевидно для меня. Ну help=all занимает около 50 кб.

Что касается моих скромных способнострей, я бы недотумкал или очень долго бы разбирался.

То есть она смогла прочитать справку и правильно её интерпретировать. Кто не справились:

Qwen3-14B-Q4_K_M

google_gemma-3-12b-it-Q5_K_M

google_gemma-3-4b-it-Q4_K_M

Меня волнует вопрос, какая модель может самостоятельно работать в агентном режиме, принимать решения вместо меня. Я сделал ряд тестов, школьные задачки, редактура письма, написать код на разных языках (не без помощи старших LLM код но остальные задачи - моя проектная практика, тригонометрия, деловая переписка, работа с нормативным или юридическим документом). В принципе размерность и качество этих моделей, кроме gemma-3-4b, были сопоставимы но на этом тесте в резкий отрыв ушла gpt-oss

★★★

Последнее исправление: baaba (всего исправлений: 3)
Ответ на: комментарий от watchcat382

Зачем картинки? Пути к ним. Хотя в принципе он и на картинках не подавится, если это фотки обычного размера, с телефона там и т.п., а не какой-то мега-хайрез.

Если не хочется SQL, в принципе можно и на ФС это решить — симлинками. Звучит несколько более костыльно, но есть свои плюшки, например возможность просмотра «тега» как каталога стандартным софтом, без необходимости в каких-либо обвязок для этого.

CrX ★★★★★
()
Ответ на: комментарий от CrX

можно и на ФС это решить — симлинками.

Поддерживать их корректность тяжко будет. Например - какой командой можно получить все симлинки,указывающие на вот этот конкретный файл? Ну чтобы их при необходимости подправить например.

watchcat382
()
Ответ на: комментарий от watchcat382

Поддерживать их корректность тяжко будет.

На самом деле не тяжелее, чем корректность записей в БД. Да и смысл исходные файлы переименовывать или перемещать, если предполагается их свалить все в один каталог, а для каталогизации использовать собственно эту систему? Разве что при удалении ставшие некорректными симлинки поудалять тоже, да и всё, а это легко.

Но так вообще можно это делать тем же процессом, которым и создаются симлинки для вновь прибывших файлов — просто периодически делать эдакую синхронизацию/актуализацию. Ровно как и в случае с ДБ на самом деле.

Например - какой командой можно получить все симлинки,указывающие на вот этот конкретный файл?

find -L путь/туда/где/дерево/с/симлинками -xtype l -samefile конкретный.файл
CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

На самом деле не тяжелее, чем корректность записей в БД.

В продвинутых БД хранятся в том или ином виде связи между «единицами хранения». Поэтому поиск при каждой операции не требуется - есть прямой указатель что вот этот элемент связан с тем,тем и тем. Мы не про тупые таблицы на dbf-файлах как в досе говорим где на каждый чих поиск по всему файлу выполнялся.

переименовывать или перемещать

Это - нет,а вот удалять и добавлять - да. При удалении естественно придется проверять чтобы не остались «висячие» ссылки.

предполагается их свалить все в один каталог

Свалить в один каталог тысячи картинок - это однозначно плохо. Будут тормоза при каждом обращении к каталогу с таким количеством файлов. Очевидно что желание сделать продвинутую систему каталогизации возникнет у человека который фотографирует реально много, а не так как я,у которого вся фотоколлекция за три десятка лет века это чуть меньше трех тысяч файлов. Будь их там не три,а тридцать три тысячи как у профи-фотографов - система вставала бы колом при каждом входе в такой каталог.

find -L путь/туда/где/дерево/с/симлинками -xtype l -samefile конкретный.файл

Ну такое решение «в лоб» через поиск - это и я могу. Но это означает что каждый запуск этой команды потребует прочитывания ВСЕХ символьных ссылок. Которых по определению будет в разы больше чем самих картинок. На большой фотоколлекции работать будет весьма не быстро мягко говоря. Хотя у профессиональных фотографов компы очень мощные (правда у них и не линукс - просто в силу традиции там обычно мак).

watchcat382
()
Ответ на: комментарий от watchcat382

Свалить в один каталог тысячи картинок - это однозначно плохо. Будут тормоза при каждом обращении к каталогу с таким количеством файлов. Очевидно что желание сделать продвинутую систему каталогизации возникнет у человека который фотографирует реально много, а не так как я,у которого вся фотоколлекция за три десятка лет века это чуть меньше трех тысяч файлов. Будь их там не три,а тридцать три тысячи как у профи-фотографов - система вставала бы колом при каждом входе в такой каталог.

Это уже отдельный вопрос. Во-первых, ни ls ни нормальные ФМ не тормозят на жалких нескольких десятках тысяч файлов. Во-вторых, это решается, например тем, что они не в одном большом каталоге лежат, а скажем по датам. Или по первым цифрам контрольной суммы. Это не принципиальный в данном случае момент, в любом случае оригинал перемещать туда-сюда обычно не предполагается, вся «каталогизация» происходит в симлинках (ну или в БД).

Ну такое решение «в лоб» через поиск - это и я могу. Но это означает что каждый запуск этой команды потребует прочитывания ВСЕХ символьных ссылок. Которых по определению будет в разы больше чем самих картинок. На большой фотоколлекции работать будет весьма не быстро мягко говоря. Хотя у профессиональных фотографов компы очень мощные (правда у них и не линукс - просто в силу традиции там обычно мак).

Ну если там миллиарды симлинков, то может быть. Если миллионы, это достаточно быстро. По сравнению с теми ресурсами, что требуются непосредственно для «расстановки тегов» для новых файлов это где-то на уровне погрешности.

P.S. Кстати, как компромиссный вариант, можно запилить таки на sqlite всё, но сделать ещё небольшую псевдо-ФС на FUSE, которая это всё представит в виде файловой системы — для использования стандартного софта, ничего о нашей БД не знающего.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 2)
Ответ на: комментарий от CrX

вариант, можно запилить таки на sqlite всё, но сделать ещё небольшую псевдо-ФС на FUSE, которая это всё представит в виде файловой системы — для использования стандартного софта, ничего о нашей БД не знающего.

Вот кстати я тоже первым делом именно подумал про связку БД+FUSE. Правда сразу задумался о том что БД должна поддерживать хранение связей между единицами хранения. Чтобы не гонять постоянно операции поиска по ключевым полям(что внутри БД что в файловой системе поиск - не выгодная жручая операция). Я когда-то давно имел дело с такой СУБД - называлась MDBS IV. Проприетарная увы (Micro Data Base Systems Inc.)

watchcat382
()
Ответ на: комментарий от CrX

P.S. Кстати, как компромиссный вариант, можно запилить таки на sqlite всё, но сделать ещё небольшую псевдо-ФС на FUSE, которая это всё представит в виде файловой системы — для использования стандартного софта, ничего о нашей БД не знающего.

Нафига такие сложности? Достатточно выводить список файлов в stdout. Вы как не линуксоиды, блин.

wandrien ★★★
()
Ответ на: комментарий от wandrien

Нафига такие сложности? Достатточно выводить список файлов в stdout. Вы как не линуксоиды, блин.

Не для всех задач это достаточно. Ну и это само собой разумеющаяся фича, естественно. FUSE FS уже как следующий этап.

CrX ★★★★★
()
Ответ на: комментарий от CrX

В БД заводишь 2 таблицы:

В одной: (файловый путь, размер, дата модификации) <-> SHA256.

В другой: SHA256 <-> (model_name, image_description)

Всё, проблемы с тем, чтобы восстановить корректные пути после перемещания файлов на диске больше нет. Меняться будет только первая таблица, без необходимости LLM гонять на всех тысячах файлов.

wandrien ★★★
()
Ответ на: комментарий от CrX

Ну теоретически можно сделать, чтобы заходя по пути виртуального каталога точка_монтирования/запрос/, мы попадали в результаты поиска.

Какие-то вайбы Plan 9 в этом есть.

Но я FUSE-драйверов не писал ни разу и пока что лениво в это лезть.

Я пока у себя непосредственно индексацию и поиск пишу.

Вряд ли доделаю до production-ready решения, так и буду на локалхосте гонять…

wandrien ★★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Ну теоретически можно сделать, чтобы заходя по пути виртуального каталога точка_монтирования/запрос/, мы попадали в результаты поиска.

Да. Это несложно сделать на FUSE. Я даже где-то уже видел именно подобное, но не помню где, и там не для картинок было.

Но я FUSE-драйверов не писал ни разу и пока что лениво в это лезть.

Ну это имеет смысл только когда БД уже есть, как и вывод имён файлов в stdout. Сперва базовая функциональность, потом уже дополнительные фичи.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)

В агентном режиме может в общем-то работать любая LLM умеющая отвечать на запросы. Просто её запускают в цикле в промтами типа «ты зашла в папку /foo/bar, там лежат файлы rarjpeg.exe и readme.md. Ты должна либо выдать команду для исполнения, либо /report, чтобы выдать финальный ответ юзеру». И с таким полузахардкоженным промтом модель работает, пока не сообщит, что результат достигнут. Дальше приходит человек и смотрит что получилось и, возможно, даёт новый промт.

Главное чтобы модель исполняла команды из белого списка или в какой-то песочнице, потому что нет никаких гарантий, что за сотни итераций она не сгенерирует патч Бармина.

Ну и от умности модели зависит сколько ей потребуется итераций и не уйдет ли она в цикл вечных доработок не будучи способной достигнуть цели.

Все топовые модели требуют фермы видеокарт, а часто ещё и закрытые. Что-то серьёзное на домашней машине без облачных ИИ вряд ли выйдет добиться. Но, конечно, зависит от твоих задач.

KivApple ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)