Как у вас устроен процесс версионирования as is и to be? Когда нужно одновременно иметь 2 диаграммы - для текущей ситуации и для, скажем, планового длительного рефакторинга, по итогу которого будут существенные архитектурные изменения.
Про это и речь. Возможно, мне не хватает деталей для полной картины, но пока выглядит как неочевидный UX, если пользователю потребуется еще раз нажимать на кнопку "купить" уже после произведенной оплаты.
Модель использовал пару часов - ни разу oom не ловил
На
deepseek-r1:14bпо ощущениям проблема еще хуже. В одном ответе может 3+ языка встречатьсяПри запуске локально
deepseek-r1:32bв ответах периодически каша из языков:Пару раз китайские иероглифы добавил:
Только что запустил на 4080, утилизируется ~15800 MB
Как у вас устроен процесс версионирования as is и to be? Когда нужно одновременно иметь 2 диаграммы - для текущей ситуации и для, скажем, планового длительного рефакторинга, по итогу которого будут существенные архитектурные изменения.
Про это и речь. Возможно, мне не хватает деталей для полной картины, но пока выглядит как неочевидный UX, если пользователю потребуется еще раз нажимать на кнопку "купить" уже после произведенной оплаты.
По схеме возможна ситуация:
П.1 и 2 корректно отработали - пользователь выбрал товар, перешел на платформу, оплатил.
П.3 не отработал (по какой-то причине) - бэкенд вообще не узнает о попытке оплаты и ее результате со всеми вытекающими.
На схеме просто не отражено, или вы такие ситуации не учитываете?