Chapter 8: NED with open LLMs and domain ontologies
The introduction recalls scispaCy’s biomedical role in Chapter 7 and previews Chapter 8’s approach to named entity disambiguation.
After this chapter you will be able to
- scispaCy biomedical specialization. Describe scispaCy as an NLP tool built on spaCy that provides pretrained biomedical models for processing documents and publications.
- Context dependent Zika disambiguation. Explain how the Zika examples illustrate scispaCy’s reliance on surrounding words, and why the section identifies unused relationships and paths in the knowledge base as a limitation.
- SNOMED ingestion inputs and outputs. Describe how the example uses SNOMED files to create entities and relationships in Neo4j and add entity names and aliases.
- Hierarchical semantic type propagation. Explain how SNOMED’s hierarchical connections let semantic types from first-level nodes reach deeper nodes.
- Local NED model deployment. Explain why the NED system runs Llama 3.1 8B locally with Ollama, and describe the setup sequence at the level given here: install Ollama, then download and deploy the model.
- OpenAI-compatible Python access. Explain how Ollama's compatibility with the OpenAI Chat Completions API lets Python code interact with the locally deployed model and simplifies its integration into the NED system.
- Entity recognition and candidate selection. Trace how the workflow turns an input document into labeled biomedical mentions and then generates possible ontology matches for each mention.
- Ontology-guided candidate disambiguation. Explain how the final stage uses the LLM and ontology structure to choose a precise match from the candidates.
- Ontology guided entity recognition. Explain how the NER stage uses categories retrieved from SNOMED to identify and classify medical entities in unstructured text.
- Candidate selection inputs and outputs. Describe how candidate selection takes mentions annotated by NER and a domain ontology, then returns one or more possible entities for each mention. Explain that these are possible interpretations, not yet the final disambiguated meaning.
- Ontology based full-text retrieval. Explain why this step uses Neo4j full-text search instead of an LLM to retrieve candidates: it searches the ontology directly, and the ontology is too large to load entirely into a prompt.
- Co-occurring entities as context. Explain how other medical entities in a sentence help resolve an ambiguous mention by connecting candidate meanings to knowledge in the domain ontology.
- Ontology shortest-path search. Describe how the system finds short ontology connections between candidates for different mentions and filters out highly connected hubs.
- Final SNOMED concept selection. Trace how the final LLM step uses the original sentence, candidate entities, and summarized context to select a SNOMED concept for each mention.
- Ontology and LLM combination. Explain why the chapter combines a domain ontology such as SNOMED with an open, general-purpose LLM such as Llama 3.1 8B for biomedical named entity disambiguation.
What it builds on
- (chapter intro) (chapter 7) · The preceding chapter’s focus on named entity disambiguation and scispaCy.
- Domain-based NED and LLMs (chapter 7) · The earlier discussion of domain-based NED and LLMs.
- Understanding named entity disambiguation (chapter 7) · The distinction between a mention in text and its disambiguated entity.
- Domain ontologies (chapter 7) · The SNOMED files introduced earlier.
- Processing, loading, and mapping ontologies (chapter 7) · Earlier ontology processing and mapping details.
Section by section
Introduction
The introduction recalls scispaCy’s biomedical role in Chapter 7 and previews Chapter 8’s approach to named entity disambiguation.
- scispaCy biomedical specialization: Describe scispaCy as an NLP tool built on spaCy that provides pretrained biomedical models for processing documents and publications.
Why it matters: This identifies the biomedical tool the introduction carries forward from the preceding chapter.
Key terms: scispaCy, spaCy, pretrained models, biomedical domain
8.1 Understanding limitations of traditional NED systems
The section explains why scispaCy’s biomedical entity disambiguation is limited, using a Zika example to show its dependence on surrounding words.
- Biomedical reference knowledge limits: Explain that scispaCy uses vocabularies and ontologies such as UMLS to identify canonical entities, but is designed for the biomedical domain and faces challenges when its reference knowledge base needs new entities or terms.
Why it matters: This explains why a biomedical disambiguation tool may be hard to adapt as a domain or its terminology changes. - Context dependent Zika disambiguation: Explain how the Zika examples illustrate scispaCy’s reliance on surrounding words, and why the section identifies unused relationships and paths in the knowledge base as a limitation.
Why it matters: The missed mention makes the cost of relying on surrounding words concrete.
Key terms: scispaCy, UMLS, canonical entities, reference knowledge base, contextual words, relationships and paths, disambiguation, Zika Virus Infection
8.2 Ingesting the domain ontology
The section describes how SNOMED is ingested into Neo4j and how its hierarchy supplies semantic types for disambiguation.
- SNOMED ingestion inputs and outputs: Describe how the example uses SNOMED files to create entities and relationships in Neo4j and add entity names and aliases.
Why it matters: These inputs give the disambiguation process ontology entities and the names used to refer to them. - Hierarchical semantic type propagation: Explain how SNOMED’s hierarchical connections let semantic types from first-level nodes reach deeper nodes.
Why it matters: This gives deeper ontology concepts semantic categories that can help drive disambiguation.
Key terms: SNOMED, Neo4j, names and aliases, relationships, SNOMED_IS_A, semantic types, first-level nodes, hierarchical structure
8.3 Setting up the model with Ollama and Llama 3.1 8B
This section explains why the NED system uses a locally deployed Llama 3.1 8B model and how Ollama makes that model accessible from Python.
- Local NED model deployment: Explain why the NED system runs Llama 3.1 8B locally with Ollama, and describe the setup sequence at the level given here: install Ollama, then download and deploy the model.
Why it matters: The local setup is the foundation for using the model in this NED system without relying on a hosted provider. - OpenAI-compatible Python access: Explain how Ollama's compatibility with the OpenAI Chat Completions API lets Python code interact with the locally deployed model and simplifies its integration into the NED system.
Why it matters: API compatibility makes the locally running model easier to use in the NED system's Python code.
Key terms: Ollama, Llama 3.1 8B, NED system, OpenAI Chat Completions API, Python
8.4 End-to-end NED process
This section traces an ontology-guided NED workflow from unstructured biomedical text to disambiguated entity matches.
- Entity recognition and candidate selection: Trace how the workflow turns an input document into labeled biomedical mentions and then generates possible ontology matches for each mention.
Why it matters: Separating recognition from candidate selection makes clear why finding a term is not yet the same as identifying its exact ontology entity. - Ontology-guided candidate disambiguation: Explain how the final stage uses the LLM and ontology structure to choose a precise match from the candidates.
Why it matters: Ontology relationships provide context for choosing among plausible matches when a term has multiple meanings or associations.
Key terms: named entity recognition (NER), candidate selection (CS), full-text search, domain ontology, candidate disambiguation (CD), shortest path, ontology structure, disambiguated entity
8.4.1 Named entity recognition
This section shows how to use SNOMED categories in an LLM prompt to recognize medical entities, then add mention positions in post-processing.
- Ontology guided entity recognition: Explain how the NER stage uses categories retrieved from SNOMED to identify and classify medical entities in unstructured text.
Why it matters: The ontology gives the recognition task a defined medical scope rather than leaving the LLM to choose categories freely. - Structured recognition output: Describe what the NER prompt asks the LLM to return for each sentence and identified entity.
Why it matters: The structured output makes clear which text was recognized and how each mention was classified. - Mention position post-processing: Explain why and how the section adds start and end character positions to recognized mentions.
Why it matters: Post-processing supplies mention positions without relying on the LLM to count characters accurately.
Key terms: NER, SNOMED, predefined categories, prompt engineering, sentence, entities, ID, mention, label, JSON
8.4.2 Candidate selection
This section explains how candidate selection maps NER-detected mentions to possible concepts in a domain ontology using type-filtered full-text search.
- Candidate selection inputs and outputs: Describe how candidate selection takes mentions annotated by NER and a domain ontology, then returns one or more possible entities for each mention. Explain that these are possible interpretations, not yet the final disambiguated meaning.
Why it matters: It separates finding plausible meanings from deciding which meaning the text intends. - Ontology based full-text retrieval: Explain why this step uses Neo4j full-text search instead of an LLM to retrieve candidates: it searches the ontology directly, and the ontology is too large to load entirely into a prompt.
Why it matters: The retrieval method keeps candidate meanings grounded in the ontology without requiring it all in an LLM prompt. - NER label search filtering: Explain how the query uses labels from NER output to narrow candidate retrieval to ontology entities relevant to the mentioned entity type.
Why it matters: Type filtering keeps the candidate search focused on relevant ontology entities.
Key terms: CS, NER, mentions, domain ontology, candidates, SNOMED, Neo4j, full-text search, LLM, $labels
8.4.3 Candidate disambiguation
This section explains how candidate disambiguation uses ontology connections and an LLM to select the best SNOMED concept for each entity mention.
- Co-occurring entities as context: Explain how other medical entities in a sentence help resolve an ambiguous mention by connecting candidate meanings to knowledge in the domain ontology.
Why it matters: A mention’s neighbors in the sentence can provide evidence that its name alone cannot. - Ontology shortest-path search: Describe how the system finds short ontology connections between candidates for different mentions and filters out highly connected hubs.
Why it matters: Short, less generic ontology connections provide usable evidence for comparing candidates. - Graph paths as sentences: Explain why and how detected ontology paths are translated into natural-language sentences.
Why it matters: The translation makes graph relationships usable as textual context for the LLM. - Condensed relational context: Explain why translated path sentences are summarized before final disambiguation and what the summary must preserve.
Why it matters: A concise summary keeps the evidence available without burying the decision in path details. - Final SNOMED concept selection: Trace how the final LLM step uses the original sentence, candidate entities, and summarized context to select a SNOMED concept for each mention.
Why it matters: This is where the collected context becomes a specific, identified ontology concept.
Key terms: CD, co-occurring, domain ontology, candidate entities, shortest paths, Neo4j Graph Data Science (GDS), degree, hub nodes, translating paths to text, graph paths
8.5 Conclusions
The section concludes that combining domain ontologies, graph search, and open LLMs supports named entity disambiguation in complex domain texts.
- Ontology and LLM combination: Explain why the chapter combines a domain ontology such as SNOMED with an open, general-purpose LLM such as Llama 3.1 8B for biomedical named entity disambiguation.
Why it matters: The conclusion ties the chapter’s components to the problem they are meant to solve. - Graph search and disambiguation: Describe the roles attributed to Neo4j GDS shortest-path detection, full-text search, and LLM disambiguation in the combined system.
Why it matters: It distinguishes the graph and search capabilities from the LLM’s disambiguation role. - Relational paths in natural language: Explain why path-to-text translation and textual path summarization are used when an LLM must distinguish similar entities.
Why it matters: It explains why relational graph information is presented to the LLM as text.
Key terms: NED, domain ontologies, SNOMED, open and general-purpose LLMs, Llama 3.1 8B, scispaCy, Neo4j’s GDS library, shortest-path detection, full-text search, disambiguation
8.6 Summary
Concepts explained in this chapter
- candidate disambiguationCandidate disambiguation is the phase of named entity disambiguation that uses contextual and ontology-based evidence to select the intended entity from candidate entities.
- path-to-text translationPath-to-text translation is the conversion of a graph path and its relationships into a natural-language textual representation.
- textual path summarizationTextual path summarization is the condensation of a graph path’s relationships and entities into a concise natural-language description.
- shortest-path detectionShortest-path detection is the computation of minimum-cost routes between nodes in a graph.
- disambiguationNamed entity disambiguation is the technique of determining which real-world entity a mention in text refers to and linking it to the correct knowledge-base entity.
- ontologyAn ontology is a formal model of concepts, relationships, and constraints in a domain that supports shared interpretation and inference.
- language modelA large language model is a neural language model trained on very large text corpora to understand and generate natural-language content.
- SNOMEDSNOMEDCT_US is the US edition of SNOMED CT, a multilingual clinical terminology and ontology containing standardized biomedical concepts and relationships.
- named entity recognitionNamed entity recognition is the natural-language-processing technique of identifying mentions of named entities in text and assigning them to predefined categories.
- candidate selectionCandidate selection is the phase of entity disambiguation that identifies possible reference entities for a recognized mention.
- scispaCyscispaCy is a Python library providing natural-language-processing models and pipelines specialized for scientific and biomedical text.
- semantic typeA semantic type is a category that specifies the kind of entity represented by an ontology node, such as a disease, body structure, substance, or event.
- node degreeNode degree is the number of edges incident to a node, optionally separated by incoming and outgoing direction.
← Chapter 7: Named entity disambiguation
Chapter 9: Machine learning on knowledge graphs: A primer approach →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.