rag – RaspeR87's Blog

When teams first introduce a Microsoft 365 declarative agent into an existing system, the goal is usually straightforward: expose backend capabilities through a Copilot-friendly interface.

That’s useful—but not yet transformative.

The real shift happens when the agent stops being just a thin wrapper over an API and starts driving interaction based on grounded evidence. Instead of returning only an answer, the system begins suggesting the next valid step—and does so deterministically, based on real legal sources.

This article walks through that transition from an engineering perspective.

The problem with “one-shot” Copilot interactions

A typical declarative agent interaction looks like this:

The user asks a question
The backend returns an answer
Sources are displayed
The conversation stops

At that point, the burden shifts back to the user: What should I ask next?

In domains like legal or policy workflows, this is a serious limitation. The system already has the context, the sources, and the structure—but the interaction model doesn’t leverage it.

The challenge becomes:

How do we guide the user forward without letting the model improvise or hallucinate the next step?

Design goals

The solution was built around a few strict constraints:

Only generate follow-up prompts when they can be grounded in real legal sources
Keep the API contract stable (no Copilot-specific hacks)
Make prompts directly actionable in the UI
Avoid redundant or repeated suggestions

This leads to a key principle:

The system should not invent the next step. It should derive it from evidence.

Architecture overview

The implementation builds on top of an existing “rich answer” pipeline.

High-level flow:

Backend returns an answer (text + sources)
A parser extracts structured data from the response
Source metadata is analyzed
A prompt builder evaluates whether grounded suggestions can be generated
If conditions are met → prompts are emitted
UI renders them as clickable actions

This keeps the system data-first:

Backend = logic + structure
UI = rendering only

No hidden heuristics in the frontend.

Continue reading →

A Practical Guide to Handling Large Legal Tables in RAG Pipelines

When working with legal documents—especially EU legislation like EUR-Lex—you quickly run into a hard problem: tables.

Not small tables.
Not friendly tables.
But hundreds-row, multi-page tables buried inside 300+ page PDFs, translated into 20+ languages.

If you are building a Retrieval-Augmented Generation (RAG) system, naïvely embedding these tables almost always fails. You end up with embeddings that contain nothing more than:

“Table 1”

…and none of the actual data users are searching for.

This post describes a production-grade approach to handling large legal tables in a RAG pipeline, based on real issues encountered while indexing EU regulations (e.g. Regulation (EC) No 1333/2008).

The Core Problem

Let’s start with a real example from EUR-Lex:

ANNEX III
PART 6
Table 1 — Definitions of groups of food additives

The table itself contains hundreds of rows like:

E 170 — Calcium carbonate
E 260 — Acetic acid
E 261 — Potassium acetates
…

What goes wrong in many pipelines

The table heading (“Table 1”) is detected as a section.
The actual <table> element is ignored or stored separately.
Embeddings are generated from the heading text only.

Result:

Embedding text length: 7
Embedding content: "Table 1"

The data exists visually—but not semantically.

Design Goals

We defined a few non-negotiable goals:

The table must be searchable
Queries like “E170 calcium carbonate” must hit the table.
IDs must be stable and human-readable
ANNEX_III_PART_6_TABLE_1 is better than _TBL0.
Structured data must be preserved
We want JSON rows for precise answering, not just text.
Embeddings must stay within limits
Some tables have hundreds of rows.

Continue reading →

Tag: rag

From Declarative Agent to Source-Grounded Legal Copilot