Wisdom-Driven Knowledge Augmented Generation at Scale

What does an AI system need when a client wants research and advice in a specialist domain, rather than information retrieved from a database? That is the problem behind Chin Keong Lam’s work at Patho.ai. Introducing himself as its founder and CEO, Lam describes starting two years earlier with an invitation through the National Science Foundation’s SBIR program to investigate LLM embeddings. An initial application in drug discovery led to building expert AI systems for corporate clients. Their requests increasingly required the system to perform advisory work.

The starting point is a broader definition of knowledge: understanding acquired through experience, education, facts and principles. A knowledge graph connects that material through explicit relationships. In Lam’s framing, the graph should preserve both a domain’s taxonomy and something of its experts’ thought process—the connections they use to reach a decision.

Knowledge-Augmented Generation (KAG) is his term for integrating that structured graph with a language model. The intended step beyond basic retrieval is to supply relationships and context that help the model synthesize advice. Lam characterizes this as understanding rather than merely retrieving; the engineering question is how to represent the expert’s reasoning and make it available at the right moment.

Interviews with clients revealed recurring patterns in how experts think and decide. Lam represents those patterns as a graph, or state diagram, with wisdom at its center. Wisdom guides the blue decision-making node, which analyzes the green situation node. Decisions therefore depend on the circumstances in which they will be applied. A gold relationship feeds knowledge back into wisdom.

Books, encyclopedias and Wikipedia can supply knowledge, but ingestion alone does not complete this process. The system must synthesize what it has absorbed. Insight supplies a different input: patterns extracted from disorder. For a client tracking product sentiment, scattered social-media posts and X discussions can reveal how customers perceive its products relative to competitors.

The distinction between knowledge, experience and insight is easier to see in Lam’s pizza analogy:

These inputs become useful together: the recipe is interpreted in light of a particular oven, and an idea for the next attempt emerges from that context.

The feedback loop is the essential part of the graph. A situation informs future wisdom; experience deepens it; insight sharpens it. Lam compares this accumulation to a tree growing stronger roots. In leadership, the loop means using feedback to avoid knee-jerk reactions. In personal growth, it means learning from past mistakes. Wisdom, in this model, is a muscle exercised through repeated use rather than a trophy acquired once.

The concrete client application is competitive analysis, work previously handled by a marketing department. The client wants an AI system that can answer a strategic question: how can we win against a competitor in this market? Returning relevant passages is only one ingredient. The answer must connect evidence about the market with the company’s history and present position.

Lam retains the same taxonomy and assigns each part a business responsibility. The wisdom engine becomes an orchestration agent that decides what the LLM can see in the current situation and what should happen next.

The situation node makes advice conditional on how the client’s products are actually doing. Market information becomes more useful when the model can relate it to that current position.

Lam prototypes the workflow in n8n. It recalls his earlier IoT work with Node-RED, the visual flow tool that originated at IBM and runs on Node.js. The appeal is a visual interface for connecting operations while code performs the work underneath. Community nodes provide building blocks for turning the state diagram into an executable workflow.

The n8n AI Agent node is central to this prototype. Lam uses n8n for its flexibility; a lighter implementation using something such as LangChain is a possible later choice, not a migration he demonstrates. The linked documentation describes the current Tools Agent behavior, while the recording does not identify its n8n version.

The wisdom engine becomes a supervisory wisdom agent, with options to use models from OpenAI or Anthropic, or an on-premises model. It oversees specialist agents that carry out the responsibilities in the state diagram. Model choice and workflow responsibility are separate: the supervisor’s job remains coordinating the work even when its underlying model changes.

For example, an insight agent visits social media, collects sentiment about the client’s products and writes its findings into the insight portion of a centralized knowledge graph. Other agents update their corresponding portions of that same graph. Their outputs accumulate in a unified taxonomy intended to reflect how a marketing strategist organizes evidence.

A human team might keep similar decision material in SharePoint or a collection of folders. Here, explicit relationships connect it for subsequent reasoning. Lam acknowledges that the final answer depends on the model, but places particular weight on the taxonomy and graph structure: the advisor needs the right organization of evidence to make a useful decision. That leads to a closer examination of the competitive-analysis component.

Why use a knowledge graph, with a database such as Neo4j, for this work? Lam gives five reasons for preferring it to traditional vector RAG in his competitive-analysis application:

• Relationship context. Explicit connections between entities can expose gaps in competitor awareness and preserve nuances that matter to a strategy.
• Accuracy and relevance. Structured data and semantic relationships can narrow the evidence used in an answer and reduce noise. For a marketing advisor, inaccurate data can lead to bad decisions—and, as Lam emphasizes, cost a contractor the client.
• Scalability and flexibility. New sources and relationships can enrich the system over time, provided the taxonomy remains suitable.
• Rich queries. Traversing several relationships supports multi-hop questions whose answers require connecting multiple entities.
• Data integration. Pictures, graphics and videos can contribute information through LLM and OCR capabilities, with structured and semi-structured results organized in the graph.

These are the architectural benefits Lam seeks. The common dependency is a graph structure that preserves the relationships relevant to the client’s decisions.

The numerical example makes the distinction concrete. Vector retrieval excels at finding semantically similar passages; it does not itself perform the calculation a market analyst needs. Lam begins with a question about Apple’s revenue in 2022. A retrieval system may return a paragraph discussing the revenue, leaving the required numerical work unresolved.

The graph-driven path separates finding evidence from computing an answer:

1. Store the financial data as structured records in an Apple financial knowledge graph.
2. Query the revenue figures for 2021 and 2022.
3. Pass the selected figures to a function that performs the calculation.
4. Return the quantitative result for the marketing decision.

Lam gives 15.23 as the illustrative function output. The slide shows a percentage-change calculation, but the example does not establish the inputs and units behind that number; it should not be read as Apple’s verified fiscal revenue growth. The mechanism is the useful distinction: structured retrieval supplies the operands, and a function supplies the arithmetic.

That separation gives the advisor numerical evidence rather than only a passage that happens to discuss the subject. For decisions based on financial or market quantities, retrieving relevant text and producing the requested calculation are distinct responsibilities.

The choice is not an all-or-nothing replacement of RAG. Lam points to LangChain plus Chroma as one way to build retrieval, and notes that it can be combined with a knowledge graph. His architecture slide highlights the wisdom graph he adopts in red. The appropriate combination depends on what the client asks the system to do.

The second question requires the system to connect the client’s present position to other evidence before proposing a strategy. Lam describes several loops of querying, rather than one retrieval followed immediately by an answer.

A Cypher pattern match makes the structured-retrieval part explicit. Using an illustrative schema for the Apple example—Company nodes connected to FinancialYear records—the query can select the two operands without asking the model to recover them from prose:

MATCH (company:Company {name: 'Apple'})
      -[:HAS_FINANCIALS]->(financials:FinancialYear)
WHERE financials.year IN [2021, 2022]
RETURN financials.year AS year,
       financials.revenue AS revenue,
       financials.currency AS currency,
       financials.unit AS unit
ORDER BY year;

The schema names illustrate the query boundary, not the client’s database schema. Returning currency and unit alongside revenue keeps the quantities interpretable before a calculation consumes them. A strategic advisor needs further queries and synthesis beyond this small retrieval step; Lam expects the repeated graph-query process to improve the resulting advice.

Building the graph introduces another choice: construct it manually, use a fully automated LLM graph transformer, or combine the two. Lam recommends the hybrid approach:

1. Use an LLM to extract an initial graph.
2. Interview the domain expert to establish the taxonomy the system should use.
3. Prune the graph by removing relationships that do not belong in that taxonomy.

The expert’s contribution is therefore not limited to supplying documents. It also determines which extracted connections should survive into the representation used for advice.

Lam reports 91% accuracy and 85% flexibility in his benchmark. He attributes the accuracy result to extracting structure, then names deterministic reproducibility, traceability and scalability as additional evaluation dimensions. The talk does not define the benchmark task, dataset, baseline, scoring methods or conditions, so the percentages cannot establish an expected improvement for another application.

The ambition is to improve quantitative reasoning and responses to complex questions by giving the system a structured store of expertise. With the right framing, Lam suggests, accumulated knowledge, experience and insight could eventually support capabilities beyond those of the initial expert. He presents that as a possibility, not a demonstrated outcome. A brief “Talk to Jesus” notebook aside follows the conclusion before he turns to the practical starting point.

Lam closes by pointing to a GitHub LLM GraphRAG stack that he describes as sponsored by Neo4j. His proposed handoff is straightforward: start it with Docker, convert text into a graph, then begin pruning. Automatic extraction gets the material into connected form; refining those connections is how the builder shapes it into the domain representation the advisory system needs.