Principle:Spcl Graph of thoughts LLM Response Parsing
| Knowledge Sources | |
|---|---|
| Domains | LLM_Orchestration, Output_Parsing |
| Last Updated | 2026-02-14 12:00 GMT |
Overview
Abstract interface pattern that defines how to parse raw language model responses into structured thought state dictionaries within a graph-based reasoning framework.
Description
The Parser abstraction decouples response parsing from reasoning execution. Each operation type in the Graph of Operations (Generate, Aggregate, Improve, Validate, Score) produces a different kind of LLM output that must be interpreted differently. The Parser defines 5 abstract methods matching these operation types:
- parse_generate_answer: Transforms raw LLM text from a generate operation into one or more new thought state dicts
- parse_aggregation_answer: Transforms raw LLM text from an aggregation operation into a merged thought state
- parse_improve_answer: Transforms raw LLM text from an improve operation into a refined thought state
- parse_validation_answer: Transforms raw LLM text from a validation operation into a boolean (valid or not)
- parse_score_answer: Transforms raw LLM text from a scoring operation into a list of float scores
Each concrete Parser implementation encodes domain-specific knowledge about how to extract structured data from free-text LLM responses. The parser receives both the original thought state(s) used to generate the prompt and the raw text response(s) from the LLM.
Usage
Use this principle when implementing a new problem domain for the GoT framework. Create a concrete Parser subclass that knows how to extract structured results from LLM responses for your specific task (sorting, keyword counting, document merging, etc.). The Parser is the counterpart to the Prompter: while the Prompter encodes how to ask, the Parser encodes how to interpret the answer.
Theoretical Basis
The Parser applies the Strategy Pattern to LLM output interpretation. Rather than hard-coding parsing logic in the execution engine, the Parser interface allows hot-swapping parsing strategies. This is the complement of the Prompter pattern and together they form a symmetric pair:
- Prompter: state dict --> prompt string (encoding)
- Parser: response string --> state dict (decoding)
This symmetry ensures that domain-specific knowledge is fully encapsulated in the Prompter/Parser pair, while the controller and graph of operations remain domain-agnostic.
Pseudo-code:
# Abstract algorithm (NOT real implementation)
for each operation in graph:
prompt = prompter.create_prompt(operation, thought_states)
response = lm.query(prompt)
texts = lm.get_response_texts(response)
if operation.type == GENERATE:
new_states = parser.parse_generate_answer(state, texts)
elif operation.type == AGGREGATE:
new_state = parser.parse_aggregation_answer(states, texts)
elif operation.type == VALIDATE:
is_valid = parser.parse_validation_answer(state, texts)
elif operation.type == SCORE:
scores = parser.parse_score_answer(states, texts)
elif operation.type == IMPROVE:
new_state = parser.parse_improve_answer(state, texts)