rPman

Питание на процессор подается только после очень сложного многоступенчатого процесса проверки, поэтому ничего с ним не случится.

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

И да и нет.

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

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

Я бы не надеялся что все произойдет 'как по маслу' и главное, остается огромное количество мусора в .cache, .local и т.п. там и так гигабайтами все копится и копится. Я буквально недавно переносил конфиги руками, сделав резервную копию каталога и создав новый профиль... там много всякого лишнего, и удаляемые приложения за собой ничего не чистят.

И нет и, может быть, да. Помимо llama существует лучше модели, например mistral и основанные на нем типа openchat35 или лучше mixtral (он неожиданно умный и скорости как 7b) или или еще лучше от databrix (по скорости как llama30b).

У разработчиков языковых моделей например есть chat версии, есть instruct, а есть base. Общий смысл каждой определяется тем, на какое именно использование их заточили. Например instruct позволяет описывать инструкции на естественном языке и главное получать ответ тоже на естественном языке, со всеми вытекающими от сюда неудобствами (api предполагает стандартизацию форматов вывода). chat ожидает что с ним будут общаться в формате user: xxx, ну а base модели изначально работают только как completion, и их обычно дообучают до своих форматов и наборов знаний.

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

Так как llm это посимвольная (по токенам точнее) генерация ответа, на каждом из них, в момент когда происходит выбор следующего токена, можно вставить свой алгоритм, ограничивающий доступный список своими, по своему правилу. Например можно описать регулярное выражение, которое будет применяться к сгенерированному тексту плюс выбираемый токен и если оно не подходит, отказывать в выборе этого токена. Например какая то реализация этого есть в llama.cpp ищи grammar, это ключ у api вызова к server.

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

Есть общепринятые лайфхаки, повышающие качество ответа. Это добавление примеров (вопрос+ответ+вопрос+ответ+вопрос+...) т.е. one-shot/multi-shot, именно так слабые модели могут встать по бенчмаркам с zero-shot у сильных моделей, без примеров. Или попросить в запросе модель поразмышлять (think step by step), надавить на эмоции (найти ответ очень важно для меня, от этого зависит моя жизнь), ценой места в окне контекста. Еще есть подход, делать один и тот же запрос (или кстати слегка менять prompt) много раз, и сделать какой то механизм валидации ответа (например большая часть одних и тех же ответов считать верной) - как защита от галлюцинаций (был пример когда модель заставили миллион раз генерировать программу, запускать ее и проверять результат - так сделали реальное научное открытие)

НО! Просто не будет.

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

Там специалисты должны выпаять чипы памяти (или подключиться к ним с помощью специализированного железа и софта) и проанализировать их содержимое.

Внутри ssd есть своя как бы файловая система, скорее всего похожая на cow, где каждая следующая запись пишется в новое место, даже если это один и тот же сектор с точки зрения пользователя (это нужно для равномерного распределения записей по ячейкам), значит можно раскрутить этот лог назад, если система не успела исполнить для этих участков trim. Но, к сожалению, записи происходят сразу по всему объему диска (современные чипы памяти это многоуровневые цепочки бит, запись которых происходит циклически, первые биты записываются быстро, последующие биты в цепочках - медленно, когда происходит запись, сначала контроллер пишет данные в каждые первые биты этих цепочек и запускает фоном процесс перераспределения, чтения записанных данных в первые биты и перезапись их в глубь каждой цепочки, это медленнее, как минимум именно так реализуют кеширование записи на дешевых пользовательских накопителях (а может и на всех). Именно поэтому примерно 20% свободного места на диске будут записаны на максимальной скорости а затем скорость упадет в десяток раз именно потому что свободных 'первых бит' не остается и контроллер ждет окончание перераспределения.

p.s. напоминаю, что любые операции записи на этот диск уменьшают шансы восстановления данных, например если на этом диске хранится ОС и был ее запуск, или на этот же диск устанавливал приложения для восстановления данных.

Если держать ssd в жарком месте (например, например в машине, на солнцепеке) то скорость деградации сильно увеличивается до месяца +-

ssd не подходит для offline хранения данных, технологии требуют наличие питания хотя бы изредка, контроллер сам следит за перераспределением данных. Но! дешевые могут это делать только во время записи, что так же не способствует сохранению данных на долгосрок.