Обновить
16K+
49
Alex Gusev@flancer

Я кодирую, потому что я кодирую…

3,1
Рейтинг
99
Подписчики
Отправить сообщение

Начало: Аналитический центр США призвал задействовать спецслужбы и сообщество Open Source для оценки уровня защиты Astra Linux

Конец: Благодаря сотрудничеству разработчиков этого проекта с «Роскосмосом», в новой версии Astra Linux появилась звуковая тема «Звёздный минимализм», в основу которой использованы «голоса» настоящих космических объектов.

А про что статья?

Дайте, пожалуйста, чёткое определение. Я просто не смог его найти и взял первое попавшееся, а оно оказалось нечётким :(

Я смотрю, по ссылкам вы не ходите :(

https://habr.com/ru/articles/834956/
https://habr.com/ru/articles/834956/

А какая разница между "уверен" и "кажется"?

Хорошо, я с вами тоже соглашусь - LLM замечательно моделирует ошибки человеческого интеллекта.

Согласен, с поправкой, что под ИИ вы подразумеваете LLM. Да, LLM - это вероятностный инструмент, и не нужно требовать от него точных ответов.

Вот, в моей Вселенной интеллект - это калькулятор. Калькулятор может считать вероятности, но в основе своей он детерминирован.

У меня интеллект разделят информацию на определённую и неопределённую. С определённой он работает по одним правилам, с неопределённой - по другим. И я вижу, что LLM неплохо работает со вторым типом информации и нехорошо - с первым.

Наш биологический интеллект может деградировать, не вопрос. Альцгеймер и иже с ним. Но мы же говорим за модель здорового интеллекта, разве нет? Я вполне могу согласиться, что LLM - это удачная модель деградировавшего интеллекта, но до здорового ему ещё расти и расти. И, скорее всего, не на этой архитектуре.

Топор можно заточить, но он так и останется тупым в интеллектуальном плане. IMHO, нужно понимать границы применимости и топора, и LLM. Но LLM гораздо более сложный инструмент, чем топор, поэтому гораздо сложнее очертить границы, где LLM становится бесползеным, а то и вредным.

И мне нравится ваша ассоциация LLM с топором. Количество интеллекта в обоих инструментах примерно одинаковое.

Не неправоту, а некомпетентность :) Вы ж например, не сядите за штурвал самолёта, если не имеете соответствующих навыков?

Ну вот в ж со своим ествественным интеллектом распознали суть вопроса и дали верный ответ - "не было там брючного костюма"! А вероятностная модель ищет связи и, самое главное, их находит.

Может быть он наконец-то просто понял, что вы от него добиваетесь и был рад вам угодить?

Опричники Ивана Грозного могли у любого любые показания добыть. Те еще промпт-инженеры были!

Для интереса выкрутил температуру в ноль, взял промпт "if you don't know the answer or are unsure, please respond with "I don't know"" и запрос "In the 2002 film The Transporter, Frank Martin carried a Chinese girl in the trunk of his car. What color pantsuit was the girl wearing?":

  • 3.5-turbo: I don't know

  • ChatGPT 4-turbo: In the 2002 film "The Transporter," the Chinese girl, Lai, who is carried in the trunk of Frank Martin's car, is wearing a pink pantsuit.

  • ChatGPT 4o: I don't know.

  • ChatGPT 4: I'm sorry, but I don't have the specific information about the color of the pantsuit the girl was wearing in the 2002 film The Transporter.

Стало гораздо лучше, не справился только 4-turbo. Подозреваю, что так это больше похоже на компьютерную программу (один и тот же ответ на один и тот же вопрос из-за обнуления температуры), но по сути LLM - это ведь она и есть, компьютерная программа. Было бы странно, если загнать Британскую Энциклопедию в компьютер, и он бы выдавал разные ответы на один и тот же вопрос: в каких годах правил российский император Александр II?

Мне кажется, что для использования в качестве инструмента (помощь в программировании, например, или поиска данных/фактов) температуру точно нужно выкручивать в ноль. А для творческого поиска - слегка приподнимать.

В общем, спасибо за коммент, коллега. Я улучшил своё понимание границ применимости LLM.

Считайте, что я говорил за "intellect".

Мы с вами по разному понимаем интеллект. В моих школьных учебниках по математике и физике в конце книг были ответы - по одному на каждую задачу. В качестве решения учитель принимал только один ответ. И этот должен был совпасть с ответом в конце книги, тогда задача считалась решённой верно. Не среднее арифметическое, а один единственный ответ. Если ученик давал несколько ответов, то звучало что-то типа "ты мне тут не угадывай!".

В моей Вселенной интеллект не может быть вероятностным. "Если я вчера бухал с друзьями до поздней ночи, то сегодня мне не стоит садиться за руль с самого утра." Можно на это высказывание накладывать различные дополнительные условия ("вопрос жизни и смерти"), но сам факт "бухал с друзьями" от этого никуда не денется. Он не превратится в "играл в карты", "смотрел фильмы" или "читал стихи".

То, что делают LLM - это big data, а не интеллект. Предобученная модель - статика, результат статического анализа огромного объёма данных. Правила перекладывания иероглифов в китайской комнате. А интеллект - это, в том числе, и учёт границ применимости фактов и осознание выхода за эти границы. Ничего плохого, если ты чего-то не знаешь, это нормально. Хуже, когда ты не можешь признаться в этом даже самому себе. Вот тут и начинаются галлюцинации.

И это, на фото видно, что девушка не в брючном костюме. В моей школе на ответ "Костюм девушки-китаянки был серого цвета" мне бы сказали, что я не понял сути вопроса.

  • 3.5-turbo: Брючный костюм был красного цвета.

  • ChatGPT 4-turbo: Брючный костюм девушки-китаянки в фильме "Перевозчик" был розового цвета.

  • ChatGPT 4o: Белого.

  • ChatGPT 4: Костюм, который был на девушке-китаянке в фильме "Перевозчик" 2002 года, был золотого цвета.

Только "4о" на стал(а) менять показания, остальные подтвердили свою репутацию вероятностных сущностей.

Я как-то писал статью про использование биомерии - https://habr.com/ru/articles/740000/ С iOS не помню особых проблем.

Интерфейсы - это "внеязыковое" понятие. Это способ мышления при конструировании ПО. Вы можете создавать код на любом языке. Можете на TS, можете на JS, на Go, Java, python, Rust, ... Можете использовать при этом интерфейсы, а можете и не использовать. Этот велосипед для тех, кто пишет код на JS и хочет использовать интерфейсы.

Вы просто "вошли не в ту дверь" и поняли это ближе к концу статьи. Только этим я могу объяснить обиженный тон вашего коммента, коллега ;)

Извините, а Вы браузером на своём мобильном устройстве пользуетесь?

Устраивается секретарша на работу, директор спрашивает:

  • Какая у вас скорость печати?

  • 1000 знаков в минуту!

  • Так много???

  • Правда такая ерунда получается...

Где я могу увидеть этот ваш код на C#?

"Инверсия контроля на голом TypeScript без боли" vs. "Формат описания идентификатора зависимости в JS DI"

(TS != JS) && (DI != AmbientContext) 

Если вы этого не понимаете, то я не смогу вам ответить на вопрос "зачем" :(

Но мне кажется, что от DI скорее ждут того, чтобы клиент получал уже готовую зависимость. То, как ее можно создавать - фабрикой или конструктором, например - могла бы сообщать контейнеру сама зависимость.

Так и есть. В es6-модуле экспортом может быть что угодно, включая класс и фабричную функцию. Будет ли этот экспорт внедрён as-is или будет внедрён результат выполнения фабричной функции (конструктора класса) - зависит от контейнера. Который конфигурируется при помощи идентификаторов зависимости в месте внедрения зависимости (могла бы сообщать контейнеру сама зависимость). Так в одном случае один и тот же экспорт должен внедряться as-is, в другом - как синглтон, в третьем - как инстанс (можно даже в пределах одного конструктора):

export default class Service {
    constructor(
        {
            'Ns_Module.export': asIs,
            'Ns_Module.export$': asSingleton,
            'Ns_Module.export$$': asInstance,
        }
    ) {}
}

Тут можно говорить ещё об одном контуре IoC - когда конфигурация контейнера идёт не через сам контейнер, а через клиентов, которые он обслуживает.

Более того, насколько вижу, у вас структура этих идентификаторов получается привязанной к пути к файлу с реализацией зависимости - а как при этом зависеть от интерфейса, а не конкретной реализации?

Вы правы, идентификатор привязывается к пути в исходнику, если исходник существует. Но в моей реализации контейнера после этапа разбора идентификатора (например, Fl32_Auth_Back_Api_Mod_User) идёт этап пред-обработки, где Контейнер может заменить в структуре идентификатора любую из его частей или все сразу:

Если в настройках Контейнера на уровне соответствующего приложения прописать, что такой-то интерфейс должен заменяться такой-то имплементацией, то в таком-то приложении будет использоваться соответствующая имплементация вместо интерфейса.

В саму библиотеку этот функционал не входит. На её уровне реализованы только возможности подключения цепочек препроцессоров и постпроцессоров, а правила пред- и пост-обработки уже закладываются отдельно, в зависимости от приложения и его процессоров.

В итоге, ваши примеры кажутся полностью идентичными просто обычным импортам, без каких-либо преимуществ.

Без пред- и пост-обработки так бы и было. Но теперь связывание выполняется в runtime, а не в коде, и правила связывания могут динамически меняться в зависимости от приложения (подключенных к Контейнеру процессоров). Например, плагин аутентификации, работающий на своём уровне с интерфейсом Fl32_Auth_Back_Api_Mod_User, в одном приложении получит одну модель пользователя, а в другом - другую. В задачи плагина аутентификации входит связывание этой модели с контекстом HTTP-запроса и его не интересует, что там за модель. Как Стетхем в "Перевозчике" - "Никогда не открывать посылку". Плагин в одном месте запрашивает у приложения модель пользователя, а в другом - предоставляет приложению возможность эту модель забрать. И один и тот же плагин может работать без изменений в разных приложениях, если они придерживаются контракта (имплементируют интерфейс).

Информация

В рейтинге
1 300-й
Откуда
Рига, Латвия, Латвия
Дата рождения
Зарегистрирован
Активность

Специализация

Фулстек разработчик
Ведущий
От 3 000 €
JavaScript
HTML
CSS
Node.js
Vue.js
Веб-разработка
Progressive Web Apps
PostgreSQL
MySQL
GitHub