Речь шла о необязательных полях и про то что разные источники заполняют эти необязательные поля ресурсов по своему, кто-то заполняет одни поля, кто-то - другие.
еще из минусов такого решения - в случае бизнес ошибок с 200 статусом вы их не увидите как ошибки в телеметрии a-la Application Insights и т.п., по крайней мере без танцев с бубном
Кроме размера модели есть еще размер контекста, и ему тоже нужны вычислительные ресурсы - с текущим доступным объемом в 128К LLM похожа на белку забывающую где закопала орех через 5 минут.
И RAG не всегда помогает т.к. простой cosine similarity не справляется при наличии непрямых зависимостях между частями исходных данных либо при запросах которые прямо касаются их всех.
если на таком оборудовании как у DeepSeek можно натренировать LLM уровня O1 (потенциально) то что можно сделать на топовом кластере от NVDA используя тот же подход, вот в чем вопрос?
Прошу прощения,видимо я недостаточно понятно изъяснялся. Я имел в виду проверки на NULL в DOM модели FHIR, например при работе с библиотеками типа https://github.com/FirelyTeam/firely-net-sdk или https://github.com/samply/golang-fhir-models.
Речь шла о необязательных полях и про то что разные источники заполняют эти необязательные поля ресурсов по своему, кто-то заполняет одни поля, кто-то - другие.
еще из минусов такого решения - в случае бизнес ошибок с 200 статусом вы их не увидите как ошибки в телеметрии a-la Application Insights и т.п., по крайней мере без танцев с бубном
Кроме размера модели есть еще размер контекста, и ему тоже нужны вычислительные ресурсы - с текущим доступным объемом в 128К LLM похожа на белку забывающую где закопала орех через 5 минут.
И RAG не всегда помогает т.к. простой cosine similarity не справляется при наличии непрямых зависимостях между частями исходных данных либо при запросах которые прямо касаются их всех.
если на таком оборудовании как у DeepSeek можно натренировать LLM уровня O1 (потенциально) то что можно сделать на топовом кластере от NVDA используя тот же подход, вот в чем вопрос?