С одной стороны, молодец, безумству храбрых поем мы песню. С другой - так и представляю этот набор костылей, смотанных изолентой, где похожие штуки маппятся примерно, потому что они похожи, а местами торчат подпорки, потому что в итоге игры чуть могут не сходиться на концептуальном уровне - иметь другие типы объектов, больше или меньше типов кубов, не иметь части функций и т.д
Очень странная статья. Вы в целом о чем говорите? Как что-то "вплетается" в "ткань" модели?
Если речь о том, что из чатов пользователя с моделью потом выбираются диалоги, обрабатываются и используются в следующих сессиях обучения/тюна - вероятно так и есть. Но только это очень опосредованно влияет на память в контексте типичных задач. Для вас, получающего галлюцинации по запросу о правилах строительства стула, то, что связь между словом "стул" и словом "деревянный" укрепилась на 0,0007% какой то серьезной выгоды нет. Если речь о системах искусственной памяти (когда в запрос подмешиваются предыдущие диалоги или их сокращенная версия) - в этом есть ограничения и оно работает как память, безо всяких забываний. Но никакой магии между этими двумя процессами вроде нет.
Поэтому непонятно, в чем тут не миф, если модели действительно не помнят ничего за пределами сессий.
Душу там найдут, вселенский мозг, гномиков. Ну то есть может еще фундаментальные штуки есть в мозге, которые делают описание "статистический попугай" некорректным. Автомобили, к примеру, не сводятся к "бензиноподрывателям", хотя двигатели работают именно так.
Ну, к сожалению термины не так просто работают, они же не вещь в себе. У символистов нет на них монополии. Если их активно используют в других значениях (а их используют для любой интеллектуальной деятельности под руководством компьютера со времен компьютерных игр), то неопределенность возникает независимо от того, хотим ли мы это или нет. Поэтому стоит уточнять. Понятно что отдельная шутка в том, что они General просто потому, что довольно много специализированных задач решается современными ИИ очень хорошо.
Безусловно текущие LLM - это статистические попугаи, но вопрос в том, знаем ли мы, из чего состоит "полноценный" ИИ и являются ли LLM путем к нему. Ну или другие варианты, например мультимодульные, LLM попрекают работой только в текстовом пространстве. Сделать их агентными можно и сейчас, над памятью, контекстом и дообучением уже работают. Это может быть просто вопросом архитектуры. Мы тоже может статистические попугаи
Ну надо сказать, что такие игры могут не появляться по разумной причине - это так себе пользовательский опыт.
Если ты можешь запустить игру быстрее - запусти лучше игру, а не маскировочный заместитель. Если игра грузится так долго, что ты можешь поиграть в другую игру - возможно ты что-то делаешь не так и нужно догружать ресурсы на ходу или оптимизировать.
Плюс, это отнимает ресурсы от основного процесса, пусть и небольшие - саму демку то ведь тоже надо запустить и игра в нее отнимает процессорное время.
Ну и в итоге может вообще в демку играть интереснее?
Впрочем есть много решений, хороших в конкретном случае.
Из наблюдаемого - мобильный Марио карт позволяет играть в игру типа хромовского динозаврика (перепрыгивай препятствия, нажимая вовремя), пока ресурсы грузятся из интернета.
Вроде демы как явление появились все же не так, а благодаря пиратским группам, которые шли от текстового файла вместе со сломанной игрой к сложным интро, где группа хвалит себя с какими то крутыми эффектами.
То есть принцип "сделать поменьше" хорош, но мотивация другая.
Впрочем это могут быть и не взаимоисключающие версии.
Вообще во многих контекстах эти термины - синонимы. Вы сами перевод указали.
Но в ПО вроде сложился консенсус, схожий с вашим, в контексте работы со старыми системами.
Эмуляция - полное воспроизведение работы системы, для потребителя не отличается от реального процесса.
Симуляция - воспроизведение функционально важных частей. Во многих случаях, как и в первом случае, позволяет получать неотличимый от реального процесс.
Имитация - воспроизведение внешних атрибутов процесса, частичное воспроизведение его свойств.
Из текста не очевидно, афера длится или доверие длится 300 лет.
В любом случае утверждение байтящее и сомнительное - и арифмометрам и компьютерам ещё как не доверяли, а llm довольно быстро показала, что относится к нечетким методам.
Что касается страхов и надежд - то тут сошлось много факторов.
Во первых есть ИИ а есть - ИИ.
То есть есть то, что сейчас называют ИИ - llm, распознавание и генерация голоса и изображений, специализированные автоматические системы и прочие чудеса машинного обучения. С ними связаны одна группа рисков и много хайпа.
А есть потенциальный ИИ. Это может быть сильный ИИ, это может быть просто достаточно мощный AGI. И его возможности потенциально могут быть непропорционально велики.
Соответственно его использование может принести как невиданные блага так и неопределенные, но глобальные риски.
Нет, обычное натягивание совы на глобус. Так то много кто описывал автоматические и полуавтоматические системы и всякие хитрые шаблоны. Бэббридж изобрел принцип хранения команд вместе с калькулируемыми данными в памяти, то есть автоматизации вычислений. Он изобрел в этом смысле компьютер. Но компьютер так то сложное устройство и различные его элементы были изобретены и улучшены в разное время.
Да нет, все с историей Китая нормально Это очень населенный регион, в отдельные периоды истории там чуть ли не треть населения жило, были очень развитые по меркам эпохи государства. Так что и драмы и достижений хватает.
Просто девятнадцатый век и пром революция сделали историю очень европоцентричной, но это история последних 300 лет В условном 11 веке разборки условных Англичан по меркам Китайцев были драками деревень.
Проблема в том, что человек в работе многих организаций - это тоже в целом инструмент. Зачастую. Проблемный, законы требуют его уважать и на него постоянные расходы, но зато универсальный. Но на больших числах очень хорошо видно - вот у нас 20 работников склада, а вот 7 + погрузчик + водитель. Погрузчик подороже, плюс палеты нужно использовать, зато купил один раз и системные расходы закончились надолго.
Ну вот вы ровно и показали, как это запутывает. Если O - это константа, значит O(1) всегда меньше O(n) для n > 1. Так можно понять, хотя на самом деле лишь подчеркивает динамику с изменением n
Проблема ведь в том, что нельзя игнорировать и алгоритм.
Мой косяк, Я имел в виду именно функции, подпрограммы, процедуры как абстракцию и как механизм программирования. Для этого ведь изобрели и стек, и всякие хитрые параметры передачи.
Мы недооцениваем этот слой, а людям так то потребовалось время, чтобы прийти к структурному программированию (цикл и условие могут описать любой алгоритм) и иерархической организации (части кода можно переиспользовать)
Функциональное программирование в каком то смысле уже относится к другому концепту и идеологии, тяготея к декларативному стилю - описанию, какие преобразования надо применить к данным.
Все это конечно хорошо, но разве не логично допустить мысль, что причины прозаичнее - столько не нужно, даже квалифицированных? В смысле идет война, экономике плохо, бизнесу тоже. Условия постоянно меняются, деньги дорогие - планировать в таком режиме очень сложно. Наем людей - это тоже элемент долгосрочного планирования. Соответственно если существующие проекты как то поддерживаются (но в основном теми же людьми, которые их и строили - они же не испарятся куда то?), но новые разворачиваются очень мало.
То есть дело не в том, что ты не можешь создать/поддерживать проект, а в том, что никому не нужны проекты. На это конечно накладывается проблема курсов и инертности - был недостаток персонала и высокий спрос, курсы как то пытались решить это. Спрос ушел, курсы остались.
Да, ну и сам концепт организации в процедуры / функции, как и функциональное программирование как бы являются инструментами и составными частями императивного программирования.
Возможно стоит упомянуть и ООП в смысле Алана Кэя - что это подход к организации программы через создание обособленных объектов (включающих как данные так и их обработку) и отправку сообщений между ними.
Такой подход решает несколько задач - организация и декомпозиция кода, хороший контроль состояния (путем разбиения сложного состояния на иерархии простых) и хороший контроль операций и входных данных (потому что объект решает как обрабатывать сообщения применительно к своим данным)
В этом смысле агенто-ориентированное программирование (Которое акторное) или, например, микросервисы - это хрестоматийное следование идеям ООП на разных уровнях.
Еще можно упомянуть связи между подходами - почти все современные ЯП используют императивное и структурное программирование как базу, имеют инструменты для метапрограммирования, опираются на системы типов разной мощности. Часть подходов являются подразделами друг друга - например data-flow подход это в каком то смысле простая идея, что "процесс - это тоже объект"
Есть еще важный фактор, который не отражен в чистой O нотации - длина единичной операции. O(1) может быть настолько дорогим для каждого элемента, что его победит перебор по массиву O(n) Хэш таблицы используют, ну, хэши (которые может требоваться вычислять) и таблицы (в смысле сложную внутреннюю организацию с чанками), в то время как последовательный перебор массива очень прост и хорошо дружит с кешем.
В итоге простыми экспериментами можно найти, до какого количества элементов выгоднее использовать массивы, и это может быть на удивление большое число.
Почти для всех приведенных пунктов есть одна важная забытая деталь - границы применимости. Они вечно теряются.
А меж тем практически каждый пункт перестает работать при чрезмерном использовании либо наоборот - стоит слишком дорого в случаях, где использование недостаточно.
Комплексные архитектуры избыточны для простого приложения от одного разработчика, а в сложном проекте нельзя сделать просто. Декомпозиция важна, чрезмерная декомпозиция делает код нечитаемым. Комментарии действительно могут устаревать и путать быстрее кода и частично замещаются хорошим неймингом, но API и сложные места/оптимизации требуют комментариев. И так далее.
Поэтому и важны нюансы, и ответы не только на вопрос "как", но и "почему".
Ну помимо ручной модерации еще есть и фильтры, системы оценок и прочие методы. Просто цели разные. Поэтому мобильные сторы завалены фигней и не видно ничего, а, к примеру, стим, таки показывает сверху годноту и прячет инди мусор, которого достаточно (его можно увидеть, если листать любую категорию достаточно долго)
Но да, это проблема и фильтров. Но это, тем не менее, не мешает называть слоп слопом. Я как бы не виню разработчиков инди игр, им нужно учиться, но мусором это быть не перестает.
С одной стороны, молодец, безумству храбрых поем мы песню.
С другой - так и представляю этот набор костылей, смотанных изолентой, где похожие штуки маппятся примерно, потому что они похожи, а местами торчат подпорки, потому что в итоге игры чуть могут не сходиться на концептуальном уровне - иметь другие типы объектов, больше или меньше типов кубов, не иметь части функций и т.д
Не в упрек моддеру конечно
Очень странная статья. Вы в целом о чем говорите?
Как что-то "вплетается" в "ткань" модели?
Если речь о том, что из чатов пользователя с моделью потом выбираются диалоги, обрабатываются и используются в следующих сессиях обучения/тюна - вероятно так и есть.
Но только это очень опосредованно влияет на память в контексте типичных задач.
Для вас, получающего галлюцинации по запросу о правилах строительства стула, то, что связь между словом "стул" и словом "деревянный" укрепилась на 0,0007% какой то серьезной выгоды нет.
Если речь о системах искусственной памяти (когда в запрос подмешиваются предыдущие диалоги или их сокращенная версия) - в этом есть ограничения и оно работает как память, безо всяких забываний.
Но никакой магии между этими двумя процессами вроде нет.
Поэтому непонятно, в чем тут не миф, если модели действительно не помнят ничего за пределами сессий.
Душу там найдут, вселенский мозг, гномиков.
Ну то есть может еще фундаментальные штуки есть в мозге, которые делают описание "статистический попугай" некорректным.
Автомобили, к примеру, не сводятся к "бензиноподрывателям", хотя двигатели работают именно так.
Ну, к сожалению термины не так просто работают, они же не вещь в себе.
У символистов нет на них монополии.
Если их активно используют в других значениях (а их используют для любой интеллектуальной деятельности под руководством компьютера со времен компьютерных игр), то неопределенность возникает независимо от того, хотим ли мы это или нет.
Поэтому стоит уточнять.
Понятно что отдельная шутка в том, что они General просто потому, что довольно много специализированных задач решается современными ИИ очень хорошо.
Безусловно текущие LLM - это статистические попугаи, но вопрос в том, знаем ли мы, из чего состоит "полноценный" ИИ и являются ли LLM путем к нему. Ну или другие варианты, например мультимодульные, LLM попрекают работой только в текстовом пространстве.
Сделать их агентными можно и сейчас, над памятью, контекстом и дообучением уже работают.
Это может быть просто вопросом архитектуры.
Мы тоже может статистические попугаи
Ну надо сказать, что такие игры могут не появляться по разумной причине - это так себе пользовательский опыт.
Если ты можешь запустить игру быстрее - запусти лучше игру, а не маскировочный заместитель. Если игра грузится так долго, что ты можешь поиграть в другую игру - возможно ты что-то делаешь не так и нужно догружать ресурсы на ходу или оптимизировать.
Плюс, это отнимает ресурсы от основного процесса, пусть и небольшие - саму демку то ведь тоже надо запустить и игра в нее отнимает процессорное время.
Ну и в итоге может вообще в демку играть интереснее?
Впрочем есть много решений, хороших в конкретном случае.
Из наблюдаемого - мобильный Марио карт позволяет играть в игру типа хромовского динозаврика (перепрыгивай препятствия, нажимая вовремя), пока ресурсы грузятся из интернета.
Игра впрочем так себе
Вроде демы как явление появились все же не так, а благодаря пиратским группам, которые шли от текстового файла вместе со сломанной игрой к сложным интро, где группа хвалит себя с какими то крутыми эффектами.
То есть принцип "сделать поменьше" хорош, но мотивация другая.
Впрочем это могут быть и не взаимоисключающие версии.
Вообще во многих контекстах эти термины - синонимы. Вы сами перевод указали.
Но в ПО вроде сложился консенсус, схожий с вашим, в контексте работы со старыми системами.
Эмуляция - полное воспроизведение работы системы, для потребителя не отличается от реального процесса.
Симуляция - воспроизведение функционально важных частей. Во многих случаях, как и в первом случае, позволяет получать неотличимый от реального процесс.
Имитация - воспроизведение внешних атрибутов процесса, частичное воспроизведение его свойств.
Из текста не очевидно, афера длится или доверие длится 300 лет.
В любом случае утверждение байтящее и сомнительное - и арифмометрам и компьютерам ещё как не доверяли, а llm довольно быстро показала, что относится к нечетким методам.
Что касается страхов и надежд - то тут сошлось много факторов.
Во первых есть ИИ а есть - ИИ.
То есть есть то, что сейчас называют ИИ - llm, распознавание и генерация голоса и изображений, специализированные автоматические системы и прочие чудеса машинного обучения. С ними связаны одна группа рисков и много хайпа.
А есть потенциальный ИИ. Это может быть сильный ИИ, это может быть просто достаточно мощный AGI. И его возможности потенциально могут быть непропорционально велики.
Соответственно его использование может принести как невиданные блага так и неопределенные, но глобальные риски.
Нет, обычное натягивание совы на глобус.
Так то много кто описывал автоматические и полуавтоматические системы и всякие хитрые шаблоны.
Бэббридж изобрел принцип хранения команд вместе с калькулируемыми данными в памяти, то есть автоматизации вычислений. Он изобрел в этом смысле компьютер.
Но компьютер так то сложное устройство и различные его элементы были изобретены и улучшены в разное время.
Да нет, все с историей Китая нормально
Это очень населенный регион, в отдельные периоды истории там чуть ли не треть населения жило, были очень развитые по меркам эпохи государства.
Так что и драмы и достижений хватает.
Просто девятнадцатый век и пром революция сделали историю очень европоцентричной, но это история последних 300 лет
В условном 11 веке разборки условных Англичан по меркам Китайцев были драками деревень.
Проблема в том, что человек в работе многих организаций - это тоже в целом инструмент.
Зачастую.
Проблемный, законы требуют его уважать и на него постоянные расходы, но зато универсальный.
Но на больших числах очень хорошо видно - вот у нас 20 работников склада, а вот 7 + погрузчик + водитель. Погрузчик подороже, плюс палеты нужно использовать, зато купил один раз и системные расходы закончились надолго.
Ну вот вы ровно и показали, как это запутывает.
Если O - это константа, значит O(1) всегда меньше O(n) для n > 1.
Так можно понять, хотя на самом деле лишь подчеркивает динамику с изменением n
Проблема ведь в том, что нельзя игнорировать и алгоритм.
Мой косяк, Я имел в виду именно функции, подпрограммы, процедуры как абстракцию и как механизм программирования.
Для этого ведь изобрели и стек, и всякие хитрые параметры передачи.
Мы недооцениваем этот слой, а людям так то потребовалось время, чтобы прийти к структурному программированию (цикл и условие могут описать любой алгоритм) и иерархической организации (части кода можно переиспользовать)
Функциональное программирование в каком то смысле уже относится к другому концепту и идеологии, тяготея к декларативному стилю - описанию, какие преобразования надо применить к данным.
Все это конечно хорошо, но разве не логично допустить мысль, что причины прозаичнее - столько не нужно, даже квалифицированных?
В смысле идет война, экономике плохо, бизнесу тоже.
Условия постоянно меняются, деньги дорогие - планировать в таком режиме очень сложно. Наем людей - это тоже элемент долгосрочного планирования.
Соответственно если существующие проекты как то поддерживаются (но в основном теми же людьми, которые их и строили - они же не испарятся куда то?), но новые разворачиваются очень мало.
То есть дело не в том, что ты не можешь создать/поддерживать проект, а в том, что никому не нужны проекты.
На это конечно накладывается проблема курсов и инертности - был недостаток персонала и высокий спрос, курсы как то пытались решить это.
Спрос ушел, курсы остались.
Логично
Мы все же говорили про общее программирование, но крупные решения типа поиска могут работать и на специализированном
Да, ну и сам концепт организации в процедуры / функции, как и функциональное программирование как бы являются инструментами и составными частями императивного программирования.
Возможно стоит упомянуть и ООП в смысле Алана Кэя - что это подход к организации программы через создание обособленных объектов (включающих как данные так и их обработку) и отправку сообщений между ними.
Такой подход решает несколько задач - организация и декомпозиция кода, хороший контроль состояния (путем разбиения сложного состояния на иерархии простых) и хороший контроль операций и входных данных (потому что объект решает как обрабатывать сообщения применительно к своим данным)
В этом смысле агенто-ориентированное программирование (Которое акторное) или, например, микросервисы - это хрестоматийное следование идеям ООП на разных уровнях.
Еще можно упомянуть связи между подходами - почти все современные ЯП используют императивное и структурное программирование как базу, имеют инструменты для метапрограммирования, опираются на системы типов разной мощности.
Часть подходов являются подразделами друг друга - например data-flow подход это в каком то смысле простая идея, что "процесс - это тоже объект"
А вообще спасибо, хорошая обзорная статья
Есть еще важный фактор, который не отражен в чистой O нотации - длина единичной операции.
O(1) может быть настолько дорогим для каждого элемента, что его победит перебор по массиву O(n)
Хэш таблицы используют, ну, хэши (которые может требоваться вычислять) и таблицы (в смысле сложную внутреннюю организацию с чанками), в то время как последовательный перебор массива очень прост и хорошо дружит с кешем.
В итоге простыми экспериментами можно найти, до какого количества элементов выгоднее использовать массивы, и это может быть на удивление большое число.
Почти для всех приведенных пунктов есть одна важная забытая деталь - границы применимости.
Они вечно теряются.
А меж тем практически каждый пункт перестает работать при чрезмерном использовании либо наоборот - стоит слишком дорого в случаях, где использование недостаточно.
Комплексные архитектуры избыточны для простого приложения от одного разработчика, а в сложном проекте нельзя сделать просто. Декомпозиция важна, чрезмерная декомпозиция делает код нечитаемым. Комментарии действительно могут устаревать и путать быстрее кода и частично замещаются хорошим неймингом, но API и сложные места/оптимизации требуют комментариев. И так далее.
Поэтому и важны нюансы, и ответы не только на вопрос "как", но и "почему".
Ну помимо ручной модерации еще есть и фильтры, системы оценок и прочие методы.
Просто цели разные.
Поэтому мобильные сторы завалены фигней и не видно ничего, а, к примеру, стим, таки показывает сверху годноту и прячет инди мусор, которого достаточно (его можно увидеть, если листать любую категорию достаточно долго)
Но да, это проблема и фильтров.
Но это, тем не менее, не мешает называть слоп слопом. Я как бы не виню разработчиков инди игр, им нужно учиться, но мусором это быть не перестает.