Да, моделей много. Под каждую задачу нужно подбирать свою "волшебную таблетку". И, я так думаю, что это задача аналитика а не команды разработки. А за модельки спасибо! Не сталкивался, посмотрю.
Увлекательно конечно исследовать то что тебе подсовывают. Насколько помню результат вывода ограничивается 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
проверил, не отфильтровывает