Какая AI модель дешевле в пересчете на решение задачи в программировании?

Дмитрий, Дмитрий, вы пишите много полезной информации, приводите интересные примеры, но не отвечаете на суть исходного вопроса. Вы пишите о задачах, инструментах, моделях, гвоздях, молотках, шуруповертах, абстракции, выборе моделей под задачи, mcp, rag, отсутствии разницы, объеме контекста и прочем. Вы показываете свою экспертность, верно указываете некоторые моменты, но уводите в сторону от сути вопроса.

Можете привести из своей практике примеры в формате: одна и та же задача > разные модели > кол-во итераций > итоговая стоимость? Есть такой опыт?

Какая AI модель дешевле в пересчете на решение задачи в программировании?

Василий Банников, У вас есть практические наблюдения по сути вопроса?

Какая AI модель дешевле в пересчете на решение задачи в программировании?

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

Если вы натаиваете, то давайте пройдемся по вопросам:

1. Для каких тебе задач нужна модель? — Для кодинга python, javascript, html, css, sql и т. п. Это как-то отвечает на мой вопрос о наблюдениях людей? — Не думаю.
2. Что она должна делать? — Писать код, проверять. Этот ответ то же не дает ответа на поставленный вопрос.
3. На каких языках кодить? — Python, GO, PHP, SQL. Не увидел тут связи между наблюдениями людей о стоимости.
4. ...

Можно продолжить отвечать на вопросы, но это я отвечаю на вопросы, а не люди делятся опытом в своих наблюдениях о стоимости решения задачей. Мне кажется, вы пытаетесь подобрать инструмент под задачи, но как это решит вопрос — не очень понятно.

Какая AI модель дешевле в пересчете на решение задачи в программировании?

Василий Банников, Василий, если вы пользуетесь ими на платной основе и у вас есть наблюдения по сути вопроса, поделитесь ими, пожалуйста.

Какая AI модель дешевле в пересчете на решение задачи в программировании?

Интересно. Вы про те бесплатные версии, которые после регистрации можно пользовать в ограниченном режиме или вы какую-то схему «замутили» для безлимитного доступа к ним? И, кстати, интересно, почему отказались от платных моделей? Если так случается, что лимит заканчивается, то ждете или переходите на другую сеть?

Какая AI модель дешевле в пересчете на решение задачи в программировании?

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

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Everything_is_bad, задачу озвучил в вопросе. Может быть не совсем корректно, но как мог. Хотелось бы сделать изначально правильно, чтобы потом не править все. Товаров может быть от 100 до 10000 разных (так, для наглядности).

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Adamos, т. е. можно продавать «товар» и «товарное предложение». И то и то по сути — товары. Верно?

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Akina, Если не подходит, то вот 100% варианты из жизни. Есть футболка и ее варианты:
XS / голубой 100 руб
XS / зеленый 100 руб
XS / графитовый 100 руб
S / золотой 100 руб
S / голубой 100 руб
S / зеленый 100 руб
S / графитовый 100 руб
M / золотой 100 руб
M / голубой 200 руб
M / зеленый 100 руб
M / графитовый 100 руб
L / золотой 100 руб
L / голубой 100 руб
L / зеленый 100 руб
L / графитовый 100 руб
XL / золотой 100 руб
XL / голубой 100 руб
XL / зеленый 100 руб
XL / графитовый 100 руб

Какие таблицы для продуктов (и их вариантов) в БД использовать?

ThunderCat, Наверное, плохо объяснил. Постараюсь чуть развернутее. Давайте выберем что-то более конкретное для примера:

Категория = торты.
Бренд = михалыч.
Товар = торт ореховый.
Характеристики: запах = орех, цвет = зеленый, вес = фикс. 900 гр.
Варианты:
— делал сам михалыч (цена = 1500).
— делала жена михалыча (цена = 1200).
— делала гувернантка (цена = 900).
Т. е. у товара может быть характеристики общие и частные, а могут быть, так сказать, некие «генеральные» отличительные особенности, по которым формируется конкретный продукт.

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Adamos, не очень понятна штука «торговое предложение». Как оно реализовано? С продуктами и товарами все понятно, а вот с торговым предложением не очень. Конкретный товар всегда равен торговому предложению? Или только набор товаров == торговому предложению? Могли бы чуть подробнее объяснить?

Какие таблицы для продуктов (и их вариантов) в БД использовать?

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

Adamos, я посмотрел несколько админок и БД нескольких CMS — кто во что горазд. Кто в одну таблицу пишет, кто — в две, кто — в большее количество, другие вообще не очень понятно как. Путей разных много, но хотелось бы обоснованно что-то выбрать, чтобы потом по минимуму переделывать при необходимости. Потому и спрашиваю.

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

Это как раз и есть второй вариант.

В окончательной таблице торговых предложений - набор (возможно, нескольких, в отдельной таблице) товаров и данные, которые будут на витрине (картинка, цена, габариты окончательной упаковки...)

А вот тут не очень понятно то, зачем формировать третью таблицу. Данные уже же будут либо в одной таблице + джойны либо в двух таблицах + джойны.

Возможно, даже очень вероятно, что я не силен в проектировании БД, поэтому такие недопонимания.

Как бы вы реализовали и почему? Мне понятно, что вы написали про три таблицы, но получается так, что вы предложили третий вариант:) Теперь есть третий вариант и надо как-то определиться с выбором.

Какие таблицы для продуктов (и их вариантов) в БД использовать?

ThunderCat, думаю, потому что не знаю. Как-то все запутанно. Характеристики, я полагаю, это какие-то базовые атрибуты товара, а варианты — это нечто вроде такой базовой штуковины, по которым различаются товары. Если взять iphone в качестве примера, то у него будут базовые модели=варианты pro, plus, e и прочее, а внутри уже будут конкретные характеристики. Надо же как-то потом выбирать товары из БД по каким-то основным критериям, а не искать среди множества разных характеристик. Сложно как-то, если подумать...

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Извиняюсь, в БД не очень силен. Можно чуть раскрыть вашу мысль? Атрибуты больше относятся к характеристикам. Т. е. есть общие характеристики и характеристики конкретных вариантов. Вопрос тут больше про то, как лучше организовать слонов — в одну таблицу или две, чтобы можно было потом более или менее нормально выводить и «просто слонов» и каких-то «конкретных слонов» в таблицу.

Какие таблицы для продуктов (и их вариантов) в БД использовать?

Adamos, не очень понял. Могли бы пояснить чуть подробнее.

Как прижать нижние колонки к низу родительского блока?

Zokhan, Может быть, я что-то упустил, но тут нет ни одного подходящего под задачу ответа.

Как прижать нижние колонки к низу родительского блока?

Видите на скриншоте крестики красные?

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

Как прижать нижние колонки к низу родительского блока?

godsplan, гуглил, яндексил. Прижатия к низу на «автомате» не нашел.

Как прижать нижние колонки к низу родительского блока?

imasdf, там то же самое, что и в вопросе.

Как прижать нижние колонки к низу родительского блока?

Hovo_Varosyan, Не, так появляются пустые пространства у контейнеров, а их быть не должно — только у нижних.

Вот так они должны прижиматься к низу и друг к другу: