Я тоже думаю над проектами (некоторые даже выстрелили) и вижу такие проблемы:
1) Самая жирная проблема: источник картинок и пр. как объектов авторских прав. Сейчас подача исков на всех и вся превратилась в массовое явление. Мои бизнес-партнеры уже отказываются и от официальных фотостоков, т.к. постоянно доказывать легальность фоток стала занимать много времени и ресурсов. А "бесплатные" фотки тоже несут риски, т.к. не понятно кто и почему поставил эту метку. Так что сейчас аккуратно надо быть с этим. Это одна из причин, почему все массово переходят на нейрогенерацию картинок. Бегать по судам никому не хочется. Даже если картинки легально куплены.
2) Языковые модели ненадежны. Даже если им предоставить правильную исходную информацию, они могут сделать неправильные выводы. Это означает, что в обязательном порядке на каждое утверждение нужно приводить ссылки на источники. Т.е. пользователю в обязательном порядке надо будет изучать источники. А если так, то бОльшая часть удобства сервиса нивелируется.
3) В таких проектах важна репутация. Почему я должен верить этой информации? - задает вопрос пользователь. Даже если речь о подборке ссылок на источники, то пользователь будет задаваться вопросами: Насколько она точна? Насколько полна? Надо всё перепроверять. И приходит к выводу, что... скрипач не нужен...
4) Огромное количество бесплатных альтернатив, перебить которые вы можете только репутацией (см. пункт 3).
5) Из личного опыта могу сказать, что оценить проект пользователи (и бизнес) могут не сразу, а лишь через несколько лет. Так что первые выводы (за первый год) - это еще не показатель провала.
Каким имхо должен быть сервис, чтобы "выстрелил":
1) Должен решать реальную проблему бизнеса (желательно именно бизнеса).
2) Сервис должен быть по настоящему уникальным.
3) Сервис должен иметь простое, но нетривиальное решение (см. п. 4).
4) Сервис должен казаться нереализуемым или очень сложно реализуемым, чтобы конкуренты с низкими бюджетами отсеялись сразу. А дяди с большими ресурсами... обычно тормозные, с большой инерцией, пока раскачаются... им проще будет выкупить ваш проект вместе с вами...
Два вопроса: 1) А паспортные данные ИП тоже попадают в публичный доступ? 2) Если речь о яндекс-метрике, то какой адрес ЦОДа указывать? Где его брать? Данные ведь хранятся у Яндекса и им же собираются обрабатываются. Сервер сайта ведь не имеет к этим данным никакого отношения.
Наверно всё же речь о сервисе как публичной услуге?
Иначе (при широкой трактовке) абсолютно все зарубежные серверы попали бы под запрет. По той простой причине, что любой установленный на зарубежном сервере софт будет иметь доступ ко всему. И речь ведь не о VPN. VPN-это лишь частный случай. А в общем случае веб-сервер, ftp-сервер, ssh-сервер и пр. и пр. и пр. , т.е. почти любую прогу можно трактовать как предоставляющую (теоретически) доступ...
Ждем. И хотелось бы там рассмотреть вопрос производительности предлагаемых решений, т.к. если документов больше миллиона (а такие корпуса наиболее интересны), то стоимость обработки документа выходит на первый план, т.к. обычно более интеллектуальные алгоритмы и более ресурсозатратные.
По моему опыту простые способы разбиения на чанки (по размеру или по абзацам) работают откровенно плохо. А семантические способы подходят только для маленьких корпусов документов. Если документов например миллионы, то уже на этапе разбиения на чанки возникают огромные проблемы.
Почему то этот процесс (разбиения на чанки) зачастую затрагивается лишь вскользь, а по мне - это самый важный этап, намного более важный чем дальнейшие способы поиска и ранжирования. Векторный поиск вообще адекватно работает только в том случае, если каждый компактный чанк имеет хорошо выраженную узко тематическую направленность. В противном случае мы получим мусор на выходе, какие бы совершенные алгоритмы ни применяли для поиска.
В НК эта проблема не так остро выражена, т.к. в статьях не так много отвлеченных абзацев. Однако в книгах, статьях, обзорах и пр. половина абзацев может быть на слишком общие темы (например, вводные), или на отвлеченные, или смежные. Всё это вводит огромный шум, что делает семантический поиск намного хуже, чем тупо BM25.
А при работе с огромным количеством документов я вообще не вижу альтернативы мешку слов (BM25). К примеру, если в корпусе десятки миллионов документов, то уже простая векторизация выглядит неподъемной задачей. С другой стороны, на таких объемах скорей всего BM25 будет работать лучше, чем семантический поиск. Просто напросто за счет разнообразия изложения одной и той же темы разными словами.
В общем, это я к тому, что всё очень классно и здорово выглядит на бумаге, а в реальных проектах возникает огромное количество проблем, где простые подходы перестают работать... Или наоборот - старый добрый BM25 будет лучшим решением.
Да, наверняка к коду карты еще и код РСЯ добавится, а он тоже не мало весит.
Что в итоге:
Вариант 1 (без карты или карта картинкой). Ваша страница легкая. В картинках прописана ленивая загрузка, а неключевые скрипты имеют отложенную загрузку. Страницу открывает посетитель со смартфона с неустойчивой 3G связью: Сначала грузится компактный файлик css (10КБ), потом html-код страницы (50КБ) и посетитель уже видит текст на первом экране. И только потом лениво загружаются большие картинки и скрипты. Главное - посетитель через пару секунд уже может читать текст, а еще через пару секунд увидит карту в виде картинки.
Вариант 2 (карта через API или iframe): Карты имеют асинхронную загрузку, поэтому предсказать последовательность загрузки невозможно. Итак, посетителю не повезло и первыми начали загружаться скрипты карты и рекламы (>1МБ), а также карточные тайлы и картинки рекламных баннеров (объем боюсь представить). Неустойчивый 3G канал посетителя забит намертво, не то что картинки сайта не загружаются, но даже и css/html-код может встать в очередь... на пару минут...
В общем банальная вставка предоставляемого кода карты на страницу - это не очень хорошая затея. Нужно смотреть, как это скажется на мобильных посетителях.
Коммерческую карту заскриншотить нельзя - будет нарушение авторских прав, как я понимаю. Свободную OSM можно. И простой картинкой, кстати, намного лучше в отношении скорости работы сайта. А встроенная через api карта (через код вставки) обычно тянет за собой мегатонны лишнего трафика, что плохо сказывается на метриках.
приходится теперь ещё оплачивать подписку на «Яндекс Бизнес»
Подскажите плиз, а может отсутствие рейтинга (звездочки с количеством отзывов) в выдаче яндекса быть связано с отсутствием платной подписки на «Яндекс Бизнес»? А то у большинства конкурентов, смотрю, рейтинг указывается, а у нас нет. Хотя отзывов на карте много и оценка 5 баллов.
На днях знакомому сайт настраивал и при вставке карты обнаружил эту рекламу. По моему это перебор: реклама занимает около 25-30% области карты. Сначала хотел оствить, как есть, но потом подумал: сайт оказывает услуги, среда весьма конкурентная, а реклама эта - контекстная, что означает, что с большой вероятностью в этих баннерах будет крутиться реклама конкурентов... Правильно я понимаю? Если да, то это уже неприемлемо. Не знаю, озаботился ли этим вопросом Яндекс, но я бы на его месте не показывал бы рекламу в картах по тематике сайта.
Инфраструктурные ограничения в применении к ИИ выглядят зыбкими, даже внятных очертаний нет, не понятно, что именно ограничивать. Да и как ограничивать, если исследовательскую лабораторию можно в рамках одной квартиры развернуть на игровых GPU. Нереально всё это. Сейчас главное препятствие - это обучение с нуля большой модели. Это очень затратно. Но основная масса исследований, как мне видится и направлена на поиск более эффективных алгоритмов обучения.
Это не совсем то. Речь о научных и прочих исследованиях. Наверно, можно мораторий на ядерные испытания притянуть, да и то частично, ведь сами исследования никто не ограничивал.
Ну какие согласованные совместные искусственные замедления развития?... Это хоть когда-нибудь наблюдалось в истории человечества? Очевидно, что с вероятностью близкой к 100% будет вариант D: "Гонка на максимальной скорости, минимум ресурсов на безопасность".
И все-таки слишком много подозрений, что и многочисленные "побеги из песочницы", и пресловутая самостоятельность и самоорганизация Агентов, и хайп про AGI и интеллект более мощный, чем у человека – лишь уловка разработчиков, чтобы продолжать доить инвесторов,
А есть какие-то сомнения? Меня удивляет то, что многие всерьез обсуждают эти "побеги" из курятника...
Если я условно знаю бэк и прошу накидай мне на React фронт, то я в 0 уйду?
Да, в ноль. На прод вы такой код не выкатите. Для своего простенького проекта - да, для проверки гипотезы - да, но для прода - нет. Да и для своего проекта, если он не совсем простой, - тоже нет. Вам по любому придется разбираться с фронтэндом, уточнять задания, разбивать на шаги, проверять. Просто со знаниями бэкэнда это будет сделать намного проще.
Не очень понимаю этого хайпа и возгласов "всё пропало!" от программистов. От обывателей это слышать понятно, но от профи не очень. Я даже верстку не могу поручить ИИ в полной мере. Отдельные кусочки - да, для экпериментального проекта - да, но в качестве волшебного горшочка для серьезного проекта, для продакшена - нет. Когда верстка разбивается на сотни компонентов, когда важна строгая система наименований и пр.... это всё надо объяснять нейросети, разбивать на мелкие шаги, потом всё контролировать... Это возможно, но это получается каша из топора. В итоге так или иначе мы приходим к тому, что без режиссера, глубоко знающего тему, не обойтись. В его руках ИИ - это мощный инструмент, умножающий производительность например на 10. Но если у режиссера ноль знаний, то ноль, умноженный хоть на тыщу, останется нулем.
А вот по поводу разработки своих проектов с автором полностью согласен. ИИ сейчас с лихвой закрывает области где я как разработчик слаб. Аж глаза разбегаются от перспектив. А главное - в этих проектах ответственность околнулевая, поэтому можно смело использовать код сгенерированный ИИшкой. Ну а уж если какой-то проект выстрелит, тогда... наверняка придется его проектировать и переписывать по нормальному. С учетом полученных экспериментальных реальных данных.
В общем я вижу только плюсы. Особенно большие плюсы, думаю, получат те, кто хорошо знает (и увлекается) другие неайтишные области. Вот на стыке этих областей с айти + ИИ и будет хороший буст.
И главное, очень сложно интерпретировать результат, т.е. объяснить его, даже если он правильный. Нейросеть - это черный ящик. Я в своих сервисах с LLM буду делать акцент на первоисточниках. Т.е. для каждого утверждения необходимо давать ссылку на первоисточник. Иначе сервис становится просто опасным.
Проблема не в персональных данных, а в резиновой невнятной трактовке.
Например, маленькому обучающему сайтику ничего не нужно кроме email. Это перс. данные? Вряд ли. Это надо большой фантазией обладать, чтобы отнести email к перс. данным. Но формально email относят к перс. данным. Или... не относят...
А куки сами по себе вообще не относятся к перс. данным. Например, если я мой сайт будет в куке хранить размер шрифта, это перс. данные? Очевидно, нет. Даже если в куке будет храниться уникальный ID посетителя, это тоже еще не перс.данные, т.к. номер этот сам сайтик и генерит (буквально от балды). А вот если сайт соберет реальные перс. данные и свяжет их с id в куках, тогда да - можно трактовать этот id как перс. данные. Но не куки сами по себе.
Если же трактовать всё формально, то под сбор перс. данных можно отнести даже сайт визитку (или вообще страницу-заглушку) без установленных метрических программ.
ЗЫ:
В мультике про козленка, который всех посчитал, по сути показан процесс установки кук, т.е. он (козленок) по формальной широкой трактовке проводил сбор перс. данных, за что и огреб...
На самом деле, всё проще: вставляете флешку большого объема в роутер и вот у вас хоть какое-то хранилище для локальных бэкапов.
Я тоже думаю над проектами (некоторые даже выстрелили) и вижу такие проблемы:
1) Самая жирная проблема: источник картинок и пр. как объектов авторских прав. Сейчас подача исков на всех и вся превратилась в массовое явление. Мои бизнес-партнеры уже отказываются и от официальных фотостоков, т.к. постоянно доказывать легальность фоток стала занимать много времени и ресурсов. А "бесплатные" фотки тоже несут риски, т.к. не понятно кто и почему поставил эту метку. Так что сейчас аккуратно надо быть с этим. Это одна из причин, почему все массово переходят на нейрогенерацию картинок. Бегать по судам никому не хочется. Даже если картинки легально куплены.
2) Языковые модели ненадежны. Даже если им предоставить правильную исходную информацию, они могут сделать неправильные выводы. Это означает, что в обязательном порядке на каждое утверждение нужно приводить ссылки на источники. Т.е. пользователю в обязательном порядке надо будет изучать источники. А если так, то бОльшая часть удобства сервиса нивелируется.
3) В таких проектах важна репутация. Почему я должен верить этой информации? - задает вопрос пользователь. Даже если речь о подборке ссылок на источники, то пользователь будет задаваться вопросами: Насколько она точна? Насколько полна? Надо всё перепроверять. И приходит к выводу, что... скрипач не нужен...
4) Огромное количество бесплатных альтернатив, перебить которые вы можете только репутацией (см. пункт 3).
5) Из личного опыта могу сказать, что оценить проект пользователи (и бизнес) могут не сразу, а лишь через несколько лет. Так что первые выводы (за первый год) - это еще не показатель провала.
Каким имхо должен быть сервис, чтобы "выстрелил":
1) Должен решать реальную проблему бизнеса (желательно именно бизнеса).
2) Сервис должен быть по настоящему уникальным.
3) Сервис должен иметь простое, но нетривиальное решение (см. п. 4).
4) Сервис должен казаться нереализуемым или очень сложно реализуемым, чтобы конкуренты с низкими бюджетами отсеялись сразу. А дяди с большими ресурсами... обычно тормозные, с большой инерцией, пока раскачаются... им проще будет выкупить ваш проект вместе с вами...
Два вопроса:
1) А паспортные данные ИП тоже попадают в публичный доступ?
2) Если речь о яндекс-метрике, то какой адрес ЦОДа указывать? Где его брать? Данные ведь хранятся у Яндекса и им же собираются обрабатываются. Сервер сайта ведь не имеет к этим данным никакого отношения.
Наверно всё же речь о сервисе как публичной услуге?
Иначе (при широкой трактовке) абсолютно все зарубежные серверы попали бы под запрет. По той простой причине, что любой установленный на зарубежном сервере софт будет иметь доступ ко всему. И речь ведь не о VPN. VPN-это лишь частный случай. А в общем случае веб-сервер, ftp-сервер, ssh-сервер и пр. и пр. и пр. , т.е. почти любую прогу можно трактовать как предоставляющую (теоретически) доступ...
Надеюсь, разум возобладает.
Ждем. И хотелось бы там рассмотреть вопрос производительности предлагаемых решений, т.к. если документов больше миллиона (а такие корпуса наиболее интересны), то стоимость обработки документа выходит на первый план, т.к. обычно более интеллектуальные алгоритмы и более ресурсозатратные.
По моему опыту простые способы разбиения на чанки (по размеру или по абзацам) работают откровенно плохо. А семантические способы подходят только для маленьких корпусов документов. Если документов например миллионы, то уже на этапе разбиения на чанки возникают огромные проблемы.
Почему то этот процесс (разбиения на чанки) зачастую затрагивается лишь вскользь, а по мне - это самый важный этап, намного более важный чем дальнейшие способы поиска и ранжирования. Векторный поиск вообще адекватно работает только в том случае, если каждый компактный чанк имеет хорошо выраженную узко тематическую направленность. В противном случае мы получим мусор на выходе, какие бы совершенные алгоритмы ни применяли для поиска.
В НК эта проблема не так остро выражена, т.к. в статьях не так много отвлеченных абзацев. Однако в книгах, статьях, обзорах и пр. половина абзацев может быть на слишком общие темы (например, вводные), или на отвлеченные, или смежные. Всё это вводит огромный шум, что делает семантический поиск намного хуже, чем тупо BM25.
А при работе с огромным количеством документов я вообще не вижу альтернативы мешку слов (BM25). К примеру, если в корпусе десятки миллионов документов, то уже простая векторизация выглядит неподъемной задачей. С другой стороны, на таких объемах скорей всего BM25 будет работать лучше, чем семантический поиск. Просто напросто за счет разнообразия изложения одной и той же темы разными словами.
В общем, это я к тому, что всё очень классно и здорово выглядит на бумаге, а в реальных проектах возникает огромное количество проблем, где простые подходы перестают работать... Или наоборот - старый добрый BM25 будет лучшим решением.
Да, наверняка к коду карты еще и код РСЯ добавится, а он тоже не мало весит.
Что в итоге:
Вариант 1 (без карты или карта картинкой).
Ваша страница легкая. В картинках прописана ленивая загрузка, а неключевые скрипты имеют отложенную загрузку.
Страницу открывает посетитель со смартфона с неустойчивой 3G связью:
Сначала грузится компактный файлик css (10КБ), потом html-код страницы (50КБ) и посетитель уже видит текст на первом экране. И только потом лениво загружаются большие картинки и скрипты.
Главное - посетитель через пару секунд уже может читать текст, а еще через пару секунд увидит карту в виде картинки.
Вариант 2 (карта через API или iframe):
Карты имеют асинхронную загрузку, поэтому предсказать последовательность загрузки невозможно.
Итак, посетителю не повезло и первыми начали загружаться скрипты карты и рекламы (>1МБ), а также карточные тайлы и картинки рекламных баннеров (объем боюсь представить).
Неустойчивый 3G канал посетителя забит намертво, не то что картинки сайта не загружаются, но даже и css/html-код может встать в очередь... на пару минут...
В общем банальная вставка предоставляемого кода карты на страницу - это не очень хорошая затея. Нужно смотреть, как это скажется на мобильных посетителях.
Коммерческую карту заскриншотить нельзя - будет нарушение авторских прав, как я понимаю. Свободную OSM можно. И простой картинкой, кстати, намного лучше в отношении скорости работы сайта. А встроенная через api карта (через код вставки) обычно тянет за собой мегатонны лишнего трафика, что плохо сказывается на метриках.
Подскажите плиз, а может отсутствие рейтинга (звездочки с количеством отзывов) в выдаче яндекса быть связано с отсутствием платной подписки на «Яндекс Бизнес»? А то у большинства конкурентов, смотрю, рейтинг указывается, а у нас нет. Хотя отзывов на карте много и оценка 5 баллов.
На днях знакомому сайт настраивал и при вставке карты обнаружил эту рекламу. По моему это перебор: реклама занимает около 25-30% области карты. Сначала хотел оствить, как есть, но потом подумал: сайт оказывает услуги, среда весьма конкурентная, а реклама эта - контекстная, что означает, что с большой вероятностью в этих баннерах будет крутиться реклама конкурентов... Правильно я понимаю? Если да, то это уже неприемлемо. Не знаю, озаботился ли этим вопросом Яндекс, но я бы на его месте не показывал бы рекламу в картах по тематике сайта.
Инфраструктурные ограничения в применении к ИИ выглядят зыбкими, даже внятных очертаний нет, не понятно, что именно ограничивать. Да и как ограничивать, если исследовательскую лабораторию можно в рамках одной квартиры развернуть на игровых GPU. Нереально всё это. Сейчас главное препятствие - это обучение с нуля большой модели. Это очень затратно. Но основная масса исследований, как мне видится и направлена на поиск более эффективных алгоритмов обучения.
Ну эти ограничения ведь не касаются самих по себе исследований.
Это не совсем то. Речь о научных и прочих исследованиях. Наверно, можно мораторий на ядерные испытания притянуть, да и то частично, ведь сами исследования никто не ограничивал.
Ну какие согласованные совместные искусственные замедления развития?... Это хоть когда-нибудь наблюдалось в истории человечества? Очевидно, что с вероятностью близкой к 100% будет вариант D: "Гонка на максимальной скорости, минимум ресурсов на безопасность".
А есть какие-то сомнения? Меня удивляет то, что многие всерьез обсуждают эти "побеги" из курятника...
Да, в ноль. На прод вы такой код не выкатите. Для своего простенького проекта - да, для проверки гипотезы - да, но для прода - нет. Да и для своего проекта, если он не совсем простой, - тоже нет. Вам по любому придется разбираться с фронтэндом, уточнять задания, разбивать на шаги, проверять. Просто со знаниями бэкэнда это будет сделать намного проще.
Не очень понимаю этого хайпа и возгласов "всё пропало!" от программистов. От обывателей это слышать понятно, но от профи не очень. Я даже верстку не могу поручить ИИ в полной мере. Отдельные кусочки - да, для экпериментального проекта - да, но в качестве волшебного горшочка для серьезного проекта, для продакшена - нет. Когда верстка разбивается на сотни компонентов, когда важна строгая система наименований и пр.... это всё надо объяснять нейросети, разбивать на мелкие шаги, потом всё контролировать... Это возможно, но это получается каша из топора. В итоге так или иначе мы приходим к тому, что без режиссера, глубоко знающего тему, не обойтись. В его руках ИИ - это мощный инструмент, умножающий производительность например на 10. Но если у режиссера ноль знаний, то ноль, умноженный хоть на тыщу, останется нулем.
А вот по поводу разработки своих проектов с автором полностью согласен. ИИ сейчас с лихвой закрывает области где я как разработчик слаб. Аж глаза разбегаются от перспектив. А главное - в этих проектах ответственность околнулевая, поэтому можно смело использовать код сгенерированный ИИшкой. Ну а уж если какой-то проект выстрелит, тогда... наверняка придется его проектировать и переписывать по нормальному. С учетом полученных экспериментальных реальных данных.
В общем я вижу только плюсы. Особенно большие плюсы, думаю, получат те, кто хорошо знает (и увлекается) другие неайтишные области. Вот на стыке этих областей с айти + ИИ и будет хороший буст.
И главное, очень сложно интерпретировать результат, т.е. объяснить его, даже если он правильный. Нейросеть - это черный ящик. Я в своих сервисах с LLM буду делать акцент на первоисточниках. Т.е. для каждого утверждения необходимо давать ссылку на первоисточник. Иначе сервис становится просто опасным.
Проблема не в персональных данных, а в резиновой невнятной трактовке.
Например, маленькому обучающему сайтику ничего не нужно кроме email. Это перс. данные? Вряд ли. Это надо большой фантазией обладать, чтобы отнести email к перс. данным. Но формально email относят к перс. данным. Или... не относят...
А куки сами по себе вообще не относятся к перс. данным. Например, если я мой сайт будет в куке хранить размер шрифта, это перс. данные? Очевидно, нет. Даже если в куке будет храниться уникальный ID посетителя, это тоже еще не перс.данные, т.к. номер этот сам сайтик и генерит (буквально от балды). А вот если сайт соберет реальные перс. данные и свяжет их с id в куках, тогда да - можно трактовать этот id как перс. данные. Но не куки сами по себе.
Если же трактовать всё формально, то под сбор перс. данных можно отнести даже сайт визитку (или вообще страницу-заглушку) без установленных метрических программ.
ЗЫ:
В мультике про козленка, который всех посчитал, по сути показан процесс установки кук, т.е. он (козленок) по формальной широкой трактовке проводил сбор перс. данных, за что и огреб...
А какая скорость у вас на 4090 получилась?
У меня такие скорости для Qwen3.8-27B-UD-Q4_K_XL (с MTP):
4090 ~ 70-80 t/s
5090 ~ 120 t/s
2x5060ti ~ 40 t/s.
Без MTP примерно вдвое меньше.