Увлекательно конечно исследовать то что тебе подсовывают. Насколько помню результат вывода ограничивается 100 бедолагами у которых включена настройка. А вы пробовали так найти конкретного человека, зная точно его геолокацию? Например найти свой профиль?
А почему вы считаете что ваши 6 пунктов есть объективная истина? Мне например было интересно читать про жизненную историю со всеми ее ошибками и граблями. А так, декларативно обличать кого-то... Напишите нам как правильно
Согласен, Ваш запрос выглядит приятней и читается проще
гпт не использовал, честное слово, подсматривал в документацию. Применил в своем запросе вот эту регулярку
nw[~"^contact:.*|email|phone|.*site$"~"."]
потому что интересующая инфа может присутствовать в различных тегах, например информация по сайту может быть в тегах 'site', 'website', 'contact:website'
Ваш пример запроса этот кейс не учитывает. если не прав - поправьте меня
Мне кажется в публикации опущено несколько важных моментов. Например предварительная обработка исходного изображения, чтобы повысить точность распознавания лиц. Ничего не описано про скорость поиска. И не совсем понятно почему расчет разности между векторами ведется на питоне. pgvector имеет свои функции расчета расстояния наверное с ними побыстрее будет чем гонять данные туда-сюда.
Зависимости от API как и от стоимости за OpenAI можно избежать, если использовать для генерации векторов одну из предобученных бесплатных моделей, например эту https://huggingface.co/cointegrated/rubert-tiny2. Основная проблема здесь в другом. Точность оценки сходства сильно снижается когда тексты существенно отличаются по количеству токенов. Так что от игрушечного примера до реального проекта этот кейс еще пилить и пилить. А так да, классная подмога FTSу
Насчет структуры - согласен полностью. В полной мере прочувствовал что ее улучшение - отдельная задача. Что касается оконных функций - пробовал такой вариант - скорость выполнения не очень была. Спасибо за отзыв
Насчет кеширования на уровне ОС сказать не могу, не знаю как postgres взаимодействует с ОС. Функция pgsql в который оборачивал запрос судя по документации при первом вызове формирует и кешируеет план запроса. Что касается изменения входных параметров (инн или названия компании) скрость выполнения зависела только от количества и вывода найденных строк. это по моим экспериментам
Возможно. Я завершил публикацию тем что выразил в ней свое мнение.
А начал с того, что sqlite рассматривается в качестве дополнительного хранилища данных в облачных версиях Б24.
Вы предлагаете json. Наверное на небольших объемах данных действительно лучше. Только сколько будет весить такой файл на 1 млн. записей? И как быстро он будет искать нужные данные?
За подсказки по sql спасибо, не знал, учту.
По итогу, видимо не сумел популярно разъяснить главную мысль. Кейс не по тонкости и выгоду использования sqlite в отдельно взятом кейсе. Речь про то, что sqlite можно эффективно использовать как альтернативное хранилище данных на любом облачном тарифе Битрикс24
Увлекательно конечно исследовать то что тебе подсовывают. Насколько помню результат вывода ограничивается 100 бедолагами у которых включена настройка. А вы пробовали так найти конкретного человека, зная точно его геолокацию? Например найти свой профиль?
А почему вы считаете что ваши 6 пунктов есть объективная истина? Мне например было интересно читать про жизненную историю со всеми ее ошибками и граблями. А так, декларативно обличать кого-то... Напишите нам как правильно
Наверное, да. Но вы не представляете чего только люди не придумают
пока готовил статью - выполнил выборочный парсинг по отдельным регионам. Вот несколько примеров "не по документации"
возможно это не самый популярный тег для указания сайта, но в запросе я его всет-таки учел
Согласен, Ваш запрос выглядит приятней и читается проще
гпт не использовал, честное слово, подсматривал в документацию. Применил в своем запросе вот эту регулярку
потому что интересующая инфа может присутствовать в различных тегах, например информация по сайту может быть в тегах 'site', 'website', 'contact:website'
Ваш пример запроса этот кейс не учитывает. если не прав - поправьте меня
На одном из скринов лендинга написано как подключить скрипт. так и ввел
прелесть publicwww.com что он может искать по фрагментам кода html
Спасибо, поправил
Мне кажется в публикации опущено несколько важных моментов. Например предварительная обработка исходного изображения, чтобы повысить точность распознавания лиц. Ничего не описано про скорость поиска. И не совсем понятно почему расчет разности между векторами ведется на питоне. pgvector имеет свои функции расчета расстояния наверное с ними побыстрее будет чем гонять данные туда-сюда.
Зависимости от API как и от стоимости за OpenAI можно избежать, если использовать для генерации векторов одну из предобученных бесплатных моделей, например эту https://huggingface.co/cointegrated/rubert-tiny2. Основная проблема здесь в другом. Точность оценки сходства сильно снижается когда тексты существенно отличаются по количеству токенов. Так что от игрушечного примера до реального проекта этот кейс еще пилить и пилить. А так да, классная подмога FTSу
Да схему нужно было поразвернутей приводить. Писали уже выше. Учту спасибо
Не совсем так. Уникальна пара инн+Огрн
А одна почта может быть привязана к нескольким компаниям отсюда и jsonb
Насчет структуры - согласен полностью. В полной мере прочувствовал что ее улучшение - отдельная задача. Что касается оконных функций - пробовал такой вариант - скорость выполнения не очень была. Спасибо за отзыв
В тексте код запроса с конкретными параметрами для примера. При тестировании скорости запросы оборачивались в функции.
select * from company_stat_by_inn('0054803450334')
select * from company_stat_by_name('ржд')
Насчет кеширования на уровне ОС сказать не могу, не знаю как postgres взаимодействует с ОС. Функция pgsql в который оборачивал запрос судя по документации при первом вызове формирует и кешируеет план запроса. Что касается изменения входных параметров (инн или названия компании) скрость выполнения зависела только от количества и вывода найденных строк. это по моим экспериментам
Да спасибо. С точки зрения вычислений запросы работают корректно
Что касается конструкции финального запроса - наверное вы правы. Если подскажете как еще можно избавиться от дубликатов кроме дистинкта будет здорово
Возможно. Я завершил публикацию тем что выразил в ней свое мнение.
А начал с того, что sqlite рассматривается в качестве дополнительного хранилища данных в облачных версиях Б24.
Вы предлагаете json. Наверное на небольших объемах данных действительно лучше. Только сколько будет весить такой файл на 1 млн. записей? И как быстро он будет искать нужные данные?
За подсказки по sql спасибо, не знал, учту.
По итогу, видимо не сумел популярно разъяснить главную мысль. Кейс не по тонкости и выгоду использования sqlite в отдельно взятом кейсе. Речь про то, что sqlite можно эффективно использовать как альтернативное хранилище данных на любом облачном тарифе Битрикс24
проверил, не отфильтровывает