То, что Вы пишете - упрощение секты свидетелей координатной плоскости. Оно не расширяется даже на кватернионы.
А чему равно само это число i ? Его можно вычислить в лоб по теореме Пифагора - и да, получится корень из -1.
Нет, Вы не можете её вычислить по ТП, потому что ТП дана в квадратах длин отрезков и суммах. И никакой минус там появиться не может - не откуда. При этом квадрат отлично поднимает прямую в плоскость безо всяких мнимых, просто позиционными элементами уравнения.
При этом, с точки зрения ТП, нам без разницы, какую ось мы возьмём в какую позицию. А когда мы вводим i - возникает разница. Поэтому i - не просто рюшечка на ТП, а добавляет новое качество. Так вот:
Минус в ТП появится только если вы введёте в рассмотрение "направление" и будете считать не на отрезках, а на векторах.
И, вроде, статья и начинается с тезиса о том, что i вводит направление.
Да и по формуле Эйлера - там угол, т.е., тоже направление, а не что-то ещё.
Т.е., не очень понятно, что Вас так возмутило в исходной посылке сюжета?
А дальше, уж простите, если мы сказали "направление", то давайте рассмотрим, что это за зверь такой и какие свойства добавляет. Возможно, Вас устроит принять, что "это ещё одно число", меня не устроило. Вся математика держится на том, что "просто ещё число" не должно требовать никаких танцев с бубном.
"Не существует" - не получится. Время, как явление останется, изменится Ваш взгляд на него. В [2] и [3] раскрывается концепция "процесса", как новой метрической единицы, связанной со временем. И да, она даёт другой взгляд, в котором "время как бы замирает, не переставая при том развёртываться".
В частности (адресуяс к Вашему следующему комментарию), нельзя сказать, что фотон находится вне времени. У него есть моменты эмисссии и поглощения, которые не одновременны, значит есть и жизненный цикл.
"У лопаты сломался черенок" = "у вектора пропала начальная точка, осталась стрелка". Как будете "чинить" вектор? Думаю, что точно так же.
Но вот Вы же не против того, чтобы видеть, что у лопаты есть черенок и штык, однако вопрос "что делает вектор вектором" вызвал затруднение.
Вы МОЖЕТЕ рассматривать яму, как место, где что-то происходит. Я МОГУ рассматривать яму как неотъемлемую часть происходящего. Это действительно, просто разные стороны одного и того же. Но разные стороны дают возможность разных рассуждений: например, место может дробиться только на более мелкие места, а происходящее дробится только на более мелкое происходящее. А польза от нового ракурса в том, что "происходящее" - т.е., "процесс" имеет свои законы (там появляется жизненный цикл и ещё много интересного), что делает выгодным смотреть на яму ЕЩË и с этой стороны.
Т.е., нет смысла доказывать, что яма - это не процесс, или заявлять о том, что яма - это только место и ничего более. Это просто разные ракурсы, которые облегчают доступ к разной логике.
Окей, судя по прилетевшему вместо ответа минусу, так оказалось не понятно. Ну, тоже средство коммуникации, чо. Давайте с другой стороны.
Вот смотрите: лопату лопатой делает соединение черенка и штыка. Если нет одного из них, копать будет неудобно.
Но вы не видите "черенка" и "штыка", а говорите "лопата - это то, чем я могу выкопать траншею от Москвы до Питера". Вы не говорите про вектор, вы говорите про земляные работы векторную алгебру и не различаете инструмента от деятельности с его помощью. Для Вас лопата - это то, чем научили махать на стройке, а вектор - это то, что научили рисовать в тетрадке. Так, конечно, можно, воля Ваша, но чтобы бравировать этим...
Аналогично и про процессы. Вот упали вы в канаву и пошли по ней до места, где можно выбраться. Это, типа действие. Но потом кто-то ещё упал и тоже пошёл и выбрался, а потом - кто-то ещё. А канава - одна и та же. А условие такое, что в ней не везде можно выбраться, а только в конечной точке - типа, тот же вектор. И вот в таком ракурсе мы уже можем рассматривать канаву как процесс: канава одна, а люди всё время бегают.
Можем, конечно, рассматривать и не как процесс, а как просто канаву. Это, опять же, личный выбор. Но понимание про процесс позволяет брать деньги за выход с тех, кто не понимает, потому что даёт предсказание, что кто-то ещё прибежит и рождает идею потока.
Это тот способ мышления, которым базарная площадь превращается в маркетплейс. Более сложная модель мышления, так сказать.
Так эта... тут же видно, что квадрат кватерниона - это тоже кватернион. Т.е., мы не повышаем и не понижаем сложность, а остаёмся в континууме.
При этом у нас вычеты по всем параметрам. Грубо говоря, по количеству мы часть теряем на вероятности, часть - на снижении энтропии (тождественности некоторых состояний в выборке), часть - на сокращении числа допустимых перестановок.
И по каждому из параметров мы тоже теряем.
Ну, либо приобретаем, если там развес коэффициентов неравномерный и мы скатываемся в сторону какой-то вырожденной ситуации.
Примечательно, что масштаб каждой компоненты будет пересчитан из других с обязательной опорой на себя и на энергию (число натуральных элементов) $a$.
Т.е., например, запас времени будет оцениваться, как $2(ab - cd)$: "число касаний" (это число элементов x число флуктуаций), минус информационную ёмкость (число фаз x число степеней свободы, т.е., сколько у нас будет синхронных касаний за одну флуктуацию).
$2(ac - bd)$ - это вариативность системы (число элементов х число фаз) минус общее число перестановок (число флуктуаций х число степеней свободы).
$2(ad-bc)$ - это число перемещений за одну флуктуацию (число элементов x число степеней свободы) минус количество мутаций (число флуктуаций х число фаз).
Конечно, я примерно это обзываю и очень на скорую руку, но общий принцип должен быть ясен.
Если x - это позиция, а у - направление, то (x,y) будет записываться как yi+xk. Ориентированное (ориентирующее?) пространство. Это что-то вроде поля, а не "ерунда" :) Точнее можно сказать, если все сочетания рассортировать. Квадраты отдельных элементов рассмотрены в тексте, там тоже ничего собо неожиданного, или нарушающего.
Можно и "станет". Позиция наблюдателя может стоять в начале, на конце (или за ним) и "вовне" наблюдаемого процесса. Это даёт немного разный угол обзора, но про одно и то же. Про перенос: тезис о том, что элементарен факт самого переноса, не важно куда. И мы его видим как флуктуацию.
Проблема ООП не в ООП, а в том, что 99% тех, кто сегодня использует ООП-фреймворки, вообще не владеет методами ООП и не понимает за декомпозицию. Они просто знают, что "есть функции, при оформлении которых нужно первым параметром писать self/this, а обращаться к ним через точку после переменной".
Ещё лет 15 назад с пониманием было получше. Но не от того, что люди были умнее, а от того, что фреймворков было меньше и они требовали больше понимания от программиста. Накопипастить вообще не включая голову было затруднительно.
В целом, сегодня именно ООП достигло той радостной черты, когда чтобы с его помощью сделать что-то полезное, можно его вообще не знать. Главное не делать из этого полезного библиотеку, но кого ж остановишь?
Существуют разные классы задач. Причём, не просто разные, а разные по степени сложности. У меня в блоге висит есдинственная статья, там, как раз об этом. Соответственно, чистый ФП, вроде ЛИСПа, относится к первому уровню сложности, ООП - к третьему. Если вам в языке приходится сочинять "шаблоны на шаблоны", или изобретать 25 видов полиморфизма - это верный признак того, что выбранный инструмент не соответствует предметной области. Хотя, есть ещё вариант, что кто-то, не понимающий ООП всё-таки создал мега-популярную библиотеку и теперь приходится его творчество компенсировать технологическим костылём.
Например, если Вы попытаетесь сделать Vue.js на ФП, то число сущностей и суперструктур, которые придётся при этом ввести, превысит все разумные пределы. В конечном итоге, вы переизобретёте ООП, только на функциональном слэнге. И это будет больно. И у вас будет целых 3 почитателя. Потому что когда вы манипулируете объектами - вам нужен ООП. А подход ФП предназначен, в первую очередь, для манипулирования состояниями.
Ну так теория категорий - и есть попытка подобраться к метафизике через задний проход математики. Т.е., решается задача: как бы нам, не отказываясь от аппарата математики (т.е., аппарата вычисления значений), создать метаматематику, т.е., аппарат вычисления операций.
Идея красивая - это создало бы язык, способный описывать себя.
Только там во второй же строчке ошибка, определяемая именно границами математики (точнее - две: бинарность морфизмов и требование существования отображения), потому - без шансов.
P.S. Но если Вы действительно шарите в теории категорий, я бы пару вопросов задал...
"Более просто" - это Вы, должно быть шутите. Математика уже лет 250-300, как перестала быть чем-то простым.
Современная метафизика имеет довольно простую основу - не сложнее арифметики. Там, как раз, проблема наоборот, в том, что она была задвинута математикой в пыльный угол и не получила пока своего развития в сложность.
2) Языка для описания ситуаций, готового как отразить результаты диагностики, так и передать эти результаты клиенту.
Собственно, сомнению можно подвергать только методы диагностики. Необхоимость же описательного аппарата для класса задач, касающихся "ситуаций" очевидна. И именно гадательные практики дают варианты таких описаний, гораздо более практичные для отражения сути происходящего и его анализа, чем тот же BPM.
Про критерии опровержимости можно модель саму и спросить, загрузив в неё обратно эту портянку. Собственно, можно точно так же, загрузив портянку, спросить и выжимку по ней - если Вам читать долго, или что-то найти хотите. Модель для этого и предназначена и не надломится. Собственно, для этого портянка и нужна в таких статьях - это "исходник", чтобы каждый мог поиграть (не знаю, осознанно ли это сделал автор, но сделал верно!). Просто культура использования ИИ ещё не очень развита и эти возможности не так очевидны, как, например, перемножение при помощи калькулятора.
Однако, для оценки идеи (а представлена именно она) опровержимость не принципиальна - идея оценивается здравым смыслом и интуицией, а формального доказательства требует только, когда превращается в теорию.
Но Ваш комментарий затрагивает более глубокую проблему. Дело в том, что в среде математических догматиков есть две стыдных правды. И обе они относятся именно к теме опровержимости.
Непонимание того, что опровержимость имеет границы применения. Например, если вы докажете, что 2 х 2 != 4, или сможете нарушить коммутативный закон, то сломаете арифметику. Однако, это опровержение даётся в рамках "математической песочницы", строго её аппаратом и строго в границах тезиса о том, что всё на свете выразимо скалярными величинами посредством операторов преобразования. И за эти рамки с требованием опровержимости выходить не следует.
Если же мы переходим в область метафизики (а представленный текст - это она), то у нас меняется понятие исчисляемого элемента. Грубо говоря, если в математике у нас операторы - это действия преобразования, а исчисляемое - количество, то в метафизике исчисляемым становятся качество (характеристика процесса состоящего из однотипных действий преобразования), а операторами становятся разные грани их соответствия. И вот тут у нас вопрос о фальсифицируемости разделяется на два разных:
Вопрос о фальсифицируемости тезисов метафизических теорий в рамках "метафизической песочницы". Например, существует тезис (не из этой статьи, из Науки складности), что "любой корректный аналитический срез ситуации даёт ровно четыре взаимоисключающих процесса, его составляющих и в нём возможных". Далее этот тезис можно как доказывать, так и фальсифицировать в рамках инструментария метафизики.
Вопрос о фальсифицируемости самой математики: а действительно ли у нас "вообще всё" выразимо её аппаратом? И если Вы, вдруг, решите отказать метафизике в праве на существование, то начните с приведения критерия фальсифицируемости самой математики - её права быть единственной "песочницей исчисления". Хотя бы задумайтесь об этой задаче.
И вот стыдная правда в том, что математики второго вопроса обсуждать не просто не готовы, они (по крайней мере те, кто действительно собой что-то представляет) прекрасно чувствуют его существование и... старательно обходят, накладывая, по сути, прямой запрет на академическое обсуждение метафизики. Такое вот поборничество Истины...
P.S. Автору: да, интересно, спасибо. Портянку к себе утащил, погоняю.
А что вы всё-таки тестировали? Точность поиска опорных документов в RAG, т.е. эмбеддинги, или точность обработки найденных опорных документов для выдачи ответа?
Есть такая инструкция от художников: "как нарисовать сову". Она очень простая: 1. Рисуете овал 2. На нём рисуете ещё один овал. 3. Превращаете это в сову.
Тут очень похоже: "а затем мы берём вот такую схему и делаем по ней многоголовое внимание". А если хотите, то читайте AIAYN, в котором вообще всё кристально ясно.
P.S. Ну и про эмбеддинги - тоже сова.
Потому что если эту магию оставить, то, в остальном, достаточно сказать, что это многослойная байесова сеть, которая по отрезку из символов генерит следующий символ и это итеративно замыкается.
На самом деле, чего нигде не видел - так это как раз описания базовой статьи вот таким простым языком, как Вы начали.
А зачем нужен реранк в прведённом случае? Ведь, поиск, с одной стороны, вернёт score, которые считаются как мера близости к вектору вопроса. А с другой - если мы выбираем 3-5 чанков, то отвечающая ЛЛМ сама разберётся, что ей релевантно, а что нет - можно вместе с мусором прогрузить.
Реранкер, наверное, более интересен, если, например, грепнули сайтик, или длинный документ и чтобы из него ради разового запроса не строить вектора и потом в них не искать, а сразу получить сортировку.
Бирюзовые организации хороши при сочетании двух факторов:
1) Когда сотрудники подбираются только такие, которые понимают ценность бирюзовых отношений. Таких в России полно, но тут есть нюанс: кто-то должен недрогнувшей рукой выгонять инотипных. А это сложно, вдобавок, ещё потому что бирюзовый психотип слишком совестью мучается.
2) Когда бизнес находится в области турбулентности, правила и ходы в которой неизвестны. Либо это новый бизнес, либо новая область, либо на улице очередной кризис и старые правила не работают, а новые ещё не устоялись. Т.е., когда неизвестно, кто в реальности окажется прав.
Вот в этой ситуации красные вчистую проиграют тем, кто сможет собрать бирюзовый процесс.
С другой стороны, красные выигрывают, когда есть админресурс и есть люди однозначно более важные для компании, а есть менее важные. И это, обычно, времена, когда бизнес делают знакомства и правильные контракты, а не изобретательность, или, к примеру, оранжевая эффективность производства. И это для России не меньшая константа, чем статистическое преобладание бирюзово-ориентированных граждан.
Поэтому на таких качелях и живём и, действительно, это особенность территории.
В общем, всё имеет своё место, время, форму и предназначение, а мода - это от лукавого.
Бывает, что и к красному гиганту полезно пристроить бирюзовый анклавчик для иновационного поиска. Потратят они сильно меньше, чем красные в сумме теряют на управленческом долбоклюйстве формализме, а что-то интересное, может быть, и сколхозят. А может - и нет :) Но, к сожалению, это фантазийный совет, поскольку красные не смогут удержаться, чтобы не развалить бирюзовое дело при первых же признаках полезного выхода от него.
В этой секте есть свои акронимические принципы. Например, SOLID (случайно придумалось, можете забирать, если глянется)
Separated - разделённый Разделяйте всё: декларацию от имплементации, интерфейс от логики, хранение от вычисления и т.д. Код, написанный таким образом, выглядит более профессионально.
Occult - мистический После того, как вы всё разделили, необходимо это связать. Передайте небольшие части деклараций в имплементацию, хранилище создайте в интерфейсе и т.д. Все части, разделённые на предыдущем шаге должны хранить частичку друг друга. Это обеспечит самосохраение вашего целостного замысла при попытках рефакторинга всякими неумехами и не даст его сломать.
Теперь вам должен стать понятен истинный смысл первого шага: кто плохо разделяет, тому потом нечего связывать.
Levelled - уровневый Для любой задачи создавайте уровни абстракции. Задумайтесь, какую общую проблему решает этот цикл, или интерфейс? Например, если вам нужно хранить конфигурацию, то необходимо понимать, что это достаточно общая задача и их удобно держать в человекочитаемом формате. Например, yaml. Создайте вначале абстракцию конфига, затем абстракцию чтерия из него в словарь. Но, поскольку в программе удобнее обращаться к переменным, не лишней будет ещё абстракция перевода значений в имена переменных модуля настроек. Но лучше - в переменные объекта, чтобы можно было иметь несколько независимых инстансов, если понадобится. Теперь добавьте немножко оккультизма: будет хорошо, если эти имена будут вычисляться, чтобы соответствие значений конфига и переменных модуля нигде в коде не встречалось. Только так можно получить подлинную абстракцию.
Intelligent - интеллектуальный Используйте самые передовые алгоритмические техники, которыми владеете. Это сокращает линейный код на 10%.
Descriptive - наглядно описательный Все переменные должны быть названы в терминах ваших абстракций. Тот, кто будет читать ваш код, должен иметь возможность погрузиться в ход ваших рассуждений, чтобы начать в нём ориентироваться. Лучше, конечно, если он начнёт знакомство именно с чтения всех абстракций и правильные имена позволяют это сделать.
Вспомнилось... есть (был) такой язык perl - там если писать плейн-код правильно, то очень скучно и лучше вообще какойньть другой язык взять. А если писать так, как он задуман, то весело, но потом ничего не понятно. Было весело, конечно... :)
То, что Вы пишете - упрощение секты свидетелей координатной плоскости. Оно не расширяется даже на кватернионы.
Нет, Вы не можете её вычислить по ТП, потому что ТП дана в квадратах длин отрезков и суммах. И никакой минус там появиться не может - не откуда. При этом квадрат отлично поднимает прямую в плоскость безо всяких мнимых, просто позиционными элементами уравнения.
При этом, с точки зрения ТП, нам без разницы, какую ось мы возьмём в какую позицию. А когда мы вводим i - возникает разница. Поэтому i - не просто рюшечка на ТП, а добавляет новое качество. Так вот:
Минус в ТП появится только если вы введёте в рассмотрение "направление" и будете считать не на отрезках, а на векторах.
И, вроде, статья и начинается с тезиса о том, что i вводит направление.
Да и по формуле Эйлера - там угол, т.е., тоже направление, а не что-то ещё.
Т.е., не очень понятно, что Вас так возмутило в исходной посылке сюжета?
А дальше, уж простите, если мы сказали "направление", то давайте рассмотрим, что это за зверь такой и какие свойства добавляет. Возможно, Вас устроит принять, что "это ещё одно число", меня не устроило. Вся математика держится на том, что "просто ещё число" не должно требовать никаких танцев с бубном.
"Не существует" - не получится. Время, как явление останется, изменится Ваш взгляд на него. В [2] и [3] раскрывается концепция "процесса", как новой метрической единицы, связанной со временем. И да, она даёт другой взгляд, в котором "время как бы замирает, не переставая при том развёртываться".
В частности (адресуяс к Вашему следующему комментарию), нельзя сказать, что фотон находится вне времени. У него есть моменты эмисссии и поглощения, которые не одновременны, значит есть и жизненный цикл.
"У лопаты сломался черенок" = "у вектора пропала начальная точка, осталась стрелка". Как будете "чинить" вектор? Думаю, что точно так же.
Но вот Вы же не против того, чтобы видеть, что у лопаты есть черенок и штык, однако вопрос "что делает вектор вектором" вызвал затруднение.
Вы МОЖЕТЕ рассматривать яму, как место, где что-то происходит. Я МОГУ рассматривать яму как неотъемлемую часть происходящего. Это действительно, просто разные стороны одного и того же. Но разные стороны дают возможность разных рассуждений: например, место может дробиться только на более мелкие места, а происходящее дробится только на более мелкое происходящее. А польза от нового ракурса в том, что "происходящее" - т.е., "процесс" имеет свои законы (там появляется жизненный цикл и ещё много интересного), что делает выгодным смотреть на яму ЕЩË и с этой стороны.
Т.е., нет смысла доказывать, что яма - это не процесс, или заявлять о том, что яма - это только место и ничего более. Это просто разные ракурсы, которые облегчают доступ к разной логике.
Окей, судя по прилетевшему вместо ответа минусу, так оказалось не понятно. Ну, тоже средство коммуникации, чо. Давайте с другой стороны.
Вот смотрите: лопату лопатой делает соединение черенка и штыка. Если нет одного из них, копать будет неудобно.
Но вы не видите "черенка" и "штыка", а говорите "лопата - это то, чем я могу выкопать траншею от Москвы до Питера". Вы не говорите про вектор, вы говорите про
земляные работывекторную алгебру и не различаете инструмента от деятельности с его помощью. Для Вас лопата - это то, чем научили махать на стройке, а вектор - это то, что научили рисовать в тетрадке. Так, конечно, можно, воля Ваша, но чтобы бравировать этим...Аналогично и про процессы. Вот упали вы в канаву и пошли по ней до места, где можно выбраться. Это, типа действие. Но потом кто-то ещё упал и тоже пошёл и выбрался, а потом - кто-то ещё. А канава - одна и та же. А условие такое, что в ней не везде можно выбраться, а только в конечной точке - типа, тот же вектор. И вот в таком ракурсе мы уже можем рассматривать канаву как процесс: канава одна, а люди всё время бегают.
Можем, конечно, рассматривать и не как процесс, а как просто канаву. Это, опять же, личный выбор. Но понимание про процесс позволяет брать деньги за выход с тех, кто не понимает, потому что даёт предсказание, что кто-то ещё прибежит и рождает идею потока.
Это тот способ мышления, которым базарная площадь превращается в маркетплейс. Более сложная модель мышления, так сказать.
Я и читаю иногда, только по психологии социального поведения. Что характерно - на том же базисе, что и эта статья :)
Вот Вы говорите "вектор". А что делает вектор вектором?
$q^2 = a^2 - b^2 - c^2 - d^2 + (2ab - 2cd)i + (2ac - 2bd)j + (2ad + 2bc)k$
Так эта... тут же видно, что квадрат кватерниона - это тоже кватернион. Т.е., мы не повышаем и не понижаем сложность, а остаёмся в континууме.
При этом у нас вычеты по всем параметрам. Грубо говоря, по количеству мы часть теряем на вероятности, часть - на снижении энтропии (тождественности некоторых состояний в выборке), часть - на сокращении числа допустимых перестановок.
И по каждому из параметров мы тоже теряем.
Ну, либо приобретаем, если там развес коэффициентов неравномерный и мы скатываемся в сторону какой-то вырожденной ситуации.
Примечательно, что масштаб каждой компоненты будет пересчитан из других с обязательной опорой на себя и на энергию (число натуральных элементов) $a$.
Т.е., например, запас времени
будет оцениваться, как $2(ab - cd)$: "число касаний" (это число элементов x число флуктуаций), минус информационную ёмкость (число фаз x число степеней свободы, т.е., сколько у нас будет синхронных касаний за одну флуктуацию).
$2(ac - bd)$ - это вариативность системы (число элементов х число фаз) минус общее число перестановок (число флуктуаций х число степеней свободы).
$2(ad-bc)$ - это число перемещений за одну флуктуацию (число элементов x число степеней свободы) минус количество мутаций (число флуктуаций х число фаз).
Конечно, я примерно это обзываю и очень на скорую руку, но общий принцип должен быть ясен.
Если x - это позиция, а у - направление, то (x,y) будет записываться как yi+xk. Ориентированное (ориентирующее?) пространство. Это что-то вроде поля, а не "ерунда" :) Точнее можно сказать, если все сочетания рассортировать. Квадраты отдельных элементов рассмотрены в тексте, там тоже ничего собо неожиданного, или нарушающего.
Можно и "станет". Позиция наблюдателя может стоять в начале, на конце (или за ним) и "вовне" наблюдаемого процесса. Это даёт немного разный угол обзора, но про одно и то же. Про перенос: тезис о том, что элементарен факт самого переноса, не важно куда. И мы его видим как флуктуацию.
Проблема ООП не в ООП, а в том, что 99% тех, кто сегодня использует ООП-фреймворки, вообще не владеет методами ООП и не понимает за декомпозицию. Они просто знают, что "есть функции, при оформлении которых нужно первым параметром писать self/this, а обращаться к ним через точку после переменной".
Ещё лет 15 назад с пониманием было получше. Но не от того, что люди были умнее, а от того, что фреймворков было меньше и они требовали больше понимания от программиста. Накопипастить вообще не включая голову было затруднительно.
В целом, сегодня именно ООП достигло той радостной черты, когда чтобы с его помощью сделать что-то полезное, можно его вообще не знать. Главное не делать из этого полезного библиотеку, но кого ж остановишь?
Существуют разные классы задач. Причём, не просто разные, а разные по степени сложности. У меня в блоге висит есдинственная статья, там, как раз об этом. Соответственно, чистый ФП, вроде ЛИСПа, относится к первому уровню сложности, ООП - к третьему. Если вам в языке приходится сочинять "шаблоны на шаблоны", или изобретать 25 видов полиморфизма - это верный признак того, что выбранный инструмент не соответствует предметной области. Хотя, есть ещё вариант, что кто-то, не понимающий ООП всё-таки создал мега-популярную библиотеку и теперь приходится его творчество компенсировать технологическим костылём.
Например, если Вы попытаетесь сделать Vue.js на ФП, то число сущностей и суперструктур, которые придётся при этом ввести, превысит все разумные пределы. В конечном итоге, вы переизобретёте ООП, только на функциональном слэнге. И это будет больно. И у вас будет целых 3 почитателя. Потому что когда вы манипулируете объектами - вам нужен ООП. А подход ФП предназначен, в первую очередь, для манипулирования состояниями.
Ну так теория категорий - и есть попытка подобраться к метафизике через задний проход математики. Т.е., решается задача: как бы нам, не отказываясь от аппарата математики (т.е., аппарата вычисления значений), создать метаматематику, т.е., аппарат вычисления операций.
Идея красивая - это создало бы язык, способный описывать себя.
Только там во второй же строчке ошибка, определяемая именно границами математики (точнее - две: бинарность морфизмов и требование существования отображения), потому - без шансов.
P.S. Но если Вы действительно шарите в теории категорий, я бы пару вопросов задал...
"Более просто" - это Вы, должно быть шутите. Математика уже лет 250-300, как перестала быть чем-то простым.
Современная метафизика имеет довольно простую основу - не сложнее арифметики. Там, как раз, проблема наоборот, в том, что она была задвинута математикой в пыльный угол и не получила пока своего развития в сложность.
И нет, это не про физику, это тоже про счёт...
Гадание состоит из двух элементов:
1) Метода диагностики.
2) Языка для описания ситуаций, готового как отразить результаты диагностики, так и передать эти результаты клиенту.
Собственно, сомнению можно подвергать только методы диагностики. Необхоимость же описательного аппарата для класса задач, касающихся "ситуаций" очевидна. И именно гадательные практики дают варианты таких описаний, гораздо более практичные для отражения сути происходящего и его анализа, чем тот же BPM.
Про критерии опровержимости можно модель саму и спросить, загрузив в неё обратно эту портянку. Собственно, можно точно так же, загрузив портянку, спросить и выжимку по ней - если Вам читать долго, или что-то найти хотите. Модель для этого и предназначена и не надломится. Собственно, для этого портянка и нужна в таких статьях - это "исходник", чтобы каждый мог поиграть (не знаю, осознанно ли это сделал автор, но сделал верно!). Просто культура использования ИИ ещё не очень развита и эти возможности не так очевидны, как, например, перемножение при помощи калькулятора.
Однако, для оценки идеи (а представлена именно она) опровержимость не принципиальна - идея оценивается здравым смыслом и интуицией, а формального доказательства требует только, когда превращается в теорию.
Но Ваш комментарий затрагивает более глубокую проблему. Дело в том, что в среде математических догматиков есть две стыдных правды. И обе они относятся именно к теме опровержимости.
Непонимание того, что опровержимость имеет границы применения. Например, если вы докажете, что 2 х 2 != 4, или сможете нарушить коммутативный закон, то сломаете арифметику. Однако, это опровержение даётся в рамках "математической песочницы", строго её аппаратом и строго в границах тезиса о том, что всё на свете выразимо скалярными величинами посредством операторов преобразования. И за эти рамки с требованием опровержимости выходить не следует.
Если же мы переходим в область метафизики (а представленный текст - это она), то у нас меняется понятие исчисляемого элемента. Грубо говоря, если в математике у нас операторы - это действия преобразования, а исчисляемое - количество, то в метафизике исчисляемым становятся качество (характеристика процесса состоящего из однотипных действий преобразования), а операторами становятся разные грани их соответствия. И вот тут у нас вопрос о фальсифицируемости разделяется на два разных:
Вопрос о фальсифицируемости тезисов метафизических теорий в рамках "метафизической песочницы". Например, существует тезис (не из этой статьи, из Науки складности), что "любой корректный аналитический срез ситуации даёт ровно четыре взаимоисключающих процесса, его составляющих и в нём возможных". Далее этот тезис можно как доказывать, так и фальсифицировать в рамках инструментария метафизики.
Вопрос о фальсифицируемости самой математики: а действительно ли у нас "вообще всё" выразимо её аппаратом? И если Вы, вдруг, решите отказать метафизике в праве на существование, то начните с приведения критерия фальсифицируемости самой математики - её права быть единственной "песочницей исчисления". Хотя бы задумайтесь об этой задаче.
И вот стыдная правда в том, что математики второго вопроса обсуждать не просто не готовы, они (по крайней мере те, кто действительно собой что-то представляет) прекрасно чувствуют его существование и... старательно обходят, накладывая, по сути, прямой запрет на академическое обсуждение метафизики. Такое вот поборничество Истины...
P.S. Автору: да, интересно, спасибо. Портянку к себе утащил, погоняю.
А что вы всё-таки тестировали? Точность поиска опорных документов в RAG, т.е. эмбеддинги, или точность обработки найденных опорных документов для выдачи ответа?
Есть такая инструкция от художников: "как нарисовать сову". Она очень простая:
1. Рисуете овал
2. На нём рисуете ещё один овал.
3. Превращаете это в сову.
Тут очень похоже: "а затем мы берём вот такую схему и делаем по ней многоголовое внимание". А если хотите, то читайте AIAYN, в котором вообще всё кристально ясно.
P.S. Ну и про эмбеддинги - тоже сова.
Потому что если эту магию оставить, то, в остальном, достаточно сказать, что это многослойная байесова сеть, которая по отрезку из символов генерит следующий символ и это итеративно замыкается.
На самом деле, чего нигде не видел - так это как раз описания базовой статьи вот таким простым языком, как Вы начали.
А зачем нужен реранк в прведённом случае? Ведь, поиск, с одной стороны, вернёт score, которые считаются как мера близости к вектору вопроса. А с другой - если мы выбираем 3-5 чанков, то отвечающая ЛЛМ сама разберётся, что ей релевантно, а что нет - можно вместе с мусором прогрузить.
Реранкер, наверное, более интересен, если, например, грепнули сайтик, или длинный документ и чтобы из него ради разового запроса не строить вектора и потом в них не искать, а сразу получить сортировку.
Бирюзовые организации хороши при сочетании двух факторов:
1) Когда сотрудники подбираются только такие, которые понимают ценность бирюзовых отношений. Таких в России полно, но тут есть нюанс: кто-то должен недрогнувшей рукой выгонять инотипных. А это сложно, вдобавок, ещё потому что бирюзовый психотип слишком совестью мучается.
2) Когда бизнес находится в области турбулентности, правила и ходы в которой неизвестны. Либо это новый бизнес, либо новая область, либо на улице очередной кризис и старые правила не работают, а новые ещё не устоялись. Т.е., когда неизвестно, кто в реальности окажется прав.
Вот в этой ситуации красные вчистую проиграют тем, кто сможет собрать бирюзовый процесс.
С другой стороны, красные выигрывают, когда есть админресурс и есть люди однозначно более важные для компании, а есть менее важные. И это, обычно, времена, когда бизнес делают знакомства и правильные контракты, а не изобретательность, или, к примеру, оранжевая эффективность производства. И это для России не меньшая константа, чем статистическое преобладание бирюзово-ориентированных граждан.
Поэтому на таких качелях и живём и, действительно, это особенность территории.
В общем, всё имеет своё место, время, форму и предназначение, а мода - это от лукавого.
Бывает, что и к красному гиганту полезно пристроить бирюзовый анклавчик для иновационного поиска. Потратят они сильно меньше, чем красные в сумме теряют на управленческом
долбоклюйствеформализме, а что-то интересное, может быть, и сколхозят. А может - и нет :) Но, к сожалению, это фантазийный совет, поскольку красные не смогут удержаться, чтобы не развалить бирюзовое дело при первых же признаках полезного выхода от него.В этой секте есть свои акронимические принципы. Например, SOLID
(случайно придумалось, можете забирать, если глянется)
Separated - разделённый
Разделяйте всё: декларацию от имплементации, интерфейс от логики, хранение от вычисления и т.д. Код, написанный таким образом, выглядит более профессионально.
Occult - мистический
После того, как вы всё разделили, необходимо это связать. Передайте небольшие части деклараций в имплементацию, хранилище создайте в интерфейсе и т.д. Все части, разделённые на предыдущем шаге должны хранить частичку друг друга. Это обеспечит самосохраение вашего целостного замысла при попытках рефакторинга всякими неумехами и не даст его сломать.
Теперь вам должен стать понятен истинный смысл первого шага: кто плохо разделяет, тому потом нечего связывать.
Levelled - уровневый
Для любой задачи создавайте уровни абстракции. Задумайтесь, какую общую проблему решает этот цикл, или интерфейс? Например, если вам нужно хранить конфигурацию, то необходимо понимать, что это достаточно общая задача и их удобно держать в человекочитаемом формате. Например, yaml. Создайте вначале абстракцию конфига, затем абстракцию чтерия из него в словарь. Но, поскольку в программе удобнее обращаться к переменным, не лишней будет ещё абстракция перевода значений в имена переменных модуля настроек. Но лучше - в переменные объекта, чтобы можно было иметь несколько независимых инстансов, если понадобится.
Теперь добавьте немножко оккультизма: будет хорошо, если эти имена будут вычисляться, чтобы соответствие значений конфига и переменных модуля нигде в коде не встречалось. Только так можно получить подлинную абстракцию.
Intelligent - интеллектуальный
Используйте самые передовые алгоритмические техники, которыми владеете. Это сокращает линейный код на 10%.
Descriptive - наглядно описательный
Все переменные должны быть названы в терминах ваших абстракций. Тот, кто будет читать ваш код, должен иметь возможность погрузиться в ход ваших рассуждений, чтобы начать в нём ориентироваться. Лучше, конечно, если он начнёт знакомство именно с чтения всех абстракций и правильные имена позволяют это сделать.
Вспомнилось... есть (был) такой язык perl - там если писать плейн-код правильно, то очень скучно и лучше вообще какойньть другой язык взять. А если писать так, как он задуман, то весело, но потом ничего не понятно. Было весело, конечно... :)
Статья жизненная, жду продолжения.