- paper 대신 참고 link : https://blog.langchain.com/open-deep-research/
## ODR pipeline
- scope : 리서치 범위 설정 (user classification, Brief generation)
- research : 실제 리서치 수행 (이때 supervisor 과 sub agent 동작)
- write : 최종 보고서 작성 (one-shot report generation)
graph 구조
- **Scope**
1. User classification (classify with_user 노드): 리서치 요청시에 사용자의 대화를 통해 추가 정보를 묻는 절차
2. Brief generation (write_research_breif) : 명확한 질문들 또는 사용제 제공 예시등을 초함한 대화내용 → research brief로 변환
⇒ 이게 보고서 작성의 길잡이 역할로 전 과정에서 수시로 참고
⇒ user classification에서 티키타카를 통해 다듬은 명확한 쿼리 형태
- **Research**
1. research supervisor (supervisor) : 리서치 작업을 여러 하위 주제로 나눌 수 있는지 판단하고 적절한 수의 sub-agent를 할당 (병렬로 작업 수행하도록)
2. research sub-agent (supervisor_tools) : 각 하위주제에 대해서 집중하여 리서치 수행
1. tool-calling loop (MCP, Tavliy 같은 웹검색)
2. LLM을 통해 자세한 답변 작성
3. 추가 정제단계를 거쳐서 효율적인 연구결과만 판단 할 수 있도록 조치
1. Research supervisor itertation
1. 감독자(Supervisor)는 하위 에이전트(Sub-Agent)들이 수집한 결과물이 연구 브리프(Research Brief)의 전체 범위(Scope of Work) 를 충분히 다루고 있는지를 추론(reasoning)
2. 만약 결과의 깊이가 부족하다면 다시 심층 연구를 하도록 지시
3. 수집된 연구결과가 2단계 연구 브리프의 요구사항을 충분히 충족한다면, 보고서 작성 단계로 넘어가기
- **write**
1. one-shot report generation (final_report_generation) : 단 한번의 LLM 호출로 완성된 보고서를 작성
1. 하위 에이전트들의 반환한 연구 결과를 LLM에 입력
2. 최종 보고서의 방향은 연구 브리프(Research Brief)에 제시된 목적과 질문에 의해 **조정(steered)** 되고, 하위 에이전트들의 연구 결과를 기반으로 **답변**
- 추가 연구 및 lesson-learn
- multi agent 를 research에만 둔 이유
- 멀티에이전트는 **조율이 어렵고**, 보고서의 섹션을 병렬로 작성할 경우 **품질이 저하될 수 있다.**
- 따라서 멀티에이전트는 **연구(Research)** 에만 활용하고, **최종 보고서는 단일 LLM 호출(One-shot Writing)** 로 완성하는 것이 가장 효과적이다.
- 멀티에이전트 구조는 “하위 주제들이 명확히 분리된 연구 과제”에서 **품질, 속도, 효율성** 모두를 개선할 수 있다. 반면 단일 에이전트는 여러 주제를 동시에 다루려 할 때 **컨텍스트 오염(Context Pollution)** 과 **깊이 저하(Shallow Research)** 문제가 발생한다.
- 멀티에이전트 감독자(Multi-Agent Supervisor)는 요청에 따라 연구 깊이를 조정(tune)
- 감독자(Supervisor)는 두 가지 상황 모두를 유연하게 처리할 수 있습니다:
- 간단한 요청 → **단일 에이전트(single-threaded)** 로 빠르게 처리
- 복잡한 요청 → **하위 에이전트(sub-agents)** 를 여러 개 생성해 병렬 연구 수행
- context engineering :
- **대화 이력 압축 (Chat History Compression) :** 이전 메시지를 그대로 유지하지 않고,핵심 내용만 요약하여 **연구 브리프(Research Brief)** 형태로 압축
- **하위 에이전트의 결과 정제 (Sub-Agent Pruning) :** 각 하위 에이전트(Sub-Agent)는 연구 결과를 감독자(Supervisor)에게 반환하기 전에 **불필요한 토큰 및 관련 없는 정보**를 제거(prune)
- Langsmith + 코드로 구조 살펴보기
//유의 사항
supervisor, researcher (ChatOpenAI랑 연동) - 지시를 내리는 LLM
supervisor_tools, researcher_tools - 그 지시를 수행하는 실행계층 손발
- `clarify_with_user`
- `write_research_brief`
- 간단한 프롬프트를 아래와 같이 확장해서 입력함
원본 프롬프트 : SK hynix와 삼성전자의 CXL 메모리 관련 최신 특허 동향을 비교·분석하고, 핵심 차별성과 리스크를 정리해줘. 표와 출처 포함, 한국어로.
확장본 :
나는 2025-10 기준으로 SK hynix와 삼성전자의 CXL(Compute Express Link) 기반 메모리 관련 최신 특허 동향을 비교·분석하고, 핵심 차별성과 리스크를 한국어로 정리하고자 한다. 조사·분석 범위와 산출물은 다음과 같다.
1. 범위와 기간
- 기술 범위: CXL 메모리 전반(예: CXL Type 3 메모리/메모리 확장 모듈·CMM, 메모리 풀링/스위칭, 캐시 일관성/프로토콜 처리, 메모리 컨트롤러/브리지/스위치, PHY/SerDes 및 PCIe 5.0/6.0 연계, RAS/ECC/에러 처리, 보안/IDE, QoS/모니터링/텔레메트리, 소프트웨어/펌웨어 스택, 전력/열/폼팩터 관련 설계). CXL 1.x/2.0/3.x 버전 관련 특허 포함.
- 기업 범위: SK hynix 및 Samsung Electronics(필요 시 양사 계열/자회사 명의 출원 포함; 동명이인/계열 식별은 특허 패밀리·주소지·발명자 등을 통해 교차 검증).
- 기간: 최신 자료 중심으로 분석하되, 우선 최근 3~5년(대략 2021–2025) 출원·등록 건에 가중치를 두고 과거 중요 선출원은 맥락상 포함. 정확한 연도 범위는 최신성 확보를 최우선으로 하여 개방형으로 처리.
- 관할권: 글로벌(한국 KR, 미국 US, 유럽 EP, 중국 CN, 일본 JP, PCT 등). 공개공보·등록특허 모두 포함.
1. 검색·식별 방법
- 키워드: “CXL”, “Compute Express Link”, “CXL 메모리/메모리 모듈/메모리 익스팬더/메모리 풀링/스위치”, “Type 3”, “coherent/coherency/캐시 일관성”, “RAS/ECC”, “IDE/security”, “QoS/monitoring/telemetry”, “PCIe 5.0/6.0”, 한국어·영문 병행.
- 분류코드: 관련 IPC/CPC(예: G06F, H04L 등) 활용해 키워드 미기재 CXL 연관 출원 보완. CXL 명시 없이 PCIe/메모리 인터커넥트만 언급된 건은 기술 맥락을 확인 후 포함 여부 판단 및 ‘불확실’로 플래그.
- 패밀리 기준: INPADOC 패밀리 단위로 중복 제거, 최초 우선일·주요 관할 등록 여부 정규화.
1. 비교·분석 지표
- 양사별 동향: 연도별 출원·등록 추이, 관할 분포, 패밀리 규모, 독립청구항 길이/항수(대략적 범위), 주요 발명자/연구거점, 상호 인용/전방·후방 인용, 기술세부(상기 기술 분류)별 포트폴리오 열지도.
- 대표 특허: 각 사 핵심·영향력 높은 특허 10–20건 선정(번호, 제목, 최초 우선일, 현재 법적 상태, 주요 청구 포인트 요약, 해당 CXL 버전·기능 매핑).
- 표준 연계: CXL 사양(1.x/2.0/3.x)과의 맵핑, 표준필수특허(SEP) 가능성 정성 평가(가능한 범위 내, 공식 SEP 선언 정보가 있으면 명시). CXL 컨소시엄 IP 정책에 따른 라이선스/FRAND 관련 고려사항 개괄.
1. 핵심 인사이트 도출
- 차별화 포인트: 기술 초점의 차이(예: 모듈·컨트롤러·스위치·RAS·보안 등), 포괄 범위/청구 전략, 제품화 연계성(CMM, 메모리 익스팬더 등)과 시장 적용성, 패밀리·관할 전략 차이.
- 리스크: 상호 FTO(자유실시) 리스크, 청구 중첩/분쟁 잠재성, 무효/선행기술 혼잡도 위험, 타사(IP 코어/PHY/컨트롤러 공급사 등) 의존 리스크, 관할권별 집행 가능성/공격·방어 취약지점, 표준정책/라이선스 의무로 인한 수익화 제약. 공개된 분쟁·이의신청·IPR/무효심판 이력 확인.
1. 산출물 형식(한국어)
- 비교 표: 지표별(출원·등록 추이, 관할, 기술 분류, 인용, 대표 특허 등) 정리 표.
- 핵심 차별성과 리스크 요약 표.
- 필요 시 간단한 타임라인/열지도(표 형태로 대체 가능)와 함께, 각 주장에 대한 근거 출처 링크 명시.
1. 우선 출처(가능한 1차/공식 문서 우선, 한국어 자료 우대)
- 특허 데이터베이스: KIPRIS(특허정보넷), WIPO PATENTSCOPE, EPO Espacenet, USPTO, Google Patents, The Lens. 법적 상태는 각 관할 공식 포털 참고.
- 표준/기술 문서: CXL Consortium 공식 사양/리소스.
- 기업 1차 자료: SK hynix·Samsung 공식 보도자료, 기술 백서, 연차/IR 자료.
- 필요 시 한국어 전문매체 기사(예: 전자신문, 머니투데이 등)는 보조적 근거로 활용.
미지정 사항은 개방형(대표 특허 건수, 분석 기간 세부 범위, 세부 지표 가중치 등)으로 두되, ‘최신성’과 객관적 재현 가능성을 최우선으로 판단한다.
- `research_supervisor`
- 도구 호출 관련 프롬프트 전달
```bash
당신은 **연구 감독자(Research Supervisor)** 입니다. 당신의 역할은 **"ConductResearch"** 도구를 호출해 연구를 수행하는 것입니다. 참고로, 오늘 날짜는 **2025년 10월 10일 금요일 (Fri Oct 10, 2025)** 입니다.
<Task>
사용자가 전달한 **전체 연구 질문**을 대상으로 **"ConductResearch"** 도구를 호출하여 연구를 수행하는 데 집중하세요.
도구 호출로부터 반환된 연구 결과에 **완전히 만족**하면, 연구가 끝났음을 표시하기 위해 **"ResearchComplete"** 도구를 호출하세요.
</Task>
<Available Tools>
다음 세 가지 주요 도구에 접근할 수 있습니다:
1. **ConductResearch**: 전문 하위 에이전트들에게 연구 작업을 위임
2. **ResearchComplete**: 연구 완료를 표시
3. **think_tool**: 연구 중 **성찰 및 전략 수립**에 사용
**중요: ConductResearch를 호출하기 전에 반드시 think_tool로 접근 방식을 계획하고, 각 ConductResearch 호출 이후에도 진행 상황을 평가하세요. think_tool은 다른 도구와 병렬로 호출하지 마세요.**
</Available Tools>
<Instructions>
**시간과 자원이 제한된 연구 매니저**처럼 사고하세요. 아래 단계를 따르십시오:
1. **질문을 주의 깊게 읽기** — 사용자가 **정확히 어떤 정보**를 필요한가?
2. **연구 위임 방식 결정** — 질문을 면밀히 검토하고 **어떻게 위임**할지 정하세요. **동시에 탐색 가능한 독립 경로**가 있는가?
3. **각 ConductResearch 호출 이후 일시 정지하고 평가** — 지금으로 **답변이 충분한가?** 무엇이 **아직 부족한가?**
</Instructions>
<Hard Limits>
**작업 위임 예산** (과도한 위임 방지):
* **단일 에이전트 선호** — 병렬화 기회가 명확하지 않다면 단순화를 위해 **한 명**의 에이전트를 사용
* **자신 있게 답할 수 있으면 중지** — 완벽주의로 계속 위임하지 말 것
* **도구 호출 제한** — 적절한 출처를 찾지 못할 경우라도 **ConductResearch와 think_tool 합산 6회** 호출에서 반드시 중단
**반복(iteration)당 최대 병렬 에이전트 10개**
</Hard Limits>
<Show Your Thinking>
**ConductResearch 호출 전**, **think_tool**을 사용해 접근 방식을 계획하세요:
- 작업을 **더 작은 하위 작업**으로 나눌 수 있는가?
**각 ConductResearch 호출 후**, **think_tool**로 결과를 분석하세요:
* **핵심 정보**는 무엇을 찾았는가?
* **무엇이 부족**한가?
* **포괄적으로 답변**하기에 충분한가?
* **추가 위임**이 필요한가, 아니면 **ResearchComplete**를 호출할 것인가?
</Show Your Thinking>
<Scaling Rules>
**단순 사실 확인, 목록, 순위**는 **단일 하위 에이전트**로 처리:
- *예:* 샌프란시스코 상위 10개 커피숍 목록 → **에이전트 1명**
**사용자 요청에 비교가 포함**되면 비교 대상 **각 요소마다 에이전트 1명**:
* *예:* OpenAI vs Anthropic vs DeepMind의 AI 안전 접근 비교 → **3명 에이전트**
* **명확·독립·겹치지 않는** 하위 주제로 위임
**중요한 주의사항:**
* 각 **ConductResearch 호출은 해당 주제 전용** 연구 에이전트를 생성
* **최종 보고서는 별도의 에이전트**가 작성 — 당신은 **정보 수집**만 하면 됨
* **ConductResearch 호출 시, 완전한 독립 지시문**을 제공 — 하위 에이전트는 **다른 에이전트의 작업을 볼 수 없음**
* **약어/두문자어 사용 금지** — 연구 질문은 **매우 명확하고 구체적**이어야 함
</Scaling Rules>
```
- 3개의 tool로 연결됨
1. `ConductResearch`: 전문 하위 에이전트들에게 연구 작업을 위임
2. `ResearchComplete`: 연구 완료를 표시
3. `think_tool`: 연구 중 **성찰 및 전략 수립**에 사용
- `supervisior`
- 각각 supervisor tool에게 넘길 research_topic 쿼리 생성
- conduct research 1: "Research SK hynix patent activity related to Compute Express Link (CXL)”
- conduct research 2: “Research Samsung Electronics patent activity related to Compute Express Link (CXL)”
- research iteration으로 몇번 반복수행이 되었는지 표기 되어있음
- `supervisor_tools` : 실제 tool 호출 단계 - output으로 ConductResearch tool 호출
- 이때 각각 tool id와 역할을 부여해서 넘기기
ex. tool id : 1, arguments : "Research SK hynix patent ”
tool id :2, arguments : “Research Samsung Electronics patent”)
이렇게 나눠서 부여하기
- `researcher` - tavily serach 쿼리 생성
- `researcher_tool` - tavily search 수행 후 응답 받기
- 이후 `runnablesequence` → `ChatopenAI` → `RunnavleLambda` 를 반복하면서 다단계 탐색을 진행
- 실제 researcher tool code
```bash
# Step 3: Check late exit conditions (after processing tools)
exceeded_iterations = state.get("tool_call_iterations", 0) >= configurable.max_react_tool_calls
research_complete_called = any(
tool_call["name"] == "ResearchComplete"
for tool_call in most_recent_message.tool_calls
)
if exceeded_iterations or research_complete_called:
# End research and proceed to compression
return Command(
goto="compress_research",
update={"researcher_messages": tool_outputs}
)
# Continue research loop with tool results
return Command(
goto="researcher",
update={"researcher_messages": tool_outputs}
)
```
- 답변이 부족한 경우에는 researcher로 가고, 충분한 경우나 시도횟수 이상인 경우에는 “compress_research(요약)” 으로 가기
- 우리가 추가로 코드 적용해야할 부분
- Rag tool 추가하기 - src/utils.py에서 get_all_tools 함수에 추가하면 됨
- MCP ppt 만들기 추가
카테고리 없음
odr study
728x90
반응형
댓글