tavolo di sinistra 
 
 
 
 
 
 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 Architettura del sistema Llettuce è stato scritto utilizzando Python sia per un back-end che per un'interfaccia utente. Il back-end comprende un magazzino vettoriale per la ricerca semantica, un LLM locale per suggerire mappings e query a un database OMOP CDM collegato per fornire agli utenti i dettagli di una mapping proposta. 2.1 Accesso tramite UI o HTTP Tutte le interazioni con Llettuce vengono effettuate tramite richieste HTTP all'API Llettuce. Una richiesta POST viene effettuata al server Llettuce contenente JSON con il seguente formato: Le opzioni di pipeline sono opzionali, quindi una richiesta può essere solo un elenco di nomi informali. 2.1.1 GUI Per gli utenti meno a proprio agio con la riga di comando, viene fornita un'interfaccia utente grafica (GUI). Questo è costruito utilizzando il framework Streamlit (Streamlit, 2024) Python, e presenta all'utente due opzioni. Il primo mostra una casella di testo in cui un utente può digitare un elenco separato da comma di nomi informali da eseguire attraverso il pipeline. Il secondo consente all'utente di caricare un file .csv e scegliere una colonna contenente nomi da eseguire attraverso il pipeline. Per entrambe le opzioni, i risultati del pipeline sono mostrati sotto l'ingresso. 2.2 Ingresso Llettuce utilizza FastAPI (Ramírez, 2024) per servire i terminali API. Questi terminali consentono di utilizzare diverse combinazioni di moduli Llettuce per trovare i nomi dei concetti. 2.3 Natural Language Processing Pipeline – Llettuce API 2.3.1 Vector search I LLM sono buoni generalizzatori per la generazione di testo. Tuttavia, il OMOP CDM ha un vocabolario specializzato. Per colmare questo divario, Llettuce utilizza gli embeddings dei concetti OMOP per la ricerca semantica. È stato dimostrato che i trasformatori solo codificanti producono rappresentazioni del linguaggio in modo che i concetti semanticamente correlati siano vicini nello spazio dei loro embeddings (Bengio et al., 2003; Devlin et al., 2019). Llettuce utilizza gli embeddings di frase (Reimers & Gurevych, 2019) per generare gli embeddings per i concetti. Questi sono memorizzati localmente in un database vettoriale. FastEmbed (‘Qdrant/Fembasted’, 2023, 14 luglio/Il concetto incorporato è confrontato I primi embeddings k sono utilizzati per la generazione aumentata da rilevamento (RAG) (Lewis et.al., 2021). In modalità RAG, il pipeline prima interrogherà il database vettoriale. Una soglia sulla somiglianza degli embeddings è stata impostata in modo che gli embeddings sopra questi siano esatti. Se c'è un embedding con un punteggio al di sopra di questo limite, questi vengono forniti all'utente. Se non c'è una corrispondenza molto stretta, gli embeddings vengono inseriti in un prompt, che serve come input al LLM, come discusso di seguito. La ragione è che gli embeddings chiusi possono contenere la risposta, che il LLM può selezionare, o suggerimenti su ciò che potrebbe essere vicino alla risposta giusta. 2.3.2 LLM Llettuce utilizza Llama.cpp (Gerganov et al., 2024) per eseguire l'ultimo Llama LLM da Meta (Dubey et al., 2024). Llama.cpp fornisce un'API per eseguire la inferenza del trasformatore. Rileva l'hardware disponibile e utilizza ottimizzazioni per l'efficiente inferenza in esecuzione su unità di elaborazione centrali (CPU). La versione di Llama testata nel nostro studio di caso ha 8 miliardi di parametri (Llama 3.1 8B). I modelli sono addestrati con ogni parametro come numero di punto galleggiante a 32 bit. La quantitazione è stata impiegata per ridurre la dimensione del modello, con poca perdita di precisione (Dettmers & Zettlemoyer, 2023; Jacob et al., 2017). La piena precisione Llama 3.1 8B richiede oltre 32 Gb di RAM per funzionare, mentre il modello quantificato a 4 bit richiede meno di 5 Gb. La maggior parte dei computer portatili di consumo sono quindi in grado di mantenere il modello nella memoria Llettuce utilizza Haystack (deepset GmbH, 2024) per orchestrare i suoi gasdotti LLM. Per i gasdotti LLM-only c'è un componente che prende un nome informale e lo inserisce in un modello di prompt, e un altro che consegna questo prompt al LLM. Il prompt utilizzato in questi casi utilizza tecniche raccomandate per i modelli Llama (‘Meta-Llama/Llama-Recipes’, 2023, 17 luglio/2024). Ad esempio, il prompt per RAG contiene istruzioni dettagliate ed esplicite 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. Questa parte del prompt dà anche al LLM un ruolo, che ha dimostrato di migliorare la coerenza nelle risposte(Kong et al., 2024). Importante, il prompt include la fornitura di esempi di coppie di nomi informali / formali, una tattica efficace per promuovere il LLM (Brown et al., 2020): Una volta che il LLM ha dedotto un nome formale per il nome informale fornito, questo nome formale viene utilizzato come nome concettuale in una query OMOP CDM parametrizzata. 2.3.3 Concept Matches Per recuperare i dettagli di qualsiasi concetto attraverso un pipeline Llettuce, viene richiesto un database OMOP CDM. Le query OMOP CDM vengono generate utilizzando una mappatura oggetto-relazionale tramite SQLAlchemy (Bayer, 2012). La stringa utilizzata per il campo nome concetto viene prima preprocessata rimuovendo la puntuazione e le parole di interruzione e suddividendo le parole con il carattere del tubo per la compatibilità con la ricerca di testo PostgreSQL nel database. Ad esempio, la stringa “paracetamol e caffeina” ha il termine stop-word “e” rimosso, e le restanti 196 parole utilizzate per costruire la stringa “paracetamol, caffeina”. Le parole di questo termine di ricerca vengono utilizzate per una query di testo contro i nomi dei concetti dei 2.4 Produzione I pipeline di Llettuce emettono JSON contenenti i risultati del pipeline. Ad esempio, per un pipeline che esegue la query LLM e OMOP, una richiesta di input è la seguente: {"nomi": ["Applicazione Betnovate Scalp"] restituisce l'uscita JSON per gli "eventi" llm_output e omop_output per ogni nome inviato a Llettuce. Il llm_output contiene una risposta della risposta del LLM, il nome informale fornito nella richiesta e metadati che descrivono l'esecuzione del LLM. L'evento omop_output contiene il search_term inviato al OMOP-CDM, quindi un array CONCEPT, in cui ogni elemento è un match che soddisfa la soglia impostata sulla corrispondenza di string fuzzy. Ogni elemento descrive il concept_name, concept_id, vocabulary_id e concept_code dalla tabella di concetto di OMOP-CDM, seguito dal concept_name_similarity_score calcolato in Llettuce. Llettuce ha anche la possibilità di recuperare ulteriori informazioni dal OMOP-CDM, non abilitato nella configurazione predefinita, che è incluso nell'entrata per ogni concetto. La GUI analizza questo e lo visualizza in un formato più user-friendly. 
 
 
 
 
 
 
 
 
 
 
 
 
 Gli autori : (1) James Mitchell-White, Centro per l'informatica sanitaria, Scuola di Medicina, L'Università di Nottingham, Servizio di ricerca digitale, L'Università di Nottingham, e NIHR Nottingham Biomedical Research Centre; (2) Reza Omdivar, Digital Research Service, Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (3) Esmond Urwin, Centro per l'informatica sanitaria, Scuola di Medicina, L'Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (4) Karthikeyan Sivakumar, Digital Research Service, Università di Nottingham; Ruizhe Li, NIHR Nottingham Biomedical Research Centre e Scuola di Informatica, Università di Nottingham; (6) Andy Rae, Centro per l'informatica sanitaria, Scuola di Medicina, Università di Nottingham; (7) Xiaoyan Wang, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore; (8) Theresia Mina, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore; (9) John Chambers, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore e Dipartimento di Epidemiologia e Biostatistica, Scuola di Salute Pubblica, Imperial College London, Regno Unito; (10) Grazziela Figueredo, Centro per l'Informatica Sanitaria, Scuola di Medicina, Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (11) Philip R Quinlan, Centro per l'informatica sanitaria, Scuola di Medicina, Università di Nottingham. Authors: (1) James Mitchell-White, Centro per l'informatica sanitaria, Scuola di Medicina, L'Università di Nottingham, Servizio di ricerca digitale, L'Università di Nottingham, e NIHR Nottingham Biomedical Research Centre; (2) Reza Omdivar, Digital Research Service, Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (3) Esmond Urwin, Centro per l'informatica sanitaria, Scuola di Medicina, L'Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (4) Karthikeyan Sivakumar, Digital Research Service, Università di Nottingham; Ruizhe Li, NIHR Nottingham Biomedical Research Centre e Scuola di Informatica, Università di Nottingham; (6) Andy Rae, Centro per l'informatica sanitaria, Scuola di Medicina, Università di Nottingham; (7) Xiaoyan Wang, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore; (8) Theresia Mina, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore; (9) John Chambers, Lee Kong Chian School of Medicine, Nanyang Technological University, Singapore e Dipartimento di Epidemiologia e Biostatistica, Scuola di Salute Pubblica, Imperial College London, Regno Unito; (10) Grazziela Figueredo, Centro per l'Informatica Sanitaria, Scuola di Medicina, Università di Nottingham e NIHR Nottingham Biomedical Research Centre; (11) Philip R Quinlan, Centro per l'informatica sanitaria, Scuola di Medicina, Università di Nottingham. 
 
 Questo documento è disponibile su archiv sotto la licenza CC BY 4.0. Questo documento è disponibile su archiv sotto la licenza CC BY 4.0.

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

EScholar Technologies

EScholar

Questo audio è prodotto nella lingua originale della storia!

Llettuce: lo strumento AI per mappare i record medici di Messy al codice standard

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

I Built an AI Copilot That Thinks in Exploits, Not Prompts

HackerNoon - A User Experience Analysis: Part 2

How to Mint Your Name.HackerNoon Web3 Identity Namespace

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

I Built an AI Copilot That Thinks in Exploits, Not Prompts

HackerNoon - A User Experience Analysis: Part 2

How to Mint Your Name.HackerNoon Web3 Identity Namespace

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps