Tapasya is a recommendation system built on top of RAG
- Setup
- the current Tapasya search stack, its session writer, and one design question: what is the system actually optimizing for
- Found
- the core problem is not one-shot answer generation; it is recommending the next passage worth reading, with retrieval and synthesis used to keep that recommendation grounded
- Result
- Tapasya search behaves like a stateful recommendation loop: each turn produces a cited answer, updates the passage registry, curates the reading list, and improves the next turn
The real problem
The hard part in Tapasya search is not answering one question well.
It is helping the user find the next passage worth reading.
That makes recommendation the product problem. RAG is the mechanism that keeps those recommendations grounded in the text instead of turning into model intuition.
First turn creates search state
On the first search turn, there is no useful session state yet. The runtime starts with an empty tool context, retrieves candidate passages, selects the strongest evidence, and then creates the search session artifacts that future turns will inherit.
sequenceDiagram autonumber actor User participant Page as Search participant Runtime participant State as Session state participant RAG as Retrieval User->>Page: First question Page->>Runtime: Execute search turn Runtime->>State: load_session_context() State-->>Runtime: no existing state Runtime->>RAG: retrieve and select passages RAG-->>Runtime: evidence set Runtime->>State: create session Runtime->>State: save evidence, registry, reading list, journey Runtime-->>User: cited answer Note left of User: first recommendations added to reading list User->>Page: Follow-up question Page->>Runtime: Execute next turn Runtime->>State: load_session_context() State-->>Runtime: existing evidence and reading state Runtime->>RAG: reuse prior passages + retrieve new ones RAG-->>Runtime: updated evidence set Runtime->>State: update evidence, registry, reading list, journey Runtime-->>User: cited answer Note left of User: reading list refined for next turn
Later turns update the same state
The important part is not just that Tapasya persists search state. It persists the right state:
evidence_bundlepassage_registryreading_listjourney
That is why longer conversations can get sharper. The next turn does not start from raw chat history. It starts from an evidence trail the system already built.
Why the reading list is part of the core system
The reading list is not a separate sidebar feature.
It is one of the outputs of the same search turn that produces the answer. The same evidence pass that grounds the answer also decides which passages stay live for the next turn.
That is what makes the recommendations improve over time. The reading list is the visible surface of a deeper state update.
Why this is RAG and not just search plus chat
If this were chat-first, the answer would be the product and the rest would be interface residue.
Tapasya does the opposite. Retrieval narrows the textual field, selection bounds the evidence, synthesis explains what the current evidence supports, and the reading list carries the strongest passages forward. The model is there to organize and explain the evidence, not to replace it.
That is why the search surface can get better over a longer conversation: the session accumulates more relevant passages, not just more words.
The decision that stayed
Tapasya is a recommendation system built on top of RAG.
Recommendation is the center. RAG is the way the system stays grounded, explainable, and stateful across turns.
That is the part that stayed.