H
Hassan Djirdeh
Guest
Retrieval-Augmented Generation (RAG) systems typically rely on embeddings to find semantically similar information. Embeddings help a system understand that phrases like "company earnings" and "financial results" refer to similar concepts. What they don't do is explicitly recognize that "YogeshGupta" is a person or that "August 31, 2025" is a date. When a query depends on a specific person, organization, product or point in time, that missing structure becomes important.
Named Entity Recognition (NER) is a natural language processing technique that locates named entities in unstructured text and classifies them into categories such as people, organizations, locations, dates and products. In a RAG pipeline, these entity labels become structured metadata that sits alongside embeddings in the search index, enabling more precise filtering, better retrieval for exact names and dates and features like entity-based autocomplete.
In this article, we'll unpack how NER works, why it matters for retrieval quality and how the Progress Agentic RAG solution applies entity detection to our content.
Most organizational knowledge lives in unstructured text. Contracts, earnings reports, support tickets and internal wikis are full of facts written as sentences rather than stored in neat database columns. NER adds structure to that prose by doing two things. It locates each entity mention within the text. It then classifies each mention into a predefined category.
What are common named entities?
Most NER models ship with a standard set of categories:
Consider a sentence you might find in an earnings report:
After NER processes it, the same sentence carries explicit labels:
The text itself hasn't changed. What's new is that the system knows what those words represent, and that knowledge can be stored as metadata alongside the original text and its embedding. NER relies on context to make these classifications: it can determine that "Progress" refers to a company in this sentence, even though the same word can mean forward movement in other contexts.
A typical RAG pipeline splits documents into chunks, converts each chunk into an embedding and stores everything in an index. Semantic search then matches queries against that index by meaning. This works well for conceptual questions, but similarity alone can blur the details. Earnings reports from different companies and quarters all look semantically similar, even though only one contains the fact a user is asking about.
NER adds a second, complementary signal. When entities are detected at ingestion time and stored as index metadata, the RAG system can use them at query time in several ways:
Suppose a knowledge base contains several years of quarterly reports and a user asks, "What did Yogesh Gupta say about AI in the Q3 2025 report?" An embedding-only search will surface passages about executives and AI from multiple quarters. With NER metadata, the system also knows which chunks mention the person "Yogesh Gupta" and the period "Q3 2025," so it can weight or filter results accordingly.
NER doesn't replace embeddings. Embeddings capture the meaning of a whole passage, while NER labels the individual people, companies and dates mentioned inside it. The two signals work best together.
Entity awareness pays off most when the identity of a subject matters as much as the topic itself. Here are the situations where we find it makes the clearest difference.
Questions about a specific organization. If a user asks, "Which contracts mention Acme Corp?", semantic search will happily return contracts involving similar companies in similar industries. An organization filter narrows results to documents where Acme Corp actually appears.
Date-sensitive financial queries. Guidance, pricing and policies change over time. Recognizing "August 31, 2025" as a date prevents the system from blending figures from different reporting periods into one answer.
People lookups. Names carry little semantic content on their own, so embeddings often can't tell two executives apart. A person entity makes "What has Yogesh Gupta said about acquisitions?" resolve to the right speaker.
Similar or ambiguous names. Product names, project code names and short company names frequently collide with ordinary words. Classifying them as entities keeps unrelated passages out of the context sent to the LLM, which directly improves the quality of the generated answer.
One of the more interesting things NER unlocks is the knowledge graph, a structure that represents entities as nodes and the relationships between them as edges. From our example sentence, "Yogesh Gupta" and "Progress Software" become nodes, and a relation extraction step adds an edge—such as "is CEO of"—between them.
When this extraction runs across an entire knowledge base, facts scattered through separate documents connect into a single navigable graph. That makes it possible to answer questions that require following relationships rather than matching one passage.
The Progress Agentic RAG solution runs entity detection automatically as part of ingestion. When we upload a resource to a Knowledge Box, the platform identifies entities across 16 built-in entity types, covering people, organizations, dates, events, locations and more. We can also define our own entity types for domain-specific vocabulary.
For deeper customization, the Graph Extraction agent lets us describe the entities and relationships we care about, along with examples that guide the extraction. A legal team, for instance, might define plaintiffs, defendants, contracts and clauses, so the extracted entities reflect their domain rather than generic categories.
That separation is what raises search precision. With plaintiff and defendant as distinct types, the team can pull only the filings where a given company sat on the defense side, which one generic PERSON or ORGANIZATION label can't express. A compliance team gets the same effect by mapping internal regulation codes and control IDs, so a question about a single control returns the records governed by it instead of anything that reads like policy language.
Named Entity Recognition turns the names, organizations, dates and products buried in unstructured text into structured metadata. In a RAG pipeline, that metadata works alongside embeddings to sharpen filtering and retrieval, power entity-based autocomplete, support anonymization and lay the foundation for knowledge graphs. The Progress Agentic RAG solution handles all of this automatically at ingestion time.
To see entity detection running against your own documents, book a live demo with a Progress AI expert or start a free trial and upload a file to a Knowledge Box.
Keyword extraction surfaces the phrases that best summarize a document's topics, such as "financial results" or "revenue guidance." NER instead finds specific mentions and assigns them to categories, labeling "Yogesh Gupta" as a person and "August 31, 2025" as a date. In short, keywords describe what a document is about, while entities identify who and what it refers to.
No. Embeddings capture the meaning of an entire passage, which is what makes semantic retrieval possible. NER labels the entities inside that passage. A strong RAG pipeline uses embeddings to find related content and entity metadata to filter and rank it when a query depends on an exact name or date.
Yes. Beyond built-in categories, NER systems can be configured to recognize custom entity types. With the Progress Agentic RAG solution, we can define our own entities and relationships for the Graph Extraction agent, with descriptions and examples that help the platform distinguish things like internal project names from ordinary text.
Continue reading...
Named Entity Recognition (NER) is a natural language processing technique that locates named entities in unstructured text and classifies them into categories such as people, organizations, locations, dates and products. In a RAG pipeline, these entity labels become structured metadata that sits alongside embeddings in the search index, enabling more precise filtering, better retrieval for exact names and dates and features like entity-based autocomplete.
In this article, we'll unpack how NER works, why it matters for retrieval quality and how the Progress Agentic RAG solution applies entity detection to our content.
What is Named Entity Recognition?
Most organizational knowledge lives in unstructured text. Contracts, earnings reports, support tickets and internal wikis are full of facts written as sentences rather than stored in neat database columns. NER adds structure to that prose by doing two things. It locates each entity mention within the text. It then classifies each mention into a predefined category.
What are common named entities?
Most NER models ship with a standard set of categories:
- People: Executives, authors, customers and other named individuals.
- Organizations: Companies, government agencies, universities and internal departments.
- Locations: Countries, cities, regions and street addresses.
- Dates and times: "August 31, 2025," "Q3 2025" or "the quarter ended August 31."
- Events: Earnings calls, product launches, conferences and outages.
- Products: Product names, model numbers and SKUs.
- Numerical values: currencies, percentages and quantities.
Consider a sentence you might find in an earnings report:
Yogesh Gupta discussed Progress Software's results for the quarter ended August 31, 2025.After NER processes it, the same sentence carries explicit labels:
[Yogesh Gupta](PERSON) discussed [Progress Software](ORGANIZATION)'s results for the quarter ended [August 31, 2025](DATE).The text itself hasn't changed. What's new is that the system knows what those words represent, and that knowledge can be stored as metadata alongside the original text and its embedding. NER relies on context to make these classifications: it can determine that "Progress" refers to a company in this sentence, even though the same word can mean forward movement in other contexts.
Why Does NER Matter in a RAG Pipeline?
A typical RAG pipeline splits documents into chunks, converts each chunk into an embedding and stores everything in an index. Semantic search then matches queries against that index by meaning. This works well for conceptual questions, but similarity alone can blur the details. Earnings reports from different companies and quarters all look semantically similar, even though only one contains the fact a user is asking about.
NER adds a second, complementary signal. When entities are detected at ingestion time and stored as index metadata, the RAG system can use them at query time in several ways:
| Capability | What it enables |
| Entity filtering | Restrict search to chunks that mention a specific person, company, product or date. |
| Revival precision | Separate documents that are topically similar but concern different entities. |
| Disambiguation | Distinguish "Progress" the organization from "progress" the everyday word. |
| Autocomplete | Suggest known entities from the index as the user types a query. |
Suppose a knowledge base contains several years of quarterly reports and a user asks, "What did Yogesh Gupta say about AI in the Q3 2025 report?" An embedding-only search will surface passages about executives and AI from multiple quarters. With NER metadata, the system also knows which chunks mention the person "Yogesh Gupta" and the period "Q3 2025," so it can weight or filter results accordingly.
NER doesn't replace embeddings. Embeddings capture the meaning of a whole passage, while NER labels the individual people, companies and dates mentioned inside it. The two signals work best together.
How Does NER Provide Better Answers?
Entity awareness pays off most when the identity of a subject matters as much as the topic itself. Here are the situations where we find it makes the clearest difference.
Questions about a specific organization. If a user asks, "Which contracts mention Acme Corp?", semantic search will happily return contracts involving similar companies in similar industries. An organization filter narrows results to documents where Acme Corp actually appears.
Date-sensitive financial queries. Guidance, pricing and policies change over time. Recognizing "August 31, 2025" as a date prevents the system from blending figures from different reporting periods into one answer.
People lookups. Names carry little semantic content on their own, so embeddings often can't tell two executives apart. A person entity makes "What has Yogesh Gupta said about acquisitions?" resolve to the right speaker.
Similar or ambiguous names. Product names, project code names and short company names frequently collide with ordinary words. Classifying them as entities keeps unrelated passages out of the context sent to the LLM, which directly improves the quality of the generated answer.
How NER Helps Auto-Build Knowledge Graphs
One of the more interesting things NER unlocks is the knowledge graph, a structure that represents entities as nodes and the relationships between them as edges. From our example sentence, "Yogesh Gupta" and "Progress Software" become nodes, and a relation extraction step adds an edge—such as "is CEO of"—between them.
When this extraction runs across an entire knowledge base, facts scattered through separate documents connect into a single navigable graph. That makes it possible to answer questions that require following relationships rather than matching one passage.
NER in Progress Agentic RAG
The Progress Agentic RAG solution runs entity detection automatically as part of ingestion. When we upload a resource to a Knowledge Box, the platform identifies entities across 16 built-in entity types, covering people, organizations, dates, events, locations and more. We can also define our own entity types for domain-specific vocabulary.
For deeper customization, the Graph Extraction agent lets us describe the entities and relationships we care about, along with examples that guide the extraction. A legal team, for instance, might define plaintiffs, defendants, contracts and clauses, so the extracted entities reflect their domain rather than generic categories.
That separation is what raises search precision. With plaintiff and defendant as distinct types, the team can pull only the filings where a given company sat on the defense side, which one generic PERSON or ORGANIZATION label can't express. A compliance team gets the same effect by mapping internal regulation codes and control IDs, so a question about a single control returns the records governed by it instead of anything that reads like policy language.
Wrap-Up
Named Entity Recognition turns the names, organizations, dates and products buried in unstructured text into structured metadata. In a RAG pipeline, that metadata works alongside embeddings to sharpen filtering and retrieval, power entity-based autocomplete, support anonymization and lay the foundation for knowledge graphs. The Progress Agentic RAG solution handles all of this automatically at ingestion time.
To see entity detection running against your own documents, book a live demo with a Progress AI expert or start a free trial and upload a file to a Knowledge Box.
FAQs
What is the difference between NER and keyword extraction?
Keyword extraction surfaces the phrases that best summarize a document's topics, such as "financial results" or "revenue guidance." NER instead finds specific mentions and assigns them to categories, labeling "Yogesh Gupta" as a person and "August 31, 2025" as a date. In short, keywords describe what a document is about, while entities identify who and what it refers to.
Does NER replace embeddings in a RAG system?
No. Embeddings capture the meaning of an entire passage, which is what makes semantic retrieval possible. NER labels the entities inside that passage. A strong RAG pipeline uses embeddings to find related content and entity metadata to filter and rank it when a query depends on an exact name or date.
Can NER identify custom, domain-specific entities like product codes or internal project names?
Yes. Beyond built-in categories, NER systems can be configured to recognize custom entity types. With the Progress Agentic RAG solution, we can define our own entities and relationships for the Graph Extraction agent, with descriptions and examples that help the platform distinguish things like internal project names from ordinary text.
Continue reading...