Mesa de la izquierda 
 
 
 
 
 
 Abstract and Introduction 
 
 
 
 
 
 
 
 
 
 System Architecture 2.1  Access via UI or HTTP 2.1.1  GUI 2.2  Input 2.3  Natural Language Processing Pipeline — The Llettuce API 2.3.1  Vector search 2.3.2  LLM 2.3.3  Concept Matches 2.4  Output 
 
 
 
 
 
 
 
 
 Case Study: Medication Dataset 3.1  Data Description 3.2  Experimental Design 3.3  Results 3.3.1  Comparison between vector search and Usagi 3.3.2  Comparison with GPT-3 3.4  Conclusions & Acknowledgement 3.5  References 2 Arquitectura del sistema Llettuce fue escrito usando Python para un back-end y una interfaz de usuario. El back-end incluye un almacén de vectores para la búsqueda semántica, un LLM local para sugerir mappings, y consultas a una base de datos OMOP CDM conectada para proporcionar los detalles de un mapping sugerido al usuario. 2.1 Acceso a través de UI o HTTP Todas las interacciones con Llettuce se realizan a través de solicitudes HTTP a la API de Llettuce. Se realiza una solicitud POST al servidor de Llettuce que contiene JSON con el siguiente formato: Las opciones de tubería son opcionales, por lo que una solicitud puede ser sólo una lista de nombres informales. 2.1.1 GUI Para los usuarios menos cómodos con la línea de comandos, se proporciona una interfaz gráfica de usuario (GUI). Esto se construye utilizando el marco de Streamlit (Streamlit, 2024) Python, y presenta al usuario con dos opciones. La primera muestra una caja de texto donde un usuario puede escribir una lista separada por comas de nombres informales para ejecutarse a través de la tubería. La segunda permite a un usuario subir un archivo .csv y elegir una columna que contenga nombres para ejecutarse a través de la tubería. Para ambas opciones, los resultados de la tubería se muestran debajo de la entrada. 2.2 Ingresos Llettuce utiliza FastAPI (Ramírez, 2024) para servir puntos finales de API. Estos puntos finales permiten que diferentes combinaciones de módulos Llettuce se utilicen para encontrar nombres de conceptos. 2.3 Natural Language Processing Pipeline - La API de Llettuce 2.3.1 Vector search Los LLM son buenos generalistas para la generación de texto. Sin embargo, el OMOP CDM tiene un vocabulario especializado. Para hacer frente a esta brecha, Llettuce utiliza embeddings de conceptos OMOP para la búsqueda semántica. Se ha demostrado que los transformadores sólo codificadores producen representaciones del lenguaje de tal manera que los conceptos semánticamente relacionados están cerca en el espacio de sus embeddings (Bengio et al., 2003; Devlin et al., 2019). Llettuce utiliza embeddings de sentencia (Reimers & Gurevych, 2019) para generar embeddings para conceptos. Estos se almacenan localmente en una base de datos vectorial. FastEmbed (‘Qdrant/Fembasted’, 2023, 14 de julio/El concepto embedded se compara con los vectores Las primeras incorporaciones k se utilizan para la generación aumentada por la recuperación (RAG) (Lewis et.al., 2021). En el modo RAG, la tubería primero consulta la base de datos vectorial. Se ha establecido un umbral sobre la similitud de las incorporaciones de tal manera que las incorporaciones por encima de esto son coincidencias exactas. Si hay una incorporación con una puntuación por encima de este umbral, estas se proporcionan al usuario. Si no hay una coincidencia muy cercana, las incorporaciones se insertan en un prompt, que sirve como entrada al LLM, como se discute a continuación. La razón es que las incorporaciones cerradas pueden contener la respuesta, que el LLM puede seleccionar, o señales sobre lo que podría estar cerca de la respuesta correcta. 2.3.2 LLM Llettuce utiliza Llama.cpp (Gerganov et al., 2024) para ejecutar el último Llama LLM de Meta (Dubey et al., 2024). Llama.cpp proporciona una API para ejecutar la inferencia de transformadores. Detecta el hardware disponible y utiliza optimizaciones para la inferencia eficiente que se ejecuta en unidades centrales de procesamiento (CPU). La versión de Llama probada en nuestro estudio de caso tiene 8 mil millones de parámetros (Llama 3.1 8B). Los modelos se entrenan con cada parámetro como un número de punto flotante de 32 bits. Se empleó la cuantización para reducir el tamaño del modelo, con poca pérdida de precisión (Dettmers & Zettlemoyer, 2023; Jacob et al., 2017). La completa precisión de Llama 3.1 8B requiere más de 32 Gb de RAM para funcionar, mientras que el modelo cuantizado de 4 bits requiere menos de 5 Gb. Llettuce utiliza Haystack (deepset GmbH, 2024) para orquestar sus tuberías LLM. Para las tuberías LLM-sólo hay un componente que toma un nombre informal e inserta en una plantilla de prompt, y otro que entrega esta prompt a la LLM. La prompt utilizada en estos casos utiliza técnicas recomendadas para los modelos Llama (‘Meta-Llama/Llama-Recipes’, 2023, 17/2024). Por ejemplo, el prompt para RAG contiene instrucciones detalladas y explícitas. You are an assistant that suggests formal RxNorm names for a medication. You will be given the name of a medication, along with some possibly related RxNorm terms. If you do not think these terms are related, ignore them when making your suggestion. Respond only with the formal name of the medication, without any extra explanation. Esta parte de la solicitud también da al LLM un papel, que ha demostrado mejorar la coherencia en las respuestas(Kong et al., 2024). Importante, la solicitud incluye proporcionar ejemplos de pares de nombres informales / formales, una táctica efectiva para la solicitud de LLM (Brown et al., 2020): Una vez que el LLM ha inferido un nombre formal para el nombre informal proporcionado, este nombre formal se utiliza como un nombre conceptual en una consulta OMOP CDM parametrizada. 2.3.3 Concept Matches Para obtener los detalles de cualquier concepto a través de un tubo Llettuce, se consulta una base de datos OMOP CDM. Las consultas OMOP CDM se generan utilizando un mapping objet-relational a través de SQLAlchemy (Bayer, 2012). La cadena utilizada para el campo de nombre de concepto se preprocede primero mediante la eliminación de puntuación y palabras de parada y la división de las palabras con el caracter de tubo para la compatibilidad con la búsqueda de texto PostgreSQL en la base de datos. Por ejemplo, la cadena “paracetamol y cafeína” tiene la palabra de parada “y” eliminada, y las 196 palabras restantes utilizadas para construir la cadena “paracetamol, caffeine”. Las palabras de este término de búsqueda se utilizan para una búsqueda de texto contra los nombres de conceptos de 2.4 Producción Las tuberías de Llettuce emiten JSON que contiene los resultados de la tubería. Por ejemplo, para una tubería que ejecuta la consulta LLM y OMOP, una solicitud de entrada es la siguiente: {"nombres": ["Aplicación Betnovate Scalp"] Devuelve la salida JSON para los “eventos” llm_output y omop_output para cada nombre enviado a Llettuce. El llm_output contiene una respuesta de la respuesta del LLM, el nombre informal suministrado en la solicitud y metadatos descriptivos sobre la ejecución del LLM. El evento omop_output contiene el search_term enviado al OMOP-CDM, luego un array CONCEPT, donde cada elemento es un encuentro que cumple el umbral establecido en la combinación de cuerdas fuzzy. Cada elemento describe el concept_name, concept_id, vocabulary_id, y concept_code de la tabla de concept de OMOP-CDM, seguido del concept_name_similarity_score calculado en Llettuce. Llettuce también tiene la opción de obtener información adicional del OMOP-CDM, no habilitado en la configuración predeterminada, que se incluye en la entrada para cada concepto. La interfaz gráfica analiza esto y lo muestra en un formato más fácil de usar. 
 
 
 
 
 
 
 
 
 
 
 
 
 Los autores: (1) James Mitchell-White, Centro de Informática de la Salud, Escuela de Medicina, La Universidad de Nottingham, Servicio de Investigación Digital, La Universidad de Nottingham, y NIHR Nottingham Centro de Investigación Biomédica; (2) Reza Omdivar, Servicio de Investigación Digital, Universidad de Nottingham, y NIHR Nottingham Centro de Investigación Biomédica; (3) Esmond Urwin, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham y NIHR Nottingham Centro de Investigación Biomédica; (4) Karthikeyan Sivakumar, Servicio de Investigación Digital, Universidad de Nottingham; (5) Ruizhe Li, NIHR Centro de Investigación Biomédica de Nottingham y Escuela de Ciencias de la Computación, Universidad de Nottingham; (6) Andy Rae, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham; (7) Xiaoyan Wang, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur; (8) Theresia Mina, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur; (9) John Chambers, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur y Departamento de Epidemiología y Biostadística, Escuela de Salud Pública, Imperial College London, Reino Unido; (10) Grazziela Figueredo, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham y NIHR Centro de Investigación Biomédica de Nottingham; Philip R Quinlan, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham. Authors: (1) James Mitchell-White, Centro de Informática de la Salud, Escuela de Medicina, La Universidad de Nottingham, Servicio de Investigación Digital, La Universidad de Nottingham, y NIHR Nottingham Centro de Investigación Biomédica; (2) Reza Omdivar, Servicio de Investigación Digital, Universidad de Nottingham, y NIHR Nottingham Centro de Investigación Biomédica; (3) Esmond Urwin, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham y NIHR Nottingham Centro de Investigación Biomédica; (4) Karthikeyan Sivakumar, Servicio de Investigación Digital, Universidad de Nottingham; (5) Ruizhe Li, NIHR Centro de Investigación Biomédica de Nottingham y Escuela de Ciencias de la Computación, Universidad de Nottingham; (6) Andy Rae, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham; (7) Xiaoyan Wang, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur; (8) Theresia Mina, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur; (9) John Chambers, Lee Kong Chian School of Medicine, Universidad Tecnológica de Nanyang, Singapur y Departamento de Epidemiología y Biostadística, Escuela de Salud Pública, Imperial College London, Reino Unido; (10) Grazziela Figueredo, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham y NIHR Centro de Investigación Biomédica de Nottingham; Philip R Quinlan, Centro de Informática de la Salud, Escuela de Medicina, Universidad de Nottingham. 
 
 Este artículo está disponible en archivo bajo la licencia CC BY 4.0. Este artículo está disponible en archivo bajo la licencia CC BY 4.0.

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

EScholar Technologies

EScholar

Este audio es producido en el idioma original de la historia!

Llettuce: La herramienta de IA para mapear registros médicos de Messy a código estándar

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

El modelo Bitcoin UTXO, impulsando un ecosistema único

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

El modelo Bitcoin UTXO, impulsando un ecosistema único

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps