Plain text wins again: A story of the web, RDF, and LLMs

I agree with this almost entirely, and then perhaps some. Plain text notes as markdown files are easy to keep up to date, along with PlantUML diagrams. VS Code plugins make that easy, and this information is easy to copy over to GitHub, etc. More recently, though, I’ve been looking at markup, because it really seems like if Generative AI has an appropriate use, it’s as part of a publishing toolchain to add alt text and microdata/rdf-a attributes. I guess the good, the bad, and the ugly reality of markdown is the absence of namespaces.

I started my professional career working for a typesetter, many, many years ago, and inline markup, which had itself emerged from editors marking up authors' manuscripts, has been a hallmark of describing simple narrative structural intent for a long time. RDF can be evoked in a similar pattern: USING <http://example.com/sample> as default, ~> HTML [ a text format; a markup language; evolved into ~> Markdown [ a Text Format; a markup language; a compact language; understood by (humans, machines)]]. which can be translated into a more canonical representation (Turtle): PREFIX default <http://example.com/sample> :HTML a :TextFormat; a :MarkupLanguage; :evolvedInto :Markdown . :Markdown a :TextFormat; a :MarkupLanguage; a :CompactLanguage; :understoodBy (:humans, :machines) . RDF is a language of concepts, not tokens. If there was a consistent way of naming anonymous nodes (blank nodes associated with bracket notation and other similiar declarations in Turtle) then the first example can be seen as RDF within a default namespace. Once you get used to the odd symbology, which can also be rendered textually: ---- There is a thing called HTML, which is a text format; a markup language; that evolved into a thing called Markdown, which is a Text Format, a markup language, a compact language; which is understood by a list of humans and machines. ---- then you can see how the one elides into the other. RDF as text does require some thinking about what you're saying, and there are specific grammatical constructs in English and other languages which likely require additional syntax, but I think that we hamper ourselves when we say RDF must use IRIs. Conversation is generally local, meaning that the we should be thinking about such identifiers as: when I make an assertion about a given entity's class (x is a X), I can do so without specifically having to reference a definition immediately, so long as at some point you and I can agree that any concepts we declare in conversation we will ultimately resolve to a common set of definitions. You can think of this as late binding for classes. This is one reason I like SHACL. It's a great language for late binding of concepts to conceptual definitions, and it's simple enough that it can be automated while sufficiently robust to handle nuance.

couldn't agree more. worth reading: "The web taught us that linked plain text could scale to the world. The semantic web taught us how to describe that world formally. LLMs bring the narrative power. The future lies in fusing them - a web where every sentence can be both read and reasoned with."

Yes! Especially that RDF in Turtle .ttl syntax or .n3 , .nt , .nq (N-Quads!) are almost as easy as .csv , .yaml, .json for adoption! And enable so much power with OWL, SHACLs and rest of ecosystem! https://lnkd.in/eENCS5Fr) https://lnkd.in/eB6rQ3CQ

Do you know why and when LLMs decide to look things up with Web search? Large language models know a lot, but that knowledge is frozen at training time and updates require a model update. They can sound confident while being out of date. Retrieval-Augmented Generation (RAG) explains how and why a model decides to look things up rather than rely only on memory. Here are the 5 key steps: 1) Retrieval Triggered: It is partly about confidence thresholds but also about rules and context. Systems retrieve for time-sensitive topics, current events, technical specifications, or when the user signals a need for freshness. Even if the model could answer from memory, it searches when recency, stakes, or reliability require it. 2) Web-Scale Retrieval: Your question becomes both a semantic vector and a standard web query. The model calls an external search API such as Google or Bing and receives about 8 to 12 results with titles, URLs, and excerpts. It brings in coherent sections from those pages, enough to stay readable but compact enough to fit within a few thousand words of active context. 3) The model re-scores those passages for answer-likelihood: topical completeness, clarity, specificity, and source authority. This is where I have coined the term LanguageRank. In practice, a retrieval-augmented model typically ingests a few thousand to about twenty thousand words of candidate text at this stage, roughly 8–12 web passages, each 500–2,000 words long. These passages are selected and scored using vectorized representations, then the actual text is loaded into the model’s active context window, which for most production-scale systems ranges from 16 k to 200 k tokens (around 12 k to 150 k words). It operates by weighting fragments not just for factual content but for fit : how well their linguistic form, precision, and framing align with the user’s query and prior dialogue. Over time, within a conversation, this becomes personal as the system learns your context and reasoning style. 4) Grounding While Writing: As the model composes its response, it tracks which retrieved passages each clause depends on, creating an internal map linking claims to sources. 5) Citation as Attribution: A citation appears when the search adds information the model uses in its answer, not when it merely confirms what it already knew. The line is between information newly retrieved and information already known. That distinction keeps citation focused on provenance and accountability, not redundancy. In strategic terms, it marks where live evidence intersects with stored understanding. RAG is more than a retrieval pipeline; it is a governance model for living knowledge. The system moves from static recall to dynamic verification, from an archive to a curator of current information. #search #llms

One of the most popular use case of LLM( Large Language Model ) is RAG (Retrieval-Augmented Generation). Today let's deep dive on it. What is it? As the name suggests RAG has 3 part - Retrieval, Augmentation and Generation. Let's understand how it works step by step. User Query: A user asks a question. Retrieval: A retriever component (often using embeddings and a vector database) searches your knowledge base for the most relevant chunks of information related to the user's query. This component does the similarity search in knowledge base stored as embeddings in a vector database. I have discussed about embeddings in last post. Please refer that to get an idea about that. Augmentation: Top K retrieved relevant/similar information is then added to the user's original query, forming a combined, enriched prompt. Usually, we augment top 2-5 retrieved chunks for best results. This usually depends on your specific use case. Generation: This augmented prompt is fed to a standard LLM, which then generates a response based on its internal knowledge and the provided context. When to use RAG: 1. Fact-checking and reducing hallucinations: You want the LLM to ground its answers in specific, verifiable sources. 2. Working with proprietary, sensitive, or niche data: The data is not publicly available or might be too specific to warrant a full fine-tuning. 3. Cost-effectiveness for knowledge updates: Updating the knowledge base (e.g., adding new documents to a vector database) is much cheaper than re-fine-tuning an LLM. 4. Lower technical barrier to entry: Setting up a basic RAG system is relatively easier than managing LLM fine-tuning. Pros: 1. Reduced Hallucinations: Grounds answers in verifiable facts from provided sources. 2. Cost-Effective Knowledge Updates: Updating the knowledge base is cheap and fast. 3. Leverages existing LLMs: Doesn't require modifying the base LLM, using off-the-shelf powerful models. Cons: 1. Retrieval Quality is Key: If the retriever fails to find relevant information, the LLM won't be able to provide a good answer. 2. Context Window Limitations: The retrieved context must fit within the LLM's context window. All LLMs come with context window limitation. Even if limitation is long enough for some LLMs, it becomes costly with increasing context window. 3. Stylistic Limitations: The base LLM's style and tone remain unchanged. #RAG #LLM #Gemini #OpenAI #AI

Retrieval in LangChain: The Backbone of RAG Systems In the world of Retrieval-Augmented Generation (RAG), retrievers act as the essential bridge between user queries and the knowledge base. In LangChain, a retriever: ➡️ Accepts a natural language query ➡️ Applies retrieval logic (semantic, lexical, or hybrid) ➡️ Returns relevant documents enriched with metadata ⚙️ Core Types of LangChain Retrievers 🔹 Core Infrastructure Retrievers – Self-hosted or cloud-based systems like Elasticsearch, Amazon Kendra, and Google Search. 🔹 External Knowledge Retrievers – Direct access to external data sources such as Wikipedia, Arxiv, or TavilySearchAPI. 🔹 Algorithmic Retrievers – BM25 and TF-IDF for lexical matching, kNN for semantic similarity. 🔹 Advanced/Specialized Retrievers – NeuralDB (CPU-optimized) and LLMLingua (document compression). 🔹 Integration Retrievers – Seamless connections to Google Drive, Outline, and other repositories. 🧩 Vector Store Retrievers — Powering Semantic Search Vector stores are at the heart of semantic search. They convert both documents and queries into embeddings, enabling similarity-based matching. Any vector store can act as a retriever using the as_retriever() method. Here’s an example: from langchain_community.retrievers import KNNRetriever from langchain_openai import OpenAIEmbeddings retriever = KNNRetriever.from_documents(documents, OpenAIEmbeddings()) results = retriever.invoke("What is machine learning?") Other Key Retriever Types in RAG Systems 1️⃣ Search API Retrievers – Interface directly with external search services without storing data locally. from langchain_community.retrievers.pubmed import PubMedRetriever retriever = PubMedRetriever() results = retriever.invoke("COVID research") 2️⃣ Database Retrievers – Connect to structured data sources using natural language translation: SQL → text-to-SQL Graph DBs → text-to-Cypher Document DBs → specialized queries 3️⃣ Lexical Search Retrievers – Implement classical algorithms like: BM25 → Probabilistic keyword ranking TF-IDF → Term frequency-based relevance Elasticsearch → Scalable enterprise-grade text search 🔍 Hybrid and Custom Retrieval Modern RAG systems often combine multiple retrieval strategies for optimal accuracy and context: Hybrid Search – Merges semantic & lexical matching MMR (Maximal Marginal Relevance) – Ensures diversity in retrieved results Custom Retrievers – Build your own via BaseRetriever Retrieval isn’t just about finding information , it’s about understanding intent and bridging meaning. that’s what makes it the true engine behind every intelligent RAG pipeline. #LangChain #RAG #AI #VectorSearch #SemanticSearch #Retrieval #MachineLearning #LLM

Won't be able to make ISWC this year sadly.   @Andre Melo from Edinburgh will attend and present our work on "Schema-Constrained Grammar-Guided Generation of GQL Queries from Natural Language" in the Industry Track.   The Problem It Solves:   Current NL2GQL methods struggle with three critical pain points: ✅ Poor syntactic accuracy without grammar constraints ✅ High compute costs from multiple prompting steps or per-schema fine-tuning ✅ Schema violations that break query functionality   Key Breakthroughs:   🔹 Grammar as the Guardrail: Custom CFG extensions (with auto-expandable schema placeholders) ensure syntactic correctness AND schema compliance during decoding. 🔹 Zero Fine-Tuning Needed: No more training models for every new schema. One grammar setup works across use cases (e.g., ignore GQL create/update/delete syntax for QA-only graphs). 🔹 Faster & Cheaper: Cuts compute time and response latency by eliminating redundant prompt schema declarations. 🔹 Post-Processing Polish: Uses Abstract Syntax Trees (AST) to fix variable reference errors and ground literals (e.g., correcting typos like “Jordan” to “Michael Jordan”), boosting query execution performance.   Why This Matters for Your Work:   For teams building personal assistants, knowledge graph QA tools, or graph database interfaces, this method delivers low-resource, on-device NL-to-GQL translation that’s reliable and efficient. It outperforms prior grammar-constrained approaches (which sacrificed speed for accuracy) and schema-aligned fine-tuning (which drains resources).   📄 Read the full paper: https://lnkd.in/e2DDuSfU #ISWC2025 #GQL #KnowledgeGraphs #AIInnovation #NLP

The core idea of RAG is to transform large language models (LLMs) from closed "knowledge repositories" into open "information processors." By decoupling the model's parametric memory (training datasets) from its non-parametric memory (external knowledge base), it fundamentally addresses the problems of knowledge ossification, hallucination tendencies, and lack of traceability in LLMs. In essence, it converts a difficult open-book exam question into a reading comprehension task—it doesn't require the model to know everything, but only to summarize and synthesize based on the relevant materials provided. Therefore, the upper limit of a RAG system's capabilities is not determined by the LLM alone, but rather by the weakest link in the collaboration between its two major modules: the retriever (context) and the generator (model reasoning). Models may become increasingly powerful, but without good context, the model can only produce nonsense. Thus, the essence of optimizing RAG lies in: 1. Raw materials determine quality: The foundation of all optimization comes from building a high-quality knowledge index. This means performing fine-grained, content-aware chunking and metadata processing to ensure that retrieved content consists of semantically complete, clean, noise-free knowledge units. 2. Mind-reading trumps obedience: Don't expect the user's original query to be the optimal search query. Through query transformation and hybrid search, proactively infer and approximate the user's true intent from multiple dimensions—semantic, keyword-based, and others—to maximize the accuracy and comprehensiveness of retrieval. 3. Curation beats volume: We must always return to the model's attention mechanism. The goal of retrieval is not to provide the LLM with as many documents as possible. Even when the context window isn't full, providing the most precise context remains the prerequisite for excellent results. Introduce a reranking stage—add a quality control step before feeding content to the LLM—to ensure the model receives the most nutritious refined grain, not unfiltered chaff.

**🔍 Query Expansion Techniques** Query expansion is a technique that transforms a single user query into multiple related queries, increasing the chances of retrieving relevant documents by capturing different phrasings, synonyms, and conceptual variations. --- **🔍 Simple analogy:** It's like asking a question in multiple ways 🗣️. Instead of just asking "How do I fix my car?", you also ask "How to repair automobiles?", "Vehicle troubleshooting tips," and "Car maintenance solutions"—casting a wider net to find answers. --- **💡 Common query expansion methods:** **1. Synonym Expansion:** - Add related terms and synonyms to the original query - Example: "global warming" → ["climate change", "greenhouse effect", "rising temperatures"] **2. Multi-Query Generation:** - Use an LLM to generate semantically similar queries - Original: "open source NLP frameworks" - Expanded: ["natural language processing tools", "free NLP libraries", "open-source language processing platforms"] **3. HyDE (Hypothetical Document Embeddings):** - Generate a hypothetical answer first, then search using that answer's embedding - Bridges the gap between question style and document style **4. Query Decomposition:** - Break complex queries into simpler sub-queries - "Compare Python and Java for web development" → ["Python web development features", "Java web development features"] **When Query Expansion Helps:** - Vague or poorly formed user queries - Keyword-based retrieval systems - Handling diverse vocabulary and terminology - Improving recall in sparse document collections --- **🚀 Key takeaway:** Query expansion improves RAG recall by generating multiple perspectives on the same information need—ensuring you don't miss relevant documents just because they use different wording. #QueryExpansion #RAG #InformationRetrieval #LLM #RAGOptimization #TechExplained ---