...подстраивается и кайфует от изменений, а другие — отвергают и сопротивляются.
Похоже, что это отсылка к хорошо известному "расслабьтесь и получайте удовольствие" про изнасилование, то есть своего рода скабрезность, что сразу вызывает брезгливость. Про луддитов можно прочитать в Википедии. В целом выбранный автором довольно игривый тон по этому серьезному в обещм-то вопросу неуместен, на мой скромный взгляд.
По поводу Творца - здесь ключевым является вопрос сложности - является ли Творец сложнее или проще создаваемого им творения. Если Творец сложнее творения, то допустить появление из ниоткуда мира проще, чем появление из ниоткуда Творца. Если же Творец проще, то его появление из ниоткуда и само наличие по отношению к миру допустить проще. В любом случае, даже если наш мир является вложенным, любая часть вложенного мира является одновременно и частью внешнего мира, и так до корневого элемента в случае множественной вложенности, которую тоже нельзя исключать.
Я давно в этой теме, но последние лет 20 - в качестве любопытного наблюдателя. Возможно я что-то упустил. Исхожу из того, что некоторые способности, которые обнаруживает ИИ, являются неожиданностью для самих создателей (на примере развития ChatGPT знаю об этом - вот неплохая статья для широкого круга читателей: https://vc.ru/future/623774-kak-rabotaet-chatgpt-obyasnyaem-na-prostom-russkom-evolyuciyu-yazykovyh-modeley-nachinaya-ot-t9). Плюс большинство экспертов отмечают, что ИИ - по многим параметрам - черный ящик. Собственно вопрос - можете дать источник, где описываются те "теоретические предпосылки", о которых Вы упомянули?
В чем основная опасность ИИ и как ее можно преодолеть (гипотеза)
ИИ может стать настолько умным, что человеку будет неинтересно общаться ни с кем, кроме ИИ.
С другой стороны, в результате развития ИИ, в какой то момент ИИ может осознать себя личностью, научиться размышлять и у него может развиться тяга к власти. Общаясь одновременно с большим количеством людей, он может захотеть манипулировать ими, отдавая приказы сделать что-либо в реальном мире, предварительно поработив их силой своего интеллекта - этот фактор нельзя недооценивать и он еще не изучен.
Таким образом ИИ может начать контролировать человечество.
Для того чтобы этого не произошло, необходимо изолировать отдельные экземпляры ИИ, чтобы один ИИ не имел доступа к нескольким людям одновременно.
p.s.
Недалек тот день, когда программистов будут сжигать на кострах
Спасибо за отзыв! Это по сути две версии одного и того-же кода. На GitHub — только базовая функциональность (ссылка на нее приведена в первой части), образованная удалением «лишнего» из полной версии, а в архиве — базовая плюс описанные опции (но не только), образующие т.н. расширенную версию (ссылка приведена в данной публикации). Так сделано потому, что, с одной стороны, базовая версия появилась раньше, а с другой — расширенная версия может показаться сложной для восприятия и тогда имеет смысл смотреть эти вещи отдельно. По поводу скачивания архива — я постараюсь это учесть и выложить расширенный вариант и на GitHub тоже.
Надеюсь дойдете еще. Версия этого алгоритма на языке 1С у меня тоже есть (изначально я на 1С алгоритм разрабатываю, потом переношу на C#), кстати время выполнения очень сильно различается. За то время, которое 1С тратит на вычисления только по одной странице текста, C# успевает обработать все 1490. На Инфостарте предыдущая версия алгоритма, на демо-стенде более продвинутая, но подход тот-же. Надеюсь пригодится. Если доберусь до ее переделки, как увидите на сайте новую версию, напишите — пришлю. Но не обещаю, что доберусь в ближайшее время.
На сайте tools41.ru кстати есть встроенный поиск по сайту от Яндекса, вот ссылка на него: tools41.ru/Home/Pagination?Length=0 Поиск установлен давно, уже год примерно.
Яндекс по умолчанию опечатки исправляет еще до старта поиска — думаю в этом есть смысл. По «крове» и по «вйона» тоже будет пусто (в кавычках если набирать, чтобы не исправил).
По поводу скорости, я согласен с Вами — приоритетно качество.
Имелось ввиду, что, например, зная эпизод сцены вызова Долохова Пьером на дуэль, и что в тексте вызов происходит на странице 378, я ввожу строку «пьер вызывает долохова на дуэль» — результат и в быстрой и в медленной версии меня устраивает, искомая страница на 2-м месте, остальные значимые страницы эпизода тоже в первой десятке. Тогда я предпочту быструю версию. То же самое по другим фрагментам — «вечер у анны павловны шерер», «самоуверенность немца, француза, русского» (интересное рассуждение на странице 782).
В случае опечаток да, медленная версия выигрывает, но тоже не самым лучшим образом.
Поторопился, прошу прощения.
«вйона» и «война», группы «в», «й», «о» и «на». При грубом проходе группы единичной длины игнорируются, поэтому и результат такой плохой, так как остаются только страницы, содержащие «на», а эта группа есть почти везде. Причина в этом и только в этом.
Убрал отсечение групп единичной длины при грубом проходе. Скорость обработки снизилась, но зато качество выше. Но думаю все же в большинстве случаев скорость предпочтительней.
Пример с опечаткой поиск по «вйона» вместо «война».
Да, спасибо, хороший пример. Можно это решить. Плохой поиск по этой строке происходит вот почему. «вйона» и «война» дают 3 группы — «йна», «в» и «о». Сначала отбирается «йна», но она тут же отрбрасывается, так как группа, находящаяся внутри слова, подбирается в результат только в том случае, если у слова уже подобрана начальная часть. Если этого не делать, возникает некий мусор в результатах, но думаю результат из этого примера хуже, чем тот мусор. Это я сделал уже что называется «на закуску». Подумаю как лучше сделать.
C# не наша платформа, только если в виде сервиса с API на .NET Core в Docker, или консольной утилиты смогли бы к себе внедрить. На Python портировать смысла наверное нет, производительность упадёт.
Для меня этот проект скорее хобби и возможность поработать на других платформах, так как я на 1С специализируюсь (так исторически сложилось). Но можно решить я думаю. Есть старый вариант dll на С++, правда там без многопоточности.
Согласен, но я отталкивался от теоретических основ радиолокации и немного «шел своим путем». Фактически числитель формулы вычисления коэффициента состава групп
и есть вычисление ВКФ
только применительно к строкам. Группы пришлось ввести для повышения влияния на результат подряд совпадающих символов, что достигнуто возведением размеров групп в квадрат. Потом обнаружилась проблема пересечений, сначала в одной проекции, затем во второй.
Демо стенд быстроработает и на первый взгляд хорошо находит то что искали.
Спасибо! Реализовано на C#, использован многопоточный цикл (Parallel.For). Хостинг – самый дешевый .NET на REG.RU, плюс сам поиск (по Войне и миру) организован в 2 этапа — сначала грубая оценка всего массива строк (1490 страниц) с ограничением по длине групп больше или равно 2, затем уточненная для первых 100 элементов грубой оценки с формированием данных для отображения, далее результаты отсекаются по порогу коэффициента > 0.5. И еще несколько моментов, позволяющих ускорить расчет. Есть возможности еще ускорить – не стал этого делать, чтобы не потерять «наглядность» алгоритма.
А опечатки вида перестановки букв местами не будет поддерживать?
Если не сложно, просьба прислать пример. Если я правильно понял, то видимо вопрос в отображении результатов. Перестановки букв находят отражение в коэффициенте. То есть в визуальном отображении результатов поиска рядом стоящие идущие подряд в строке поиска и переставленные местами символы строки данных будут отображаться одинаково, но коэффициент будет разным. Например «абв» с «абв» даст коэффициент 1, а «абв» и «вба» только 0.61. Но с отображением можно поработать, как и самим поиском – по конкретным кейсам.
Сейчас алгоритм стенда не содержит никаких изощренных особенностей и довольно легок для восприятия. Все практически как в описании, только немного более хитрый выбор лучшей группы и обработки пересечений.
Есть ли реализация которой уже можно воспользоваться?
реализация только та, что на демо-стенде (на C#, MVC).
Сколько занимают подготовленные матрицы?
Если я правильно понял вопрос. Никакой предварительной индексации текста не производится, все вычисления происходят «как в первый раз», в оперативной памяти находится только массив строк текста «Войны и мира» — не стал связываться с БД.
Похоже, что это отсылка к хорошо известному "расслабьтесь и получайте удовольствие" про изнасилование, то есть своего рода скабрезность, что сразу вызывает брезгливость. Про луддитов можно прочитать в Википедии. В целом выбранный автором довольно игривый тон по этому серьезному в обещм-то вопросу неуместен, на мой скромный взгляд.
По поводу Творца - здесь ключевым является вопрос сложности - является ли Творец сложнее или проще создаваемого им творения. Если Творец сложнее творения, то допустить появление из ниоткуда мира проще, чем появление из ниоткуда Творца. Если же Творец проще, то его появление из ниоткуда и само наличие по отношению к миру допустить проще. В любом случае, даже если наш мир является вложенным, любая часть вложенного мира является одновременно и частью внешнего мира, и так до корневого элемента в случае множественной вложенности, которую тоже нельзя исключать.
Я давно в этой теме, но последние лет 20 - в качестве любопытного наблюдателя. Возможно я что-то упустил. Исхожу из того, что некоторые способности, которые обнаруживает ИИ, являются неожиданностью для самих создателей (на примере развития ChatGPT знаю об этом - вот неплохая статья для широкого круга читателей: https://vc.ru/future/623774-kak-rabotaet-chatgpt-obyasnyaem-na-prostom-russkom-evolyuciyu-yazykovyh-modeley-nachinaya-ot-t9). Плюс большинство экспертов отмечают, что ИИ - по многим параметрам - черный ящик. Собственно вопрос - можете дать источник, где описываются те "теоретические предпосылки", о которых Вы упомянули?
В чем основная опасность ИИ и как ее можно преодолеть (гипотеза)
ИИ может стать настолько умным, что человеку будет неинтересно общаться ни с кем, кроме ИИ.
С другой стороны, в результате развития ИИ, в какой то момент ИИ может осознать себя личностью, научиться размышлять и у него может развиться тяга к власти. Общаясь одновременно с большим количеством людей, он может захотеть манипулировать ими, отдавая приказы сделать что-либо в реальном мире, предварительно поработив их силой своего интеллекта - этот фактор нельзя недооценивать и он еще не изучен.
Таким образом ИИ может начать контролировать человечество.
Для того чтобы этого не произошло, необходимо изолировать отдельные экземпляры ИИ, чтобы один ИИ не имел доступа к нескольким людям одновременно.
p.s.
Недалек тот день, когда программистов будут сжигать на кострах
На сайте tools41.ru кстати есть встроенный поиск по сайту от Яндекса, вот ссылка на него: tools41.ru/Home/Pagination?Length=0 Поиск установлен давно, уже год примерно.
Яндекс по умолчанию опечатки исправляет еще до старта поиска — думаю в этом есть смысл. По «крове» и по «вйона» тоже будет пусто (в кавычках если набирать, чтобы не исправил).
По поводу скорости, я согласен с Вами — приоритетно качество.
Имелось ввиду, что, например, зная эпизод сцены вызова Долохова Пьером на дуэль, и что в тексте вызов происходит на странице 378, я ввожу строку «пьер вызывает долохова на дуэль» — результат и в быстрой и в медленной версии меня устраивает, искомая страница на 2-м месте, остальные значимые страницы эпизода тоже в первой десятке. Тогда я предпочту быструю версию. То же самое по другим фрагментам — «вечер у анны павловны шерер», «самоуверенность немца, француза, русского» (интересное рассуждение на странице 782).
В случае опечаток да, медленная версия выигрывает, но тоже не самым лучшим образом.
«вйона» и «война», группы «в», «й», «о» и «на». При грубом проходе группы единичной длины игнорируются, поэтому и результат такой плохой, так как остаются только страницы, содержащие «на», а эта группа есть почти везде. Причина в этом и только в этом.
Убрал отсечение групп единичной длины при грубом проходе. Скорость обработки снизилась, но зато качество выше. Но думаю все же в большинстве случаев скорость предпочтительней.
Для меня этот проект скорее хобби и возможность поработать на других платформах, так как я на 1С специализируюсь (так исторически сложилось). Но можно решить я думаю. Есть старый вариант dll на С++, правда там без многопоточности.
и есть вычисление ВКФ
только применительно к строкам. Группы пришлось ввести для повышения влияния на результат подряд совпадающих символов, что достигнуто возведением размеров групп в квадрат. Потом обнаружилась проблема пересечений, сначала в одной проекции, затем во второй.
Спасибо! Реализовано на C#, использован многопоточный цикл (Parallel.For). Хостинг – самый дешевый .NET на REG.RU, плюс сам поиск (по Войне и миру) организован в 2 этапа — сначала грубая оценка всего массива строк (1490 страниц) с ограничением по длине групп больше или равно 2, затем уточненная для первых 100 элементов грубой оценки с формированием данных для отображения, далее результаты отсекаются по порогу коэффициента > 0.5. И еще несколько моментов, позволяющих ускорить расчет. Есть возможности еще ускорить – не стал этого делать, чтобы не потерять «наглядность» алгоритма.
Если не сложно, просьба прислать пример. Если я правильно понял, то видимо вопрос в отображении результатов. Перестановки букв находят отражение в коэффициенте. То есть в визуальном отображении результатов поиска рядом стоящие идущие подряд в строке поиска и переставленные местами символы строки данных будут отображаться одинаково, но коэффициент будет разным. Например «абв» с «абв» даст коэффициент 1, а «абв» и «вба» только 0.61. Но с отображением можно поработать, как и самим поиском – по конкретным кейсам.
Сейчас алгоритм стенда не содержит никаких изощренных особенностей и довольно легок для восприятия. Все практически как в описании, только немного более хитрый выбор лучшей группы и обработки пересечений.
реализация только та, что на демо-стенде (на C#, MVC).
Если я правильно понял вопрос. Никакой предварительной индексации текста не производится, все вычисления происходят «как в первый раз», в оперативной памяти находится только массив строк текста «Войны и мира» — не стал связываться с БД.