ODR research

ODR research & reverse engineering

paper 대신 참고 link : https://blog.langchain.com/open-deep-research/

0. ODR pipeline
- scope : 리서치 범위 설정 (user classification, Brief generation)
- research : 실제 리서치 수행 (이때 supervisor 과 sub agent 동작)
- write : 최종 보고서 작성 (one-shot report generation)

https://blog.langchain.com/open-deep-research/

1. Scope
1) User classification (classify with_user 노드): 리서치 요청시에 사용자의 대화를 통해 추가 정보를 묻는 절차 (그러나 코드상으로는 확인이 안됨)

2) Brief generation (write_research_breif): 명확한 질문들 또는 사용자 제공 예시 등을 포함한 대화내용 → research brief로 변환
   ⇒ 이게 보고서 작성의 길잡이 역할로 전 과정에서 수시로 참고
   ⇒ user classification에서 티키타카를 통해 다듬은 명확한 쿼리 형태 (그러나 코드상으로는 확인이 안됨)

2. Research
3) research supervisor (supervisor): 리서치 작업을 여러 하위 주제로 나눌 수 있는지 판단하고 적절한 수의 sub-agent를 할당 (병렬로 작업 수행하도록)

 

4) research sub-agent (supervisor_tools): 각 하위주제에 대해서 집중하여 리서치 수행
   a) tool-calling loop (MCP, Tavily 같은 웹검색)
   b) LLM을 통해 자세한 답변 작성
   c) 추가 정제 단계를 거쳐서 효율적인 연구결과만 판단할 수 있도록 조치

5) Research supervisor iteration
   a) 감독자(Supervisor)는 하위 에이전트(Sub-Agent)들이 수집한 결과물이 연구 브리프(Research Brief)의 전체 범위(Scope of Work)를 충분히 다루고 있는지를 추론(reasoning)
   b) 만약 결과의 깊이가 부족하다면 다시 심층 연구를 하도록 지시
   c) 수집된 연구결과가 2단계 연구 브리프의 요구사항을 충분히 충족한다면, 보고서 작성 단계로 넘어가기

3. write
6) one-shot report generation (final_report_generation): 단 한번의 LLM 호출로 완성된 보고서를 작성
   a) 하위 에이전트들의 반환한 연구 결과를 LLM에 입력
   b) 최종 보고서의 방향은 연구 브리프(Research Brief)에 제시된 목적과 질문에 의해 조정(steered)되고, 하위 에이전트들의 연구 결과를 기반으로 답변

 

4. 추가 연구 및 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)

 

5. Langsmith + 코드로 구조 살펴보기
   (참고) 

   supervisor, researcher (ChatOpenAI랑 연동) - 지시를 내리는 LLM
   supervisor_tools, researcher_tools - 그 지시를 수행하는 실행계층 (손발)

 

1) clarify_with_user

 

2) 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 등). 공개공보·등록특허 모두 포함.

2) 검색·식별 방법
   • 키워드: “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 패밀리 단위로 중복 제거, 최초 우선일·주요 관할 등록 여부 정규화.

3) 비교·분석 지표
   • 양사별 동향: 연도별 출원·등록 추이, 관할 분포, 패밀리 규모, 독립청구항 길이/항수(대략적 범위), 주요 발명자/연구거점, 상호 인용/전방·후방 인용, 기술세부(상기 기술 분류)별 포트폴리오 열지도.

• 대표 특허: 각 사 핵심·영향력 높은 특허 10–20건 선정(번호, 제목, 최초 우선일, 현재 법적 상태, 주요 청구 포인트 요약, 해당 CXL 버전·기능 매핑).
• 표준 연계: CXL 사양(1.x/2.0/3.x)과의 맵핑, 표준필수특허(SEP) 가능성 정성 평가(가능한 범위 내, 공식 SEP 선언 정보가 있으면 명시). CXL 컨소시엄 IP 정책에 따른 라이선스/FRAND 관련 고려사항 개괄.

4) 핵심 인사이트 도출
   • 차별화 포인트: 기술 초점의 차이(예: 모듈·컨트롤러·스위치·RAS·보안 등), 포괄 범위/청구 전략, 제품화 연계성(CMM, 메모리 익스팬더 등)과 시장 적용성, 패밀리·관할 전략 차이.
   • 리스크: 상호 FTO(자유실시) 리스크, 청구 중첩/분쟁 잠재성, 무효/선행기술 혼잡도 위험, 타사(IP 코어/PHY/컨트롤러 공급사 등) 의존 리스크, 관할권별 집행 가능성/공격·방어 취약지점, 표준정책/라이선스 의무로 인한 수익화 제약. 공개된 분쟁·이의신청·IPR/무효심판 이력 확인.

5) 산출물 형식(한국어)
   • 비교 표: 지표별(출원·등록 추이, 관할, 기술 분류, 인용, 대표 특허 등) 정리 표.
   • 핵심 차별성과 리스크 요약 표.
   • 필요 시 간단한 타임라인/열지도(표 형태로 대체 가능)와 함께, 각 주장에 대한 근거 출처 링크 명시.

6) 우선 출처(가능한 1차/공식 문서 우선, 한국어 자료 우대)
   • 특허 데이터베이스: KIPRIS(특허정보넷), WIPO PATENTSCOPE, EPO Espacenet, USPTO, Google Patents, The Lens. 법적 상태는 각 관할 공식 포털 참고.
   • 표준/기술 문서: CXL Consortium 공식 사양/리소스.
   • 기업 1차 자료: SK hynix·Samsung 공식 보도자료, 기술 백서, 연차/IR 자료.
   • 필요 시 한국어 전문매체 기사(예: 전자신문, 머니투데이 등)는 보조적 근거로 활용.
   • 미지정 사항은 개방형(대표 특허 건수, 분석 기간 세부 범위, 세부 지표 가중치 등)으로 두되, ‘최신성’과 객관적 재현 가능성을 최우선으로 판단한다

## research_supervisor

도구 호출 관련 프롬프트 전달

당신은 연구 감독자(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 : 연구 중 성찰 및 전략 수립에 사용

  

 

3) supervisor
- 각각 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으로 몇 번 반복 수행이 되었는지 표기 되어있음

4) 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"
- 이렇게 나눠서 부여하기

5) researcher: tavily search 쿼리 생성
6) researcher_tool: tavily search 수행 후 응답 받기

이후 RunnableSequence → ChatOpenAI → RunnableLambda 를 반복하면서 다단계 탐색을 진행

 

실제 researcher tool code (발췌):

# 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(요약)"으로 가기

5. 우리가 추가로 코드 적용해야할 부분
• RAG tool 추가하기 - src/utils.py에서 get_all_tools 함수에 추가하면 됨
• MCP ppt 만들기 추가

# ODR research & reverse engineering 12

 

 

 

Open Deep Research