#240 en tal caso STEAL THE RICH!
#241 en el caso de tunear un modelo de LLM, cuantos intentos soléis hacer con estos modelos?
imagino que primero cogeis varios sub-dataset de prueba, vigilando las distribuciones y demás parámetros, y ahi haces un par de pruebas de parámetros, para hacer cross validation típico y sacar los mejores parámetros
y luego el final es con 10k euros no?
en mi empresa tienen modelos que hacen fine-tunning y llevan ANOS y aun no dan buenos resultados... la verdad... pero claro, me imagino que les pasa como a nosotros y les saldría super caro un intento (50k), y deben usan mierdas de datasets que luego el resultado final fuma porros
ademas son modelos con cosas generativas para rellenar el espacio (long tail) y tal... ósea coste del modelo generativo, de los taggeados... jajaj menudo pozo de dinero es el ML si. mucho hype poco beneficio.
ah y por supuesto son modelos que funcionan geolocalizados, el modelo para UK no funciona para Italia o para Australia JAJAJAJA así que cada equipo tiene que hacer su modelo repitiendo todo.
#242 no recuerdo cuántos tests hicimos (como describes), con cuántos modelos probamos. Tampoco es algo fijo, ahora estamos en nuestra v2 con DeBERTa3. ¿28 modelos? No recuerdo, tengo las métricas por algún lado.
Los 10k€ los invertimos para on premise. Hice cálculos y según el uso que le damos, si sobrevivimos 4 años, nos sale más rentable que tirar de nube. Así de baja ha sido la inversión. (esto es solo para fine tunning y la clasificación mensual de esos millones de objetos). Tiramos de 2×4090. 48 GB de VRAM.
La gran parte del resto de la pipeline va a AWS.
#243 Si on-prem es el futuro.
Por cierto tus cálculos están mal, no veo vuestros salarios a esos 10k jeje : - )
Pues en transmisión de AWS ya veras como se empiece a escalar las cosas. Porque o tienes cosas embedded en memoria con su hardware y tecnología o pagas transmisión.... O te montas la infra de openai (millones de euros) o los pagas a AWS jaja
Yo hablando con Zalando les quería resolver esto porque tienen pipelines de millones de euros que les cuesta tirar 10h. Nah, no lo veían claro. Les ahorraba varios millones de euros al ano pero no me querían pagar lo que les pedia : - ) Ahi sigue esa empresa, en el top 15 e-commerce mundial no?
#244 la inversión para la parte de NLP y clasificación (bueno, lo aprovechamos para todo lo que podemos de cómputo, el resto a AWS). La inversión total en el proyecto ha sido de \~1.5M€, todo ayudas europeas, a fondo perdido, por lo que no hemos tenido que abrir ronda en ningún momento 
#245 Que es retos, parte, innpacto, innoeuropa? no tenéis que ir con ningún centro de r+d de la mano para la ayuda?
#248 la pregunta es ¿cómo es que la UE nos financia para hacer investigación sobre farmacias ilegales de USA? Esa pregunta le hice a mi socio cuando, de aquellas como potencial jefe, me hizo la entrevista de trabajo XD
Disculpas al resto se los compas del hilo, que hemos desviado bastante.
#250 si os puedo dar trabajo significaría que habré dejado de vivir precariamente, que tendría estabilidad. Ojalá os pueda dar trabajo XD
Una pregunta un poco tonta pero no me termina de quedar claro.
Estoy usando un modelo llm en local que para input corto va bien, pero como sea más largo se la va completamente y alucina muchísimo.
Para ello un RAG daría mejores resultados cierto? Pese a que el input no sea excesivamente largo.
#252 entiendo que depende del tamaño de contexto que acepte el modelo. Si es un contexto pequeño te pasaría lo mismo pese a usar RAG. Piensa que el orquestador busca en tu pregunta lo más relevante en el RAG y le pasa esa información junto con tu pregunta al llm, por lo que si el problema es el tamaño de contexto estás en las mismas.
#253 Claro eso es lo que pensaba y no me cuadraba. Aún así, si el RAG "filtra" algo disminuye el input y quizá funcionaría mejor, pero no creo que demasiado.
https://machinelearning.apple.com/research/introducing-apple-foundation-models
https://security.apple.com/blog/private-cloud-compute/
Target diffusion starts with the request metadata, which leaves out any personally identifiable information about the source device or user, and includes only limited contextual data about the request that’s required to enable routing to the appropriate model. This metadata is the only part of the user’s request that is available to load balancers and other data center components running outside of the PCC trust boundary. The metadata also includes a single-use credential, based on RSA Blind Signatures, to authorize valid requests without tying them to a specific user. Additionally, PCC requests go through an OHTTP relay — operated by a third party — which hides the device’s source IP address before the request ever reaches the PCC infrastructure. This prevents an attacker from using an IP address to identify requests or associate them with an individual. It also means that an attacker would have to compromise both the third-party relay and our load balancer to steer traffic based on the source IP address.
Si tu empresa no trabaja asi, no la voy a usar.
