У пруссаков, если не ошибаюсь, было правило в армии - писать объяснительную (рапорт) о происшествии не раньше третьего дня, когда эмоции улеглись и мартышки успокоились
Использовалась 100% так как создавалась почти что а процессе парного программирования с майором который расписания составлял. Можно сказать, в процессе обучал заказчика программированию :-)
Сам в такой же омут нырнул - маткласс,медаль, и хоть не мфти (из принципа, так как математичка про него постоянно говорила, но пара одноклассников его закончила), а бауманка (ближе к земле) - в итоге полжизни перекладываю джейсоны. Скажем так, знать алгоритмы не нужно, важнее писать эссе и письма и доклады готовить.
Сейчас банки рулят - "системообразующий бизнес".
В штатах та же болезнь - офис банка с open space , а на стене выложено кирпичами "Honeywell". Был завод а стал банк.
я 15 лет просидел на одной работе - сейчас смотрю как будто дурдом вокруг.
Это все от того что нормальные рабочие места ушли в Китай и людям некуда деваться, по сути.
Посмотрел, посмотрел, и начал копаться с нейронками, проект на гитхабе по мотивам прежних тем начал (рефакторю то с чем работал, по сути, беру некоторые куски), учебник с примерами использования llm начал для таких же идиотов как я сам ( лучший способ разобраться и запомнить это написать), исходники эластика гляжу , куда они ушли от точки когда касался их последний раз - а ребята там способные работают, накатали много.
И мысль такая закрадывается что возможно уеду снова за рубеж на халтуры если работу здесь не найду, хотя не особо хотелось бы, но посмотрим как процесс пойдет.
посмотрел статьи... Забавное совпадение - в 90х на военной кафедре писал программу расписания для преподавателей.
Думал - ерунда, а крови она попила прилично - столько нюансов вылезло...
На Западе в IT волонтерство было почти нормой для новичков - ради подтверждения опыта работы и получения рекомендации пол года или год можно было поработать за спасибо. Неполную ставку, конечно. Обучение это затраты, они компенсировались выполнением работы.
Перед принятием на работу вполне могли набрать по телефону предыдущего работодателя и расспросить о тебе.
Поэтому все старались вести себя корректно ибо репутация монетаризировалась (береги честь с молоду и тд).
забавно, у меня трое знакомых , включая одноклассника - закончили МФТИ. Все ушли в финансы, бухгалтерию. Один на растаможке сел агентом.
Никто не шел в IT.
Сейчас времена другие.
Все хотят брать работников из сильных вузов, это понятно, но какое отношение физика или фундаментальная наука, которой занимается мфти, имеет к прикладной теме как работа в IT...
Понятно что за них идет борьба - микрометром хорошо измерять диаметр гвоздей, если получается. Но в целом это выглядит что что то не то в датском королевстве
Работал в Москве в 2006-2008 - приходит толковый студент 4го курса из МГУ, мехмат. Понятно что кодит нормально на java, вопросов нет, способный, это видно. Но кодить приложение для брокеров для человека с мозгами которые могут тянуть научные темы - грустно .
Это деградация, сэр. Да я сам в. IT пошел от безысходности что инженерные темы схлопнулись и прикладные навыки пригодились ( диплом был расчетный программа по сути, два года его делал).
Примерно лет 20 назад меня знакомый ,земляк, пытался в цифровое "железо" затащить. Я начал копаться в Verilog/VHDL, разводке плат и тд. В ВУЗе мы СВЧ руками только делали на кафедре ( кое что для спутников и мелких радаров)
Он как раз инженером в Research in Motion попал, на хорошую по тем временам зарплату, подъемные тысяч десять получил на переезд, в Китченер (Онтарио).
Потом свой бизнес открыл, выпускал пинцеты с измерителями полного сопротивления (смд) -помню он на разных частотах делал измерение и чтоб в схеме можно было не отпаивая пощупать.
не так давно вытащили из сундука достаточно простую приспособу (продуктом язык не поворачивается назвать), из консалтингового отдела.
Как оно обычно бывает? Пришел к клиенту, понадобилась утилита, написал под его сутиацию. Следующий проект проходит - на основе утилиты еще одна версия (в бранч) и тд. Набирается опыт, и зажигается зеленая лампочка "сделаем продукт!'
Если бы лампочка загоралась и затем технические решения отдавали бы техническим же специалистам...
Не трогай ничего, это отличный код ( На самом деле не простой а золотой, написанный в большой спешке, много чего из декларируемого не реализовано, много конфигурационных параметров в системных переменных (разные конфиги параллельно не потестишь во время билда в разных потоках). Написан в 2011 году (привет Java 5!) и далее раз в год немного долепливался. Смотреть страшно, бранчей много, их не мержили.
Не надо плагины, насыпай зависимости в lib папку, будем у клиента так делать, всегда работало (тихо сделал плагины но пока папка "plugins" не находится, только из основного класс лоадера и папки lib загрузка)
Не используй докер для интеграционных тестов. Мы докер не любим (альтернативы не предлагаем тоже). Поставь руками 5 видов баз которые мы поддерживаем, и проверь все запросы (тихо используем докер с базами на своей машине потому что у QA ВМки полудохлые и вообще, не все базы есть, вот так то, а админы разводят руками). Да, забыл, иногда на разных версиях баз надо будет тестить.
Не надо Spring. Не спрашивай почему (вздохнув, делаем жалкое подобие bean context, со сканированием классов, чтобы как то с натяжкой слепить подобие архитектуры (и оно работает) - когда это приложение решат перевести, переделывать придется меньше.
Хочу метрики как в нашем спринг приложении другом, добавьте как нибудь (интегрируем модуль для спринга заодно и сюда). Интегрируем простой веб сервер
Долепливается старт/стоп, retryable для всяких соединений (база сдохла, база ожила), перенос данных из разных серверов (а не на одном), конвертация и тд.
Реально, проще написать с нуля и взять только бизнес логику.
Правило для консалтинга - если пишешь что то на проекте (разовом), отделяй бизнес логику сразу, если хочешь ее потом где то использовать.
PS в общем, я сейчас там не работаю и особо не жалею, отпуск, лето, зашибись погода. Лет 10 не был в отпуске, колотя jira tickets. На leetcode как то не тянет смотреть, хотя надо бы
напомнили - у меня на экзамене по математике был доп вопрос: "что вы можете сказать о функции по ее второй производной?". Уже плохо соображал и подвис и ответил перепутав имя преподавателя с отчеством, на что получил ответ:
"Если вам трудно запомнить как меня зовут, зовите меня просто Вовочка, я не обижусь".
Владимир Борисович, надеюсь жив и здоров еще.
Теорию управления подзабыл, но краем сознания вспоминаю что там гистерезис помогает много где в приводах, и на устойчивость надо посмотреть, не возникают ли автоколебания из за задержки обрабоки сигналов...
Вспоминаю первую работу в стартапе в чайнатауне... Уютный офис, отличная китайская еда (не шутка) из одного шифрованного ресторана без вывески (один сотрудник был местный, показал явки). Клево было.
Вторая работа - офис полная противоположность, не в грязном и шумном квартале где могло пованивать (у магазинов морепродуктов или овощных), а в строгом деловом квартале у аэропорта. По пятницам, в обед, всей командой в ресторан, по очереди выбирали куда идем,каждый показывал хорошие места (чтоб не сильно далеко). Победила индийская кухня для европейцев, в одном семейном индийском ресторане. Тоже неплохое время было.
На удаленке проработал 15 лет. Если честно, есть и минусы - работаешь 10 лет с человеком, а вживую не видел. Один раз сделали слет в Минске, оторвались, посетили много интересных мест (вплоть до покатушек на белазах, стрельбище, рестораны) хорошо потусили, хоть увидел людей вживую.
Оптимальна гибридная модель с возможность встретиться в офисе. Можно держать небольшой офис, на 10% сотрудников, не больше, и когда нужно, бронируешь рабочее место. Живые встречи и общение полезны, это смена обстановки. Пиццу пожевать, мозговой штурм, отметить что либо.
Не база знаний, обычные бизнес документы, договора, ипотечные всякие, страховые кейсы, медицинские (из того чего касался). 50-100 тыс это скорость кролинга документов в час, как правило, причина торможения это обработка контента. Без контента типичная скорость около 1 млн /час. Еще важно тротлинг применять и сажать репозиторий в рабочее время (по ночам основная работа). Всего документов, к примеру, 10 миллионов - это детский объем на самом деле. С ними работают примерно 500 пользователей (активных сессий), это включает поиск в индесе, редактирование документов в репозитории, оттуда обновленные документы добавляются кролером в индекс (перезаписывая старую версию), и тд, по кругу. Удаление документов из репозитория - событие которое отрабатывает кролер и удаляет запись из индеса. Если идет массовое обновление или реиндексация, то при максимальной скорости кролинга в 100 тыс/час (к примеру) и 10 млн документов, нам понадобится 100 часов, это почти неделя, но в реальности две или три, так как активный кролинг нагружает репозиторий и придется кролить в нерабочее время. А теперь представим что документов не 10 млн а 200 или 300 млн - это обычный индекс в нормальном банке или страховой. Значит, документы желательно кешировать (хоть в файловой системе или в какой то базе которая хороша как кеш, cassandra или что то подобное, главное чтобы скорость записи не падала сильно при росте объема). С подобной базой кешем рекролинг будет быстрее, уже 2,3, 5 миллионов документов в час на обычном PC. Значит изменять индексы и заменять можно шустрее. Был клиент у которого индекс кролился 4 месяца, кеш он по религиозным мотивам (иначе понять не могу) не ставил (типа, некому будет обслуживать а архитекторы не подумали и пропустили мимо ушей предупреждения) - в итоге на индекс молился. Позже вскрылись баги кое какие, в типах люсин, и пришлось вместо обновленного код и рекролинга делать обходные патчи в логике в поисковике. Сейчас этим индусы занимаются, не знаю что там и как. Думаю все хорошо, деньги есть.
RAG было бы полезно использовать, если цена конечно (и быстродействие) позволят.
Поправлю условия по количеству документов: не 50-100 тысяч, а 50-100 тыс в час, добавление. Всего для мелких организаций (небольшой банк и тд) достаточно 10 млн документов. Для более менее крупных контор типично от 100 до 500 млн.
Еще вопрос по RAG - предположим что контент большой, в разы больше контекста LLM модели. Мы создаем вектора и тд. А вопрос будет касаться содержимого начала и конца документа, те разных векторов и у них совпадение по отдельности будет так себе. Т.е RAG хорошо будет работать когда контекст почти того же размера или больше чем размер контента документа и непонятно как работать когда контент в разы больше... И следующее - поиск по метаданным, наверное, через RAG гонять не нужно, достаточно сформулировать запрос по метаданным в языке запроса который LLM "по зубам"
Интересно, что можно сделать с графовой базой, если уйти от векторов сразу в knoledge graph, RDF, knowledge graph DB. Ссылки:
PS понятно что фантазии пока, но я на саббатикале, и могу себе позволить "подурить" на непрактичные темы. Хочется иногда забыть чем занимался на работе.
Сейчас LocalAI ставлю, попробую с локальной сеткой квантированной embedding прогнать, наверное печальная будет скорость... подозреваю что неприемлимая
Собственно, в продакшн никакого пока не использовал. В саббатикале сейчас, после нескольких лет работы без нормального отпуска (два три дня когда не дергают), и нагоняю сейчас.
RAG смотрю так как это соприкасается с темой прошлой работы - миграция репозиториев документов и поисковые движки (в том числе самописные) на базе люсин. Типичные объемы - от 100 до 500 млн документов в одном репозитории. В начале этого года была миграция у клиента на 1.5 млрд документов (перед моим уходом). Т.е примерно понимаю что люди использовали в корпоративной среде (банки и страховые) для поиска документов и что ожидают.
PostgreSQL практически не касался больше 20 лет (в первом стартапе его использовали, затем формально перешли на Oracle), хотя база хорошая (по какой причине от нее активно воротили нос - не могу объяснить, возможно проблема моего окружения принимающего решения и выборка клиетов такая). MySQL к примеру, тащили (наверное из за стоимости в облаке Amazon), хотя как база это откровенное непонятно что.
В домашних условиях прототипирую кое что из положенного на полку и не доделанного, но большие объемы не прогнать ни на локальной сетке (квантированная модель, на 16ГБ чтобы входила), покупать через прокладки или напрямую доступ у OpenAI для теста хотя бы 10М документов (а лучше 100, 200) - дороговато. А без больших тестов оценить сложно на что это похоже.
Если к примеру, я могу хотя бы от 50-100 тысяч документов в час кролить включая создание embedding векторов (а он понадобится не один, так понимаю, если обрабатываем контент со скользящим окном), то уже можно с натяжкой этим методом пользоваться у более менее крупного клиента. Подобные скорости кролинга с контентом типичны и для on premises репозиториев, типа FileNET, и у облачных провайдеров контента типа Box или Sharepoint (если удавалось договориться и уменьшить тротлинг).
Пользователи хотят:
Скорость поиска - до 10 секунд, лучше до 5.
Скорость обновления (документ изменился, поиск тоже, счет на минуты). Иногда приходилось обновлять индекс одновременно с репозиторием (preemptive update), у того же Box, к примеру, события приходят с задержкой от секунд до десятков минут (а это "не есть хорошо"...)
Еще и security втащить. Хотя это совсем не "кошерный" вариант, но если H2 использует Lucene для полнотекствого поиска, то почему бы не всунуть индекс для ускорения join в Lucene? Без join получается денормализованные записи, при изменении общих полей (security) могут быть огромные по объему обновления. Лучше этого избегать, конечно в NoSQL, включая люсин. В Postgres большой плюс - это уже нормальная база с join. Что делать если нужен обычный поиск по полям метаданных, векторный поиск по контенту (семантическое сходство, по словам или по тексту) и join сверху?
У меня пока недостаточно опыта для оценки, какое железо для нужной производительности потребуется для RAG, чтобы LLM модели с достаточной скоростью (и точностью) создавали вектора. Не получится ли что проще будет плюнуть на RAG и создать поиск старыми способами а РАГ оставить для чат ботов...
кролим репозиторий документов с метаданными и контентом (тот же PDF). Контент в среднем 10к символов но может быть максимум до 10М символов текст. В контекст точно не влезет.
При этом поиск делаем как по метаданным, так и по контенту.
Имена полей в метаданных тоже необходимо маппить в NLP, к примеру dateModified дата изменения документа и тд..
Прогнать тест на 100м документов репозитории и посмотреть, заодно сравнить milvus и постгресс.
И было бы неплохо дополнить до гибридного RAG с поиском в векторном хранилище и в базе или люсин индексе, вроде моделей для люсин хватает в отличие от SQL...
Я бы сейчас для тренировки полепил такой поиск.
если получится уложиться во время поиска (после конверсии в вектора, без учета llm) до 10 секунд на 100м документах на обычном железе, то вполне неплохо.
или ушел в запой и такое написал "письмо турецкому султану"...
Главное - чтобы не раньше третьего дня
Люди остывали, обдумывали, эмоции уходили
У пруссаков, если не ошибаюсь, было правило в армии - писать объяснительную (рапорт) о происшествии не раньше третьего дня, когда эмоции улеглись и мартышки успокоились
Использовалась 100% так как создавалась почти что а процессе парного программирования с майором который расписания составлял. Можно сказать, в процессе обучал заказчика программированию :-)
Об этом и написал.
Сам в такой же омут нырнул - маткласс,медаль, и хоть не мфти (из принципа, так как математичка про него постоянно говорила, но пара одноклассников его закончила), а бауманка (ближе к земле) - в итоге полжизни перекладываю джейсоны. Скажем так, знать алгоритмы не нужно, важнее писать эссе и письма и доклады готовить.
Сейчас банки рулят - "системообразующий бизнес".
В штатах та же болезнь - офис банка с open space , а на стене выложено кирпичами "Honeywell". Был завод а стал банк.
Нет, не мои - его. В начале 2000х была проблема все засунуть в небольшой корпус, с микроконтроллером.
я 15 лет просидел на одной работе - сейчас смотрю как будто дурдом вокруг.
Это все от того что нормальные рабочие места ушли в Китай и людям некуда деваться, по сути.
Посмотрел, посмотрел, и начал копаться с нейронками, проект на гитхабе по мотивам прежних тем начал (рефакторю то с чем работал, по сути, беру некоторые куски), учебник с примерами использования llm начал для таких же идиотов как я сам ( лучший способ разобраться и запомнить это написать), исходники эластика гляжу , куда они ушли от точки когда касался их последний раз - а ребята там способные работают, накатали много.
И мысль такая закрадывается что возможно уеду снова за рубеж на халтуры если работу здесь не найду, хотя не особо хотелось бы, но посмотрим как процесс пойдет.
посмотрел статьи... Забавное совпадение - в 90х на военной кафедре писал программу расписания для преподавателей.
Думал - ерунда, а крови она попила прилично - столько нюансов вылезло...
На Западе в IT волонтерство было почти нормой для новичков - ради подтверждения опыта работы и получения рекомендации пол года или год можно было поработать за спасибо. Неполную ставку, конечно. Обучение это затраты, они компенсировались выполнением работы.
Перед принятием на работу вполне могли набрать по телефону предыдущего работодателя и расспросить о тебе.
Поэтому все старались вести себя корректно ибо репутация монетаризировалась (береги честь с молоду и тд).
Сейчас все сошли с ума, и похоже что везде.
забавно, у меня трое знакомых , включая одноклассника - закончили МФТИ. Все ушли в финансы, бухгалтерию. Один на растаможке сел агентом.
Никто не шел в IT.
Сейчас времена другие.
Все хотят брать работников из сильных вузов, это понятно, но какое отношение физика или фундаментальная наука, которой занимается мфти, имеет к прикладной теме как работа в IT...
Понятно что за них идет борьба - микрометром хорошо измерять диаметр гвоздей, если получается. Но в целом это выглядит что что то не то в датском королевстве
Работал в Москве в 2006-2008 - приходит толковый студент 4го курса из МГУ, мехмат. Понятно что кодит нормально на java, вопросов нет, способный, это видно. Но кодить приложение для брокеров для человека с мозгами которые могут тянуть научные темы - грустно .
Это деградация, сэр. Да я сам в. IT пошел от безысходности что инженерные темы схлопнулись и прикладные навыки пригодились ( диплом был расчетный программа по сути, два года его делал).
Хорошая статья, рад за вас.
Примерно лет 20 назад меня знакомый ,земляк, пытался в цифровое "железо" затащить. Я начал копаться в Verilog/VHDL, разводке плат и тд. В ВУЗе мы СВЧ руками только делали на кафедре ( кое что для спутников и мелких радаров)
Он как раз инженером в Research in Motion попал, на хорошую по тем временам зарплату, подъемные тысяч десять получил на переезд, в Китченер (Онтарио).
Потом свой бизнес открыл, выпускал пинцеты с измерителями полного сопротивления (смд) -помню он на разных частотах делал измерение и чтоб в схеме можно было не отпаивая пощупать.
да ладно бы с живым не дали...
не так давно вытащили из сундука достаточно простую приспособу (продуктом язык не поворачивается назвать), из консалтингового отдела.
Как оно обычно бывает? Пришел к клиенту, понадобилась утилита, написал под его сутиацию. Следующий проект проходит - на основе утилиты еще одна версия (в бранч) и тд. Набирается опыт, и зажигается зеленая лампочка "сделаем продукт!'
Если бы лампочка загоралась и затем технические решения отдавали бы техническим же специалистам...
Не трогай ничего, это отличный код ( На самом деле не простой а золотой, написанный в большой спешке, много чего из декларируемого не реализовано, много конфигурационных параметров в системных переменных (разные конфиги параллельно не потестишь во время билда в разных потоках). Написан в 2011 году (привет Java 5!) и далее раз в год немного долепливался. Смотреть страшно, бранчей много, их не мержили.
Не надо плагины, насыпай зависимости в lib папку, будем у клиента так делать, всегда работало (тихо сделал плагины но пока папка "plugins" не находится, только из основного класс лоадера и папки lib загрузка)
Не используй докер для интеграционных тестов. Мы докер не любим (альтернативы не предлагаем тоже). Поставь руками 5 видов баз которые мы поддерживаем, и проверь все запросы (тихо используем докер с базами на своей машине потому что у QA ВМки полудохлые и вообще, не все базы есть, вот так то, а админы разводят руками). Да, забыл, иногда на разных версиях баз надо будет тестить.
Не надо Spring. Не спрашивай почему (вздохнув, делаем жалкое подобие bean context, со сканированием классов, чтобы как то с натяжкой слепить подобие архитектуры (и оно работает) - когда это приложение решат перевести, переделывать придется меньше.
Хочу метрики как в нашем спринг приложении другом, добавьте как нибудь (интегрируем модуль для спринга заодно и сюда). Интегрируем простой веб сервер
Долепливается старт/стоп, retryable для всяких соединений (база сдохла, база ожила), перенос данных из разных серверов (а не на одном), конвертация и тд.
Реально, проще написать с нуля и взять только бизнес логику.
Правило для консалтинга - если пишешь что то на проекте (разовом), отделяй бизнес логику сразу, если хочешь ее потом где то использовать.
PS в общем, я сейчас там не работаю и особо не жалею, отпуск, лето, зашибись погода. Лет 10 не был в отпуске, колотя jira tickets. На leetcode как то не тянет смотреть, хотя надо бы
Пример из моей прошлой работы.
В консалнинговой компании было 24 разработчика.
Мне приходит письмо, в котором по ошибке прицеплена зарплатная ведомость - брат владельца бизнеса форварднул случайно.
С соседом смотрим - у всех примерно одинаковая зарплата, а у руководителей отделов (которых 3), рост в 3.5 раза.
Условно назову уровни: 40 тыс, и 140 у руководителя.
Сосед психует и увольняется на следующий день. Через неделю присылает и мне оффер на 80, но нужно сорваться в другой город на горящий контракт.
У меня были другие планы, тоже собирался уходить но не прямо сейчас, остаюсь.
Это сорвало лавину, народ пошел на беседу к боссу, затем на выходе крутили у виска (просил 45, отказ) и на увольнение.
Через неделю осталось 3 человека, я и пара индусов DBA. Я тоже отвалил, в общем то.
Ни одного разраба, все с нуля.
Буквально недавно, похожий прикол от бухгалтерии на последнем месте работы - только бухгалтера прислали не мою ведомость а портянку для всех.
И опять, руководитель отдела - зарплата в 2 раза выше, на удаленке - в 4 раза отличие.
И снова, все в хлам, но по другой причине (результат тот же, впрочем).
напомнили - у меня на экзамене по математике был доп вопрос: "что вы можете сказать о функции по ее второй производной?". Уже плохо соображал и подвис и ответил перепутав имя преподавателя с отчеством, на что получил ответ:
"Если вам трудно запомнить как меня зовут, зовите меня просто Вовочка, я не обижусь".
Владимир Борисович, надеюсь жив и здоров еще.
Теорию управления подзабыл, но краем сознания вспоминаю что там гистерезис помогает много где в приводах, и на устойчивость надо посмотреть, не возникают ли автоколебания из за задержки обрабоки сигналов...
Вспоминаю первую работу в стартапе в чайнатауне... Уютный офис, отличная китайская еда (не шутка) из одного шифрованного ресторана без вывески (один сотрудник был местный, показал явки). Клево было.
Вторая работа - офис полная противоположность, не в грязном и шумном квартале где могло пованивать (у магазинов морепродуктов или овощных), а в строгом деловом квартале у аэропорта. По пятницам, в обед, всей командой в ресторан, по очереди выбирали куда идем,каждый показывал хорошие места (чтоб не сильно далеко). Победила индийская кухня для европейцев, в одном семейном индийском ресторане. Тоже неплохое время было.
На удаленке проработал 15 лет. Если честно, есть и минусы - работаешь 10 лет с человеком, а вживую не видел. Один раз сделали слет в Минске, оторвались, посетили много интересных мест (вплоть до покатушек на белазах, стрельбище, рестораны) хорошо потусили, хоть увидел людей вживую.
Оптимальна гибридная модель с возможность встретиться в офисе. Можно держать небольшой офис, на 10% сотрудников, не больше, и когда нужно, бронируешь рабочее место. Живые встречи и общение полезны, это смена обстановки. Пиццу пожевать, мозговой штурм, отметить что либо.
Спасибо, полезно
Не база знаний, обычные бизнес документы, договора, ипотечные всякие, страховые кейсы, медицинские (из того чего касался). 50-100 тыс это скорость кролинга документов в час, как правило, причина торможения это обработка контента. Без контента типичная скорость около 1 млн /час. Еще важно тротлинг применять и сажать репозиторий в рабочее время (по ночам основная работа). Всего документов, к примеру, 10 миллионов - это детский объем на самом деле. С ними работают примерно 500 пользователей (активных сессий), это включает поиск в индесе, редактирование документов в репозитории, оттуда обновленные документы добавляются кролером в индекс (перезаписывая старую версию), и тд, по кругу. Удаление документов из репозитория - событие которое отрабатывает кролер и удаляет запись из индеса. Если идет массовое обновление или реиндексация, то при максимальной скорости кролинга в 100 тыс/час (к примеру) и 10 млн документов, нам понадобится 100 часов, это почти неделя, но в реальности две или три, так как активный кролинг нагружает репозиторий и придется кролить в нерабочее время. А теперь представим что документов не 10 млн а 200 или 300 млн - это обычный индекс в нормальном банке или страховой. Значит, документы желательно кешировать (хоть в файловой системе или в какой то базе которая хороша как кеш, cassandra или что то подобное, главное чтобы скорость записи не падала сильно при росте объема). С подобной базой кешем рекролинг будет быстрее, уже 2,3, 5 миллионов документов в час на обычном PC. Значит изменять индексы и заменять можно шустрее. Был клиент у которого индекс кролился 4 месяца, кеш он по религиозным мотивам (иначе понять не могу) не ставил (типа, некому будет обслуживать а архитекторы не подумали и пропустили мимо ушей предупреждения) - в итоге на индекс молился. Позже вскрылись баги кое какие, в типах люсин, и пришлось вместо обновленного код и рекролинга делать обходные патчи в логике в поисковике. Сейчас этим индусы занимаются, не знаю что там и как. Думаю все хорошо, деньги есть.
Посмотрел эластик, с ним мало имел дело, после 5й версии не касался его, он сильно изменился, оброс и заматерел, скачал исходники, надо посмотреть его лучше. Он мне раньше нравился, видно по уровню кода что команда сильная. Попробовал localAI с моделью отсюда https://www.elastic.co/search-labs/blog/localai-for-text-embeddings и сразу воспроизвел баг (да что ж такое) https://github.com/mudler/LocalAI/issues/4529 и https://github.com/mudler/LocalAI/issues/3886
четко по статье все поставил и поймал проблему, видать когда статью писали, бага не было. С другой моделью попроще запустил
Вектор выплюнула, замерю попозже на пачке и на разных моделях.
но это пожалуй, для обучения, не более, скорость низкая на домашней игровой карточке.
Пардон за много букв...
RAG было бы полезно использовать, если цена конечно (и быстродействие) позволят.
Поправлю условия по количеству документов: не 50-100 тысяч, а 50-100 тыс в час, добавление. Всего для мелких организаций (небольшой банк и тд) достаточно 10 млн документов. Для более менее крупных контор типично от 100 до 500 млн.
Еще вопрос по RAG - предположим что контент большой, в разы больше контекста LLM модели. Мы создаем вектора и тд. А вопрос будет касаться содержимого начала и конца документа, те разных векторов и у них совпадение по отдельности будет так себе. Т.е RAG хорошо будет работать когда контекст почти того же размера или больше чем размер контента документа и непонятно как работать когда контент в разы больше... И следующее - поиск по метаданным, наверное, через RAG гонять не нужно, достаточно сформулировать запрос по метаданным в языке запроса который LLM "по зубам"
Интересно, что можно сделать с графовой базой, если уйти от векторов сразу в knoledge graph, RDF, knowledge graph DB. Ссылки:
https://migalkin.github.io/posts/2023/03/27/post/
https://migalkin.github.io/kgcourse2021/lectures/lecture1
PS понятно что фантазии пока, но я на саббатикале, и могу себе позволить "подурить" на непрактичные темы. Хочется иногда забыть чем занимался на работе.
Сейчас LocalAI ставлю, попробую с локальной сеткой квантированной embedding прогнать, наверное печальная будет скорость... подозреваю что неприемлимая
Собственно, в продакшн никакого пока не использовал. В саббатикале сейчас, после нескольких лет работы без нормального отпуска (два три дня когда не дергают), и нагоняю сейчас.
RAG смотрю так как это соприкасается с темой прошлой работы - миграция репозиториев документов и поисковые движки (в том числе самописные) на базе люсин. Типичные объемы - от 100 до 500 млн документов в одном репозитории. В начале этого года была миграция у клиента на 1.5 млрд документов (перед моим уходом). Т.е примерно понимаю что люди использовали в корпоративной среде (банки и страховые) для поиска документов и что ожидают.
PostgreSQL практически не касался больше 20 лет (в первом стартапе его использовали, затем формально перешли на Oracle), хотя база хорошая (по какой причине от нее активно воротили нос - не могу объяснить, возможно проблема моего окружения принимающего решения и выборка клиетов такая). MySQL к примеру, тащили (наверное из за стоимости в облаке Amazon), хотя как база это откровенное непонятно что.
В домашних условиях прототипирую кое что из положенного на полку и не доделанного, но большие объемы не прогнать ни на локальной сетке (квантированная модель, на 16ГБ чтобы входила), покупать через прокладки или напрямую доступ у OpenAI для теста хотя бы 10М документов (а лучше 100, 200) - дороговато. А без больших тестов оценить сложно на что это похоже.
Если к примеру, я могу хотя бы от 50-100 тысяч документов в час кролить включая создание embedding векторов (а он понадобится не один, так понимаю, если обрабатываем контент со скользящим окном), то уже можно с натяжкой этим методом пользоваться у более менее крупного клиента. Подобные скорости кролинга с контентом типичны и для on premises репозиториев, типа FileNET, и у облачных провайдеров контента типа Box или Sharepoint (если удавалось договориться и уменьшить тротлинг).
Пользователи хотят:
Скорость поиска - до 10 секунд, лучше до 5.
Скорость обновления (документ изменился, поиск тоже, счет на минуты). Иногда приходилось обновлять индекс одновременно с репозиторием (preemptive update), у того же Box, к примеру, события приходят с задержкой от секунд до десятков минут (а это "не есть хорошо"...)
Еще и security втащить. Хотя это совсем не "кошерный" вариант, но если H2 использует Lucene для полнотекствого поиска, то почему бы не всунуть индекс для ускорения join в Lucene? Без join получается денормализованные записи, при изменении общих полей (security) могут быть огромные по объему обновления. Лучше этого избегать, конечно в NoSQL, включая люсин. В Postgres большой плюс - это уже нормальная база с join. Что делать если нужен обычный поиск по полям метаданных, векторный поиск по контенту (семантическое сходство, по словам или по тексту) и join сверху?
У меня пока недостаточно опыта для оценки, какое железо для нужной производительности потребуется для RAG, чтобы LLM модели с достаточной скоростью (и точностью) создавали вектора. Не получится ли что проще будет плюнуть на RAG и создать поиск старыми способами а РАГ оставить для чат ботов...
Погуглил пару минут, не Нортон а тотал коммандер - похожие жалобы
А ведь Тотал против Нортона это как столяр супротив плотника.
Кто то просто не сделал move а заменил его copy/delete ( более того, наоборот), типа наивный алгоритм для всех случаев (разные диски и один диск)
Что если приблизить задачу к реальному сценарию?
кролим репозиторий документов с метаданными и контентом (тот же PDF). Контент в среднем 10к символов но может быть максимум до 10М символов текст. В контекст точно не влезет.
При этом поиск делаем как по метаданным, так и по контенту.
Имена полей в метаданных тоже необходимо маппить в NLP, к примеру dateModified дата изменения документа и тд..
Прогнать тест на 100м документов репозитории и посмотреть, заодно сравнить milvus и постгресс.
И было бы неплохо дополнить до гибридного RAG с поиском в векторном хранилище и в базе или люсин индексе, вроде моделей для люсин хватает в отличие от SQL...
Я бы сейчас для тренировки полепил такой поиск.
если получится уложиться во время поиска (после конверсии в вектора, без учета llm) до 10 секунд на 100м документах на обычном железе, то вполне неплохо.
Пусть будет jpg с большой метадатой. Стеганография типа.