Decomposed Prompting: A Modular Approach for Solving Complex Tasks

https://arxiv.org/abs/2210.02406

Decomposed Prompting: A Modular Approach for Solving Complex Tasks

 

Decomposition의 시초격 논문인 것 같습니다.

 

 

 

 

여기선 한번에 subtask를 decompose하는 방식이 아닌 그 때 그 때 해결하는 방식이네요...

 

split과 arr_pos를 사용하는 법을 잘 보여주네요 

 

여기선 재귀적 방법을 잘 보여줍니다. 

 

Retrieve까지 추가하여 Open Domain 문제도 해결하였다.

 

 

Figure 7을 통해 입력이 길어지면 다른 방법들은 성능이 낮아지는 것을 확인할 수 있지만 Decomposition을 진행한 방식은 가장 높은 점수를 꾸준이 유지하는 것을 볼 수 있다.

Figure 8에서도 단어 개수가 많아져도 낮아지긴 하지만 CoT로 해결할 수 없는 것을 해결하는 모습을 보여준다.

 

 

문제의식	기존 CoT, Least-to-Most Prompting 등은 복잡한 문제(긴 reasoning, multi-step QA, retrieval+reasoning 포함)에 대해 단일 흐름 또는 문장 기반 분해로는 일반화 성능과 디버깅에 한계가 있음.
핵심 아이디어	문제를 명시적인 (function, input, output) 형태의 sub-task들로 분해하고, 각 sub-task를 개별 모듈(handler)로 처리하는 모듈형 prompting 방식 제안.
구성 요소	① Decomposer Prompt: 문제를 sub-task 시퀀스로 나눔 ② Sub-task Handlers: 각 단계 처리 (LLM, rule, API 등 다양) ③ Executor: sub-task 결과를 최종 답으로 결합
방법론 특징	- reasoning, retrieval, 계산 등을 모듈로 나눠 처리 - handler는 GPT, symbolic 툴, rule 기반 등 혼합 가능 - 재귀적 처리, 리스트 조작 등도 가능 (예: list reverse)
예시 구조	🔤 문자열 문제: split → extract_first_char → join ➗ 수학 문제: find_value → find_multiplier → multiply 🔍 QA: query → retrieve → synthesize_answer
적용 과제	🔸 k-th 문자 추출 🔸 리스트 재귀 뒤집기 🔸 긴 문서 QA (CommaQA) 🔸 Open-domain QA (HotpotQA 등) 🔸 수학 QA (GSM8K, MultiArith)
실험 결과	- 모든 태스크에서 CoT 대비 정확도 우세 - 복잡도/길이 증가에도 성능 급감 없이 일반화 유지 - 특히 reasoning + 검색 혼합 문제에서 강력한 성능
장점	✅ 중간 reasoning 단계가 명확하여 디버깅 용이 ✅ 외부 도구 결합 (ES, 계산기 등) 가능 ✅ handler 재사용 및 구성 확장성 우수
한계점	⚠ sub-task 분해는 현재 수작업 또는 수동 프롬프트 설계 필요 ⚠ pipeline 중간 실패 시 전체 실패 가능성 있음 ⚠ 학습 가능한 decomposer는 향후 과제로 남음
학술적 기여	🔹 Prompting을 task handler 수준으로 모듈화한 새로운 패러다임 제시 🔹 symbolic 도구와 LLM을 혼합 가능한 아키텍처로 확장 🔹 복잡 reasoning 문제 해결을 위한 프롬프트 기반 framework 설계

 

논문 “Decomposed Prompting: A Modular Approach for Solving Complex Tasks” (ICLR 2023)은 복잡한 문제를 더 단순한 서브 태스크로 나누고, 각 태스크를 독립적인 프로세스(프롬프트 또는 심볼릭 시스템)로 해결하는 모듈형 접근 방식을 제안합니다

---

📌 논문 핵심 요약표

문제 정의	기존 few-shot prompting, CoT prompting은 복잡한 문제를 처리할 때 한계가 있음.
제안 방식	문제를 작은 sub-task로 나누고, 각각의 sub-task handler(LLM 또는 symbolic module)로 처리하는 방식 (DECOMP)
핵심 구성 요소	- Decomposer: 전체 문제를 sub-task로 나누는 프롬프트 생성기 - Sub-task Handlers: 각 서브 문제를 해결하는 모듈들 (프롬프트, 다른 LLM, 검색 시스템 등)
프롬프트 형식	각 sub-task는 [(function, query, answer)] 형태로 구성되어 실행됨
모듈화 이점	- 디버깅 및 교체가 용이 - 재사용 가능 - Symbolic 시스템과 연계 가능 (예: Elasticsearch)
실험 과제	① kth 문자 연결 ② 리스트 뒤집기 (재귀) ③ 긴 문서 기반 QA ④ Open-domain QA (ElasticSearch 활용) ⑤ 수학 QA (CoT 후 정답 추출 개선)
성과 요약	- 모든 태스크에서 CoT, Least-to-Most Prompting보다 향상된 성능 - 특히 길이나 복잡도가 증가할수록 일반화 성능에서 큰 격차를 보임
한계 및 확장성	- 적절한 sub-task 설계 및 prompt 설계에 여전히 수작업이 필요 - 자동화된 decomposer 학습은 향후 과제로 남아 있음

---

🔍 방법론 상세

1. Decomposed Prompting 구조

• 기존 CoT는 reasoning 과정을 한 줄로 보여주는 반면, DECOMP는 이를 모듈화된 단계로 나누어 처리함.
• 예시:
• Task: "Jack Ryan" → 각 단어의 첫 글자 이어 붙이기
  - Q1: 단어 나누기 → ["Jack", "Ryan"]
  - Q2: 각 단어의 첫 글자 추출 → ["J", "R"]
  - Q3: 공백으로 연결 → "J R"

2. Sub-task 처리 방식

• LLM prompting, symbolic API 호출 (e.g., Elasticsearch), rule-based 방식 등을 sub-task handler로 혼합 사용 가능.
• CoT 결과에서 정답을 잘못 추출하는 경우, 별도 GPT3 handler로 정확한 정답만 추출하는 방식도 적용 가능.

3. 재귀 구조 지원

• 리스트 뒤집기 등의 태스크에서 리스트를 재귀적으로 분할 → 각 부분 처리 → 병합 구조 지원. 이는 기존 CoT나 Least-to-Most 방식보다 유연한 방식임.

---

📊 주요 실험 결과 요약

Task	CoT 정확도	Decomposed Prompting (DECOMP)
kth 문자 추출	22.7–74.7%	96–98% (길이 증가에도 일반화 유지)
리스트 뒤집기	5.5–59%	76–86% (Recursive 구조로 일반화 개선)
Long-Context QA (CommaQA)	낮은 성능	분리된 sub-task가 정확도 향상에 기여
Open-Domain QA	No-decomp보다 평균 10~20pt 향상 (MuSiQue, HotpotQA, 2WikiMultiHopQA)
수학 QA (GSM8K, MultiArith)	36, 78	50.6, 95 (정답 추출 handler 추가)

---

🧠 결론 및 한계

• 결론: Decomposed Prompting은 복잡한 문제를 모듈 단위로 나누어 해결하는 방식으로, 유연성, 디버깅 용이성, 성능 향상 측면에서 기존 프롬프트 방식보다 우수함.
• 한계: Decomposer 설계 및 각 sub-task의 적절한 프롬프트 구성에는 도메인 지식과 수작업 설계가 필요함.

---

 

 

---

📚 관련 연구 비교 정리

구분	방법	논문	주요 특징	Decomposed prompting과의 차이점
🧠 Chain-of-Thought (CoT)	단계별 reasoning을 natural language로 표현	“Chain-of-Thought Prompting Elicits Reasoning in LLMs”	reasoning 과정을 단일 LLM이 연속적으로 처리	- Decomp는 각 단계를 명시적으로 분리하여 모듈화 - CoT는 중간 단계 결과 활용이 어려움
🪜 Least-to-Most Prompting	문제를 점진적으로 작은 문제로 분해	“Least-to-Most Prompting Enables Complex Reasoning in LLMs”	간단한 문제로 변환 → 점진적 조합	- Decomp는 explicit sub-task handler 사용 가능 (symbolic, LLM 등 혼합) - L2M은 주로 자연어 수준의 분해에 국한
🧩 Program-Aided Prompting	symbolic program + LLM hybrid	“PAL: Program-Aided Language Models”	LLM이 프로그램을 출력 → 실행 → 정답 획득	- PAL은 코드 기반 프로그램 중심, Decomp는 일반 프롬프트 기반 모듈도 사용 가능
🔁 Toolformer / ReAct	툴 사용 + 반응 기반 reasoning	“Toolformer”, “ReAct”	LLM이 API 호출 삽입, 도구와 상호작용	- Decomp는 static pipeline 구조 중심, ReAct/Toolformer는 interleaved action/observation 흐름
🔨 Modular Prompting	작업별로 분리된 프롬프트 체계	"Neural Module Networks”	sub-task를 모듈별로 분리하고 학습	- Neural Module Network는 fully supervised, end-to-end 학습 기반, Decomp는 프롬프트 기반 zero-shot 처리 가능
🔍 RAG (Retrieval-Augmented Generation)	외부 지식 검색 후 답 생성	“Retrieval-Augmented Generation”	query → retriever → LLM decoder 구조	- RAG는 retrieval과 decoding이 tightly coupled - Decomp는 retrieval을 하나의 모듈로 활용 가능하며, 다단계 구조 적용 가능
🔄 Self-Ask	질문을 생성하고 다시 질문	“Self-Ask”	LLM이 스스로 sub-question을 생성하고 답함	- Decomp는 sub-question에 대해 프롬프트 또는 외부 도구 사용 가능, Self-Ask는 LLM 단독 처리
🧠 Tree of Thoughts	트리 구조 탐색으로 생각 확장	“Tree of Thoughts”	생각 과정을 트리 형태로 관리하며 탐색	- Tree of Thoughts는 탐색 기반, Decomp는 명시적 프롬프트 파이프라인 기반

---

🔍 차이점 요약 정리

	CoT	Least-to-Most	PAL	Toolformer/ReAct	RAG	Decomposed Prompting
🧩 모듈화	✗	△	△	△	✗	✅
🔄 재사용성	✗	✗	△	✗	✗	✅
🔧 외부 툴 결합	✗	✗	✅	✅	✅	✅
🧠 reasoning 구조	연속	점진적	코드 실행	행위 기반	검색 기반	병렬적 모듈 구조
📦 처리 단위	전체 프롬프트	자연어 분해	Python 코드	Tool 호출	문서 retrieval	(function, input, output) 3-튜플 기반 task unit
🧪 특징	simple yet strong	gradual generalization	program+LLM	reasoning+act	factual QA	reasoning, retrieval, execution 혼합 가능

---

🧠 전문가용 요약 포인트

• Decomposed Prompting은 단순한 prompt chaining이 아닌, 명시적인 task 분해와 모듈 조합을 통해 복잡한 reasoning, 검색, 정답 추출 등 다양한 서브태스크를 유연하게 처리함.
• 기존 방식들과 달리 디버깅과 구성 변경이 용이하며, symbolic 또는 LLM handler를 자유롭게 조합할 수 있다는 점에서 강력한 일반화와 실용성을 동시에 확보함.
• 향후에는 자동 sub-task planner 또는 decomposer 학습으로 확장 가능성이 있음.

---

 

 

---

🧠 핵심 개념 요약

복잡한 문제를 잘게 쪼개고, 각 단계를 독립적인 sub-task handler(LLM, 검색기, 심볼릭 계산기 등)로 처리하여, 전체 문제를 해결하는 모듈형 파이프라인 프롬프팅 방식

---

🧩 전체 구조 (Decomposed Prompting Architecture)

1. Decomposer Prompt
   • 사용자가 입력한 복잡한 문제를 sub-task들로 나누는 역할
   • 출력은 일종의 task plan 또는 API 호출 시퀀스
2. Sub-task Prompting Handlers
   • 각 sub-task는 개별 handler가 처리
   • handler는 GPT, CoT, rule-based prompt, Elasticsearch API 등 다양하게 구성 가능
3. 결과 결합
   • sub-task들의 결과를 최종 답으로 합성
   • 경우에 따라 재귀 호출 혹은 리스트 조작 등이 가능

---

🔄 Pipeline 예시: 문자열 처리 문제

문제: “Jack Ryan”의 각 단어의 첫 글자만 출력하라.

✅ 기존 CoT 방식:

"Jack Ryan"은 두 단어다.
첫 단어는 Jack → 첫 글자 J
두 번째는 Ryan → 첫 글자 R
정답은 JR

✅ Decomposed 방식:

[
  ("split", "Jack Ryan", ["Jack", "Ryan"]),
  ("extract_first_char", ["Jack", "Ryan"], ["J", "R"]),
  ("join", ["J", "R"], "JR")
]

각 함수는 하나의 sub-task로 분리되어, 별도의 handler가 처리한다.
예를 들어 "split"은 단순 rule 기반, "extract_first_char"는 LLM prompting으로 수행 가능.

---

🔍 또 다른 예시: 수학 문제 처리 (GSM8K)

문제: “Tom has 3 times as many apples as Jerry. Jerry has 4 apples. How many apples does Tom have?”

✅ Decomposer 출력 (CoT 대신 Decomp)

[
  ("find_value", "Jerry has 4 apples", 4),
  ("find_multiplier", "Tom has 3 times as many as Jerry", 3),
  ("multiply", [3, 4], 12)
]

• "find_value"는 수치 extraction 프롬프트
• "multiply"는 GPT 또는 심볼릭 계산기 사용

이처럼 중간 reasoning 과정이 명확하게 명시되고 모듈화되어 있음.

---

🔧 주요 구성 요소 설명

구성 요소	설명	구현 예시
Decomposer Prompt	입력 문제를 sub-task로 분해	GPT에 “문제를 해결하기 위한 함수 호출 리스트를 반환해줘” 프롬프트
Sub-task Handler	각 서브 문제를 해결하는 GPT 또는 rule	예: “extract_first_char”에 대해 "각 단어의 첫 글자를 반환하라"는 프롬프트
Executor	결과를 다음 단계로 전달, 최종 답 생성	JSON 형태로 결과 관리, 리스트 조작 등
Optional: Symbolic Module	GPT 대신 Elasticsearch, Python 계산기 등 사용	예: open-domain QA에서 retrieval은 ES가 처리

---

📈 효과적인 이유 (기존 방식 대비)

항목	기존 방식 (CoT 등)	Decomposed Prompting
reasoning 흐름	단일 흐름에 종속	모듈별로 분리, 디버깅 쉬움
재사용성	낮음	높음 (handler 재활용 가능)
외부 시스템 결합	어려움	가능 (e.g., ES, 계산기)
성능 일반화	길거나 복잡할수록 취약	구조화로 인해 일반화 유지
처리 단위	비명시적 문장	(function, input, output) 구조화된 형식

---

🔬 실험 구조 요약

논문에서는 다음과 같은 task 유형에 따라 위 방식을 실험적으로 적용:

1. 구조화 문자열 처리: split → extract → join
2. 재귀형 문제 (list reverse): divide → recursive solve → merge
3. Open-domain QA: question → retrieval → answer synthesis
4. 수학 문제: 정보 추출 → 계산 → 정답 생성
5. 긴 문서 QA: decomposition → 특정 문장 추출 → 정답 추론

---

📌 정리

• Decomposed Prompting은 프롬프트를 모듈화하여 reasoning, retrieval, 계산 등을 유연하게 조합 가능한 체계로 만든 방식입니다.
• 각 handler는 LLM이 될 수도 있고, rule이나 검색 도구처럼 symbolic 방식이 될 수도 있습니다.
• 이 접근법은 설명 가능성, 일반화, 재사용성 측면에서 기존 CoT 방식보다 우수하며, 복잡한 reasoning이 필요한 다양한 분야에서 활용될 수 있습니다.

---

 

 

---

✅ 최종 결과 요약 (Results)

논문에서는 다양한 reasoning 및 QA 태스크에 Decomposed Prompting을 적용하고 기존 방법들과 비교하였습니다.

Task	기존 방법 (정확도)	Decomposed Prompting 정확도	성능 향상 요약
k-th 문자 문제	CoT: 22.7% (길이↑시 급감)	96.0%~98.7%	길이 증가에도 일반화 유지
List reverse (재귀형)	CoT: 5.5%~59.0%	76.5%~86.5%	재귀 구조에서 강한 일반화
CommaQA (long-context QA)	baseline: 낮음	Decomp > CoT > direct QA	문장 추출, reasoning 분리로 향상
Open-domain QA (HotpotQA, 2Wiki...)	GPT3: 38~59%	Decomp: 49~73%	10~20pt 이상 향상
수학 QA (GSM8K, MultiArith)	CoT: 36.0%, 78.0%	Decomp: 50.6%, 95.0%	정답 추출 오류 제거 효과

📌 결론: 복잡도가 높아질수록, 그리고 reasoning/retrieval이 혼합된 과제일수록 Decomposed Prompting의 효과가 두드러짐.

---

🧠 결론 (Conclusion)

• Decomposed Prompting은 복잡한 문제를 구조적으로 해결하기 위해, 문제를 명시적인 sub-task로 나누고, 이를 모듈화된 handler로 처리하는 새로운 prompting paradigm이다.
• CoT, Least-to-Most Prompting, ReAct 등 기존 방식들이 갖는 한계(불안정성, 중간 과정 해석 불가, 도구 결합 어려움 등)를 극복하며, reasoning generalization과 구성 가능성(modularity)을 동시에 달성하였다.

---

⚠️ 한계점 (Limitations)

항목	설명
Sub-task 분해 수작업	현재는 사용자가 문제를 어떻게 나눌지 prompt를 설계해야 하며, 자동 분해(Decomposer 학습)는 아직 미완성
Handler 설계 비용	각 sub-task에 적합한 prompt 또는 툴을 설정하는 데 전문가의 개입이 필요함
Pipeline 실패 취약성	중간 sub-task 중 하나라도 실패하면 전체 결과가 실패할 수 있음 (모듈화의 trade-off)
성능 평가 어려움	구조가 복잡해질수록 각 단계의 성능 기여도를 분석하거나 디버깅하기 위해 추가적인 trace 분석이 필요함

---

🎓 기여 (Contributions)

🔹 Prompt 모듈화 개념 도입	문제를 (function, input, output) 구조로 명시하고, step-by-step이 아닌 module-by-module로 분리 수행
🔹 Handler 혼합 프레임워크	LLM, symbolic API, rule-based module 등을 하나의 framework 내에서 자유롭게 혼합 가능하게 함
🔹 재귀, 검색, 계산 포함하는 복합 태스크 처리	reasoning + retrieval + execution이 혼합된 복잡한 문제를 안정적으로 처리할 수 있는 체계 구축
🔹 성능 향상 + 일반화 확보	reasoning 길이나 입력 복잡도 증가에도 성능이 급감하지 않고 강력한 generalization 보임
🔹 확장 가능성 높은 기반 설계	향후 자동 decomposer 학습, plan optimization, module search 등과 결합 가능성이 큼

---

📌 요약 마무리

Decomposed Prompting은 기존 prompting의 흐름을 명시적 모듈화(modularization)하여 더 나은 reasoning, 도구 활용, 디버깅, 일반화를 가능하게 한 프롬프팅 프레임워크이다.
특히, reasoning + 검색 + 계산을 하나의 체계로 통합 가능하다는 점에서 지속적 발전 가능성과 실용성 모두를 보여준 방식이다.

---