Ярослав

С LLM у тебя только два варианта - добавлять информацию в запрос, а в случае с противоречиями, тюнить и усложнять подводку, типа если ты хочешь чтобы везде где сетка использует цвет красный она говорила


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

Этот механизм имеет недостатки, из-за проблемы 'катастрофического забывания', чем больше данных ты пытаешься добавить в модель через дообучение, тем больше она забывает ранее выученных (с этим борются подмешиванием данных из изначальной обучающей выборки но это не так просто)

На самом деле эта путаница по-человечески очень понятна и объяснима.
Вы, как фронтендер, воспринимаете "веб-сервер" как такой черный ящик, "то место, откуда фронт запрашивает данные".

В то время как этот термин может означать несколько разных понятий.
1. Веб-сервер в вашем, широком понимании. Бэкенд целиком.
2. Также веб-сервером может называться и сам компьютер, на котором все это крутится.
3. В более узком смысле - это программа, которая принимает НТТР запросы. Вот это nginx и есть. Но сам по себе, без помощи других программ, он не может полностью представлять услуги веб-сервера. Например, в нем нет базы данных. Это, скорее, как правильно написали в соседнем ответе - такой прокси-сервер, который частично обрабатывает запросы сам (например к статическим файлам), а частично - проксирует запросы на другие программы.

И вот на Го (или РНР, Питоне, JS, C#) как раз и пишется эта программа, которая, к примеру, обращается в БД, получает нужные данные и отдает их Nginx-у, который уже и возвращает их клиенту

Ты как будто отсутствовал последний год и пропустил бум ChatGPT. Этот алгоритм нейронных сетей (Generative Pre-trained Transformer) был разработан в 2017-ом 'гуглом' и 'доведен до ума' публично в OpenAI (их chatgpt4 сейчас самый продвинутый универсальный генератор текста, проявляющий признаки интеллекта).

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

На текущий момент самая крутая из доступных нейронных сетей (доступные предобученные веса сети), которую можно доучивать под свою задачу или даже пользоваться как есть, - это фейсбуковская llama2 (бесплатная, с очень либеральной лицензией, позволяющая коммерческое использование), ее можно запускать на процессоре на десктопной машине с меньше 64гб ram (скорость от 1токен в секунду, слово это 1-7 токенов) с помощью llama.cpp или на машине с GPU, суммарной емкостью vram от 80Gb (я не нашел точные минимальные требования, квантизация 8бит доступна в штатном коде llama а 4-битную тоже можно но я не уверен какие проекты уже поддерживают llama2).

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

p.s. самостоятельная разработка (сбор обучающих данных и обучение) с нуля подобного проекта невероятно дорогая, слабые версии имеют оценку стоимости обучения (при наличии специалистов, которые уже стали на вес золота) в десятки миллионов баксов только на оборудование (тоже дефицитное, так как используется в основном кластеры на основе оборудования nvidia, которые монополисты в ИИ и рисуют 10х стоимость не моргнув глазом а еще искусственно не расширяют производство чипов при наличии высокого спроса)

Но если взять уже обученную сетку (веса) собрать небольшой датасет текстов под свою задачу, то тюнинг будет достаточно дешевым, вот еще со старой llama так делали

Надо попробовать еще раз с Media Wiki API.
У всех получается - и у вас получится.

Парсить "в лоб" сайт, у которого есть API - это идиотизм и забивание гвоздей микроскопом.

Ярославище, не поверишь, но ленточка до сих пор остается наиболее дешевым и обьемным хранилищем. В этом отношении с 1990 года ничего не изменилось, разве только магнитофоны стали намного меньше :)
Плюсы у них как всегда - долговечность 15-30 лет и фантастическая дешевизна на гиг обьема хранения. И можно картридж спрятать в сейф, поставить печать и посадить солдата с винтовкой :)

Лет 10 назад можно было на барахолках купить стриммеры HP. А кассет было много на предприятиях. Некоторые впоследствии на радиорынках продавались еще в нераспечатанном виде. Производитель лент гарантировал что-то вроде 15 лет хранения информации (при условиях правильной температуры и влажности). Это - самые длительные сроки что я видел. Размер касеты у них кажется был 20-40Гб.

Еще Verbatim продвигал какие-то особо прочные DVD+R диски с алмазным покрытием. А по объему кажется это были 4.7G Надо посмотреть я не помню точно. Вобщем надо искать + еще покупать пищущее устройство.
А сейчас даже ноуты продают уже без DVD привода.

Я у себя дома храню на двух HDD дисках серии WD-Green. Конечно непонятно что делать если от времени сгорает
контроллер но вроде как 2 сразу в один день не должны сгореть.

Я думаю, проще взять виртуалку в каком-нить hetzner/digitalocean

Облачные сервисы больше заточены на предоставление различных saas/paas и хороши для быстрого/автоматического масштабирования различных сервисов.
И мне кажется, что для маленьких вещей минимальная плата там выше чем, скажем, минимальная виртуалка у более "стандартных" хостеров, где нужно будет руками поставить докер, настроить и запустить.

Мьютексы, семафоры, критические секции. То есть добавь объекты синхронизации, чтобы гарантировать, что объекты изменяются упорядоченно и только одним потоком в единицу времени.

Если проект ориентирован на РФ, то регистрируйтесь как саможанятный. Все крайне просто и никаких отчислений без доходов. А затем Юкассу подключает.

Есть стандарты RFC 8620, RFC 8621 RFC 8887 (JMAP), фактически на REST API для почты и того что рядом с ней, если поищите - есть библиотеки этот стандарт реализующие, например сервер и клиент на Rust.

По факту, это стандартизованный FastMail'ом его API, другим вебпочтам переезжать со своего давно написанного и отлаженного API на FastMail'овский причин нет, т.к. это означает что придется переписывать не только серверную, но и клиентскую часть, причем при наличии мобильных приложений использующих API какое-то время поддерживать две версии API, потому что пересадить клиентов на новый API одномоментно невозможно, а преимуществ, по крайней мере прямо сейчас нет - "универсальные" клиенты используют IMAP.

Есть и другие документированые (но не стандартизованные) API, например у Google.

Потому что IMAP - это сам себе протокол.
Каждый почтовый сервис может для себя придумать какой-нибудь свой REST API, но все эти варианты не стандартизированы.

Из стандартизированных есть jmap, но мало кто его использует.