В каждой из этих областей Агенты работают как усилитель. Усиливается, в том числе, и глупость (например, по незнанию). Более близкая мне аналогия - экзоскелет. Если не знаешь, как грамотно колоть дрова - наломаешь дров, на все деньги. А если знаешь - будет быстрее, чем руками топором махать.
Эволюция инструмента поиска: изначально использовали RAG с векторной базой данных – быстро, но требует индексации, хрупко в разных окружениях, и главное – Claude не любил его использовать. Переход на инструмент Grep, позволяющий Claude искать самостоятельно, оказался гораздо удобнее.
Ловко. Зачем все эти embedding, vector databases, semantic graphs и т.д. Не любит Claude это использовать, лучше Grep (Grep Searches for patterns in file contents).
Один раз только неправильный ответ был, на Hard: H01: Balanced Parentheses. Со второй попытки - решено.
Josephus Problem - вообще легко оказалось (в смысле - быстро). Возможно, моделька натренировалась на первых задачах, всё в одном чате делал.
В качестве промпта давал текст задания, за исключение первого задания, там добавил такое описание языка:
Syntax:
Character Instruction Performed
> Increment the data pointer by one (to point to the next cell to the right).
< Decrement the data pointer by one (to point to the next cell to the left). Undefined if at 0.
+ Increment the byte at the data pointer by one modulo 256.
- Decrement the byte at the data pointer by one modulo 256.
. Output the byte at the data pointer.
, Accept one byte of input, storing its value in the byte at the data pointer.[b]
Я бы рассмотрел ситуацию пошире - математика и физика дают модель мира. Мир не обязан подчиняться модели. Собственно, история науки во многом представляет из себя "кладбище видов (моделей)" (по аналогии с биологической эволюцией).
Т.е., с одной стороны, проблема шире, чем "неподчинение преступника" а с другой - математика, в применении к реальному миру, в каком-то смысле работает. Хотя мир ей не подчиняется.
Тут неполная индукция, но авторское написание несколько необычно.
фасолина_1, взятая из этого мешочка - белая фасолина_2, взята из этого мешочка - белая ... фасолина_n, взята из этого мешочка - белая Следовательно: Вероятно, все фасолины, взятая из этого мешочка - белые
Тут можно моделировать через комбинацию методов. По абдукции выдвигается гипотеза - т.е. вот, есть набор фактов, смотрим, в каких ещё случаях такая комбинация фактов появлялась.
Наш случай - наши факты Случай1 - тоже наши факты Ergo: Наш случай - Случай1
Ergo тут ненадёжное, ибо вывод абдуктивный, и это не более, чем гипотеза, которая нуждается в проверке. Тем более, что по набору фактов "матчится" много других случаев.
Собственно, для отсечения лишнего может использоваться дедукция, которая отбрасывает варианты. Так сказать, апофатический метод познания.
Но скорее всего это была проблема не БД, а генеративного ИИ и promt injection.
Интересно. Поясните, как это могло произойти? Я, причём, спрашиваю на русском или английском, а вижу фрагменты ответов на испанском (я в тот период был в Испании, если что).
Но это не означает что задача не решаема в принципе, популярный стек: Patroni + Consul (ZooKeeper или etcd), для получения автоматического failover.
Дык в принципе оно конечно решается, кто ж спорит. Но по рассматриваемому факту у OpenAI не решилось - они это дело аутсорсят вместо того, чтобы взять bare metal и сэкономить денег.
Но смысл и сила PostgreSQL, как раз в реляционной модели и ACID.
Это в каком-то смысле верно.
Но если целиться в распределённую систему, то сила реляционной модели превращается в её слабость. Для high-load OLTP нагрузки лучше подходят key-value базы, ибо для скорости требуется точечное чтение - запись. Для OLAP нужна колоночная база, там и скорость, и сжатие огромное.
Про то что бизнесу всё равно: ему всё равно, пока не приходят счета))
Так как раз счета придут больше, если обеспечивать strict consistency там, где этого не требуется. Именно через этот аргумент бизнес и убеждается легко в том, что давайте лучше eventual consistency, где можно - дешевле выйдет.
По остальному предметно без данных конкретных экспериментов говорить не готов. Но, впрочем, качественно склонен согласится.
И PostgreSQL вполне спокойно работает в таких условиях
Можно подробнее, как он работает? Вот есть три bare metal сервера в трёх ДЦ, что нужно сделать, чтобы обеспечить strict consistency и fault tolerance к выпадению одного ДЦ? Для cassandra/scylla это решается штатно незамысловатым конфигом.
Достаточно просто также добавить дискового пространства и вычислительных мощностей в систему путем добавления узлов - это тоже штатные процедуры. Как с этим у PostgreSQL?
Плюс большие требования для железа, это будет 1,5-2 раза (субъективно) будет занимать больше места на то же количество информации в сравнении с реляционками.
Ну тут таки да, три копии данных вместо двух (у Postgres) в стандартной HA-конфигурации.
Главный же момент, который отталкивает именно бизнес, это сама парадигма: жертвуя консистентностью в пользу доступности (до этого понимания нужно дорасти).
По опыту, бизнесу вообще это не очень важно или легко объясняется. Тут скорее вопрос в технарях, и как раз та самая "переоптимизация".
Я полностью поддерживаю идею использовать Postgress в большинстве "начальных" случаев -- при условии наличия в команде соответствующих компетенций, конечно.
В основном полемика идёт вокруг тезиса "PostgreSQL могут ещё дать фору новомодным решениям".
Вот смотрите, Вы пишете: "когда ты точно знаешь что строишь геораспределённую систему на несколько континентов". Почему же сразу гео и на несколько континентов? А уметь переживать падение датацентра внутри континента - разве не является задачей, достойной рассмотрения?
Cassandra/Scylla решают это задачу так... Ну как решают - это у них в DNA прописано. RF=3, NetworkTopologyStrategy и т.д. Т.е. всё работает прямо "из коробки", не требуя особых усилий по конфигурации и доработке ПО.
Вот такой аспект, конечно, посложнее будет - "точно понять какие запросы будут нужны". С Cassandra надо работать в парадигме ключ-значение, CQL лишь способ придать некоторую структуру ключам и значениям, не более. Запрос на чтение - всегда по ключу или по подключу. Все сложные соединения и агрегации - через заранее подготовленные материализованные VIEW. У нас вот этот продукт сделан по такой технологии.
В основном всё круто работает. Основная проблема - получить развёрнутую статистику по всем клиентам. Тут пока думаем использовать ClickHouse. Ну т.е. Scylla/Cassandra - это OLTP профиль нагрузки, ClickHouse - OLAP. Это, к тому же, разные типы хранения - строковые и колоночные.
Тогда как многие программисты плюются на SDD именно потому, что, мол, зачем вычитывать/править кучу текста
Тут есть определённая проблема с "кучей". "Кучу текста" трудно понять и гарантировать, что реализация соответствует этой самой куче.
LLM тут отчасти помогают - можно сделать review на соответствие - но на "куче" весьма высок процент ложно-положительных срабатываний.
PS. Сам постоянно пишу спеки, перечень проблем примерно такоей- сделать покороче, убрать дублирование и описание очевидных моментов, добиться согласованности.
Любопытно. А можно подробнее про "классическое понимание"? Вот есть, например, Guide to the Software Engineering Body of Knowledge
Содержание
Software requirements
Software architecture
Software design
Software construction
Software testing
Software engineering operations
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering models and methods
Software quality
Software security
Software engineering professional practice
Software engineering economics
Computing foundations
Mathematical foundations
Engineering foundations
В каждой из этих областей Агенты работают как усилитель. Усиливается, в том числе, и глупость (например, по незнанию). Более близкая мне аналогия - экзоскелет. Если не знаешь, как грамотно колоть дрова - наломаешь дров, на все деньги. А если знаешь - будет быстрее, чем руками топором махать.
Это понятно. Но вот перешли к другому .py-файлу, что происходит? Правило опять перечитывается?
Интересно. Не в курсе - это грузится для каждого файла каждый раз или тоже подвержено компрессии?
Ловко. Зачем все эти embedding, vector databases, semantic graphs и т.д. Не любит Claude это использовать, лучше Grep (Grep Searches for patterns in file contents).
Занятный тест. Попробовал погонять.
Opus 4.6 Extended, практически без проблем вот это: B.3 Complete Problem Examples
B.3.1 Easy: E04: Sum Two Integers
B.3.2 Medium: M08: Nth Fibonacci Number
B.3.3 Hard: H01: Balanced Parentheses
B.3.4Extra-Hard: X20: Josephus Problem
Один раз только неправильный ответ был, на Hard: H01: Balanced Parentheses. Со второй попытки - решено.
Josephus Problem - вообще легко оказалось (в смысле - быстро). Возможно, моделька натренировалась на первых задачах, всё в одном чате делал.
В качестве промпта давал текст задания, за исключение первого задания, там добавил такое описание языка:
Вот у нас есть немного кровоточащий энтерпрайз-проект:
AI работает так же, как и на маленьких проектах. А именно - как экзоскелет. Если знаешь, что делать, то поможет, а если не знаешь - всё сломаешь.
Однако, сильно зависит от tooling. Вот прямо очень сильно. Мы Augment Code используем.
Интересный разбор, даже попросил "машину" (кавычки, да) написать опус на заданную тему: DPI: Обнаружение и Маскировка Туннелей.
Машинная самокритика:
Я бы рассмотрел ситуацию пошире - математика и физика дают модель мира. Мир не обязан подчиняться модели. Собственно, история науки во многом представляет из себя "кладбище видов (моделей)" (по аналогии с биологической эволюцией).
Т.е., с одной стороны, проблема шире, чем "неподчинение преступника" а с другой - математика, в применении к реальному миру, в каком-то смысле работает. Хотя мир ей не подчиняется.
Есть ведь определения как "неполной", так и "полной" индукции (ака "математическая"). Для второго случая всё достаточно строго, т.е. доказываем что:
Eсли утверждение верно для n то оно верно для n+1
Утверждение верно для n=1
Ну и далее считается, что все доказано для любого n > 0.
Мне представляется, что это упрощение, будем так говорить - несколько чрезмерно - в рамках заданной темы.
Тут неполная индукция, но авторское написание несколько необычно.
фасолина_1, взятая из этого мешочка - белая
фасолина_2, взята из этого мешочка - белая
...
фасолина_n, взята из этого мешочка - белая
Следовательно: Вероятно, все фасолины, взятая из этого мешочка - белые
Тут можно моделировать через комбинацию методов. По абдукции выдвигается гипотеза - т.е. вот, есть набор фактов, смотрим, в каких ещё случаях такая комбинация фактов появлялась.
Наш случай - наши факты
Случай1 - тоже наши факты
Ergo: Наш случай - Случай1
Ergo тут ненадёжное, ибо вывод абдуктивный, и это не более, чем гипотеза, которая нуждается в проверке. Тем более, что по набору фактов "матчится" много других случаев.
Собственно, для отсечения лишнего может использоваться дедукция, которая отбрасывает варианты. Так сказать, апофатический метод познания.
Пусть цветут все цветы.
Почему трава зелёная?
Намекаете, что если изменить права доступа к БД PostgreSQL то это никак не повлияет на результат запроса?
В статье же пишут: a single Rust .unwrap() in Cloudflare's edge network.
Безусловно. В этом замечена монструозность архитектур - чем архитектура монструознее, тем больше вероятность прокола.
Интересно. Поясните, как это могло произойти? Я, причём, спрашиваю на русском или английском, а вижу фрагменты ответов на испанском (я в тот период был в Испании, если что).
Дык в принципе оно конечно решается, кто ж спорит. Но по рассматриваемому факту у OpenAI не решилось - они это дело аутсорсят вместо того, чтобы взять bare metal и сэкономить денег.
Это в каком-то смысле верно.
Но если целиться в распределённую систему, то сила реляционной модели превращается в её слабость. Для high-load OLTP нагрузки лучше подходят key-value базы, ибо для скорости требуется точечное чтение - запись. Для OLAP нужна колоночная база, там и скорость, и сжатие огромное.
Так как раз счета придут больше, если обеспечивать strict consistency там, где этого не требуется. Именно через этот аргумент бизнес и убеждается легко в том, что давайте лучше eventual consistency, где можно - дешевле выйдет.
По остальному предметно без данных конкретных экспериментов говорить не готов. Но, впрочем, качественно склонен согласится.
Как пример - интересно, как контраргумент - не очень убеждает.
Тут недавно Cloudflare лихорадило, при всей квалификации разрабов и надёжности языка Rust...
PS. А ничего, что система с бэком, который работает на PostgreSQL, мне показывала куски чатов от других пользователей?
Можно подробнее, как он работает? Вот есть три bare metal сервера в трёх ДЦ, что нужно сделать, чтобы обеспечить strict consistency и fault tolerance к выпадению одного ДЦ? Для cassandra/scylla это решается штатно незамысловатым конфигом.
Достаточно просто также добавить дискового пространства и вычислительных мощностей в систему путем добавления узлов - это тоже штатные процедуры. Как с этим у PostgreSQL?
Ну тут таки да, три копии данных вместо двух (у Postgres) в стандартной HA-конфигурации.
По опыту, бизнесу вообще это не очень важно или легко объясняется. Тут скорее вопрос в технарях, и как раз та самая "переоптимизация".
Я полностью поддерживаю идею использовать Postgress в большинстве "начальных" случаев -- при условии наличия в команде соответствующих компетенций, конечно.
В основном полемика идёт вокруг тезиса "PostgreSQL могут ещё дать фору новомодным решениям".
Вот смотрите, Вы пишете: "когда ты точно знаешь что строишь геораспределённую систему на несколько континентов". Почему же сразу гео и на несколько континентов? А уметь переживать падение датацентра внутри континента - разве не является задачей, достойной рассмотрения?
Cassandra/Scylla решают это задачу так... Ну как решают - это у них в DNA прописано. RF=3, NetworkTopologyStrategy и т.д. Т.е. всё работает прямо "из коробки", не требуя особых усилий по конфигурации и доработке ПО.
Вот такой аспект, конечно, посложнее будет - "точно понять какие запросы будут нужны". С Cassandra надо работать в парадигме ключ-значение, CQL лишь способ придать некоторую структуру ключам и значениям, не более. Запрос на чтение - всегда по ключу или по подключу. Все сложные соединения и агрегации - через заранее подготовленные материализованные VIEW. У нас вот этот продукт сделан по такой технологии.
В основном всё круто работает. Основная проблема - получить развёрнутую статистику по всем клиентам. Тут пока думаем использовать ClickHouse. Ну т.е. Scylla/Cassandra - это OLTP профиль нагрузки, ClickHouse - OLAP. Это, к тому же, разные типы хранения - строковые и колоночные.
Неплохо👍Вот в другом стиле вариант
Тут есть определённая проблема с "кучей". "Кучу текста" трудно понять и гарантировать, что реализация соответствует этой самой куче.
LLM тут отчасти помогают - можно сделать review на соответствие - но на "куче" весьма высок процент ложно-положительных срабатываний.
PS. Сам постоянно пишу спеки, перечень проблем примерно такоей- сделать покороче, убрать дублирование и описание очевидных моментов, добиться согласованности.