Content revision ea31a3343577b30cee4337cf2fef2b0864a5741341f27598e9108766c486fb2d

## Judging the whole solution

A Structure-Preserving RAG Ingestion Pipeline
Source ID ragflow-pipeline:judging-the-whole-solution
Original https://www.henryw.me/#/ragflow-pipeline#judging-the-whole-solution

Part of my role was deciding what would count as meeting a requirement. “Support complex tables” leaves several possibilities open. A tool might reproduce a table’s appearance, recover its hierarchy, or make that hierarchy available to the model answering a question. The client’s purpose determines which of these matters. I had to translate that purpose into checks detailed enough to guide a technical choice, while leaving room to discover how existing tools could satisfy it. Specifying a particular implementation too early would have narrowed the options before I understood them. I also needed to judge the combination of tools as a solution in its own right. A capability demonstrated by one component can disappear at its interface with the next, as the table structure did during downstream processing. That makes integration part of the evaluation itself.

It affects where to intervene, too. Existing parsing capabilities covered several requirements, while reference linking called for a small piece of custom logic. The distinction depended on the relationship each requirement needed to preserve. It gave me a reason for every part I added and a way to test whether that addition worked. Operating constraints belong in the same reasoning. Ingestion frequency changes whether model start-up time or idle GPU cost is the more significant concern. A preference for fewer models affects the value of finding table and flowchart support within one parser. These dependencies mean a recommendation has to explain the conditions under which its choices make sense. I want the client to be able to see which decisions can remain in place as usage grows, and which should be revisited if its documents, workload or infrastructure change.