← Docs hub

A2A 지식 그래프·RAG 연동 설계

A2A는 요청의 담당과 실행 계획을 정하고, 지식 그래프는 관련 관계를 좁히며, RAG는 원문 근거를 찾는다. TaskManager는 승인된 계획을 실제 완료까지 관리한다. 모든 요청을 RAG와 계획 수립기에 차례로 통과시키지 않는다. 필요한 요청에 필요한 단계만 사용한다.

이 설계는 다음 다섯 질문에 답한다.

1. 자연어 요청은 어떤 기준으로 네 실행 경로 중 하나를 선택하는가?
2. 경로 선택·계획 모델과 전문 업무 모델은 언제 호출되는가?
3. 지식 그래프와 RAG는 각각 무엇을 제공하는가?
4. 사용자가 답을 듣는 시간과 기기 동작이 끝나는 시간은 어떻게 다른가?
5. 현재 구현을 깨뜨리지 않고 어떤 순서로 연결하고 검증할 것인가?

제1부. 선택적 연동이 필요한 이유

1. 하나의 요청에 모든 단계를 적용할 필요는 없다

“필터 교체 주기를 알려줘”는 제품 지식이 필요하다. “안방으로 이동해”는 실행 계획과 기기 상태가 중요하다. 앱이 이미 returnToStation 작업 계약을 보냈다면 자연어 해석 자체가 필요하지 않다. 이 세 요청을 모두 같은 검색과 모델 호출 순서로 처리하면 지연과 비용이 늘고, 검색 결과가 실행 판단에 부당하게 개입할 수 있다.

반대로 단순 규칙만으로 처리하면 설명·현재 상태·기기 실행·복합 목표의 경계를 놓치기 쉽다. 따라서 이 구조의 핵심은 요청의 형태와 의미를 먼저 구분하고, 필요한 처리만 선택하는 것이다.

2. 채택하는 구조

현재 자연어의 담당 경로는 A2A가 정한다. 1차 연결에서는 A2A가 DQR로 선택한 요청 뒤에 문서 RAG를 붙인다. 목표 구조에서는 RAG 앞에 제품 지식 그래프의 관계 투영을 추가한다. 지식 그래프가 질문과 관련된 기능·부품·정책·오류 관계를 좁히고, RAG가 그 관계를 뒷받침하는 원문을 찾는다.

현재 call_device_qna_rag()는 이름과 달리 S-029 RAG 실행 환경에 연결되지 않았다. 사전 등록 질문 연결을 먼저 확인하고, 일치하지 않으면 DQR용 생성형 AI 또는 안전한 대체 응답으로 끝난다. 1차 연결은 이 전문 처리부에 실제 문서 검색을 붙이는 작업이다. 즉, S-029 검색기는 로컬 실험까지 완료됐지만 현재 A2A 실행 환경에 연결되지 않았다.

그림 1 · 현재 경로 선택 권한은 유지한다. DQR 뒤에 문서 RAG를 연결하고, 제품 지식 그래프는 다음 단계에서 관련 관계를 좁히는 역할로 추가한다. SVG 크게 보기

용어를 먼저 정리하면

제2부. 현재 A2A와 네 실행 경로

3. 현재 자연어 처리 흐름

자연어 입력
  → STT 안전 경계·현재 상태 빠른 처리
  → 기능 목록 기반 후보 + 비개입 관찰 후보 + 사전 판정
  → 통합 경로 선택·계획 모델
  → 후보 순위와 제품 경계 보정
  → owner_selection + typed steps
  → 전문 처리 또는 TaskManager 작업 흐름

A2A_INLINE_UNIFIED_ROUTER=true가 기본이면 기능 후보를 만들기 위한 별도 생성형 AI는 호출하지 않는다. 통합 모델이 담당 주체와 실행 계획을 함께 생성하고, 이후 제품 경계 보정과 계획 검증이 결과를 확인한다.

현재 선택 권한

RAG는 처리 경로를 결정하지 않는다. 검색은 DQR이 선택된 뒤에 제품 지식 근거를 제공한다.

4. 네 실행 경로

네 경로는 독립된 라우터 네 개가 아니다. 입력 계약을 먼저 확인하고, 자연어라면 현재 A2A가 B·C·D를 구분한다.

그림 2 · A는 모델 호출 없이 직행한다. 자연어 B·C·D는 기본 경로 모델을 공유하고, 선택된 전문 처리와 재계획에서만 추가 호출이 발생한다. SVG 크게 보기

경로 A · 구조화 실행 계약 직행

구조화 요청 → 형식·권한·정책 검증 → 실행 계획 변환 → TaskManager

• 자연어 의미 해석과 제품 문서 검색이 필요하지 않다.
• 필드가 부족하거나 지원 기능이 없으면 추측하지 않고 거부한다.
• 기존 MQTT·레거시 명령은 기존 경로를 유지한다.
• 자연어 문장을 키워드 규칙만으로 A에 넣지 않는다.

경로 B · 기기 지식 근거 답변

현재  자연어 → A2A가 DQR 선택 → 사전 등록 질문 또는 DQR 생성 모델
1차   자연어 → A2A가 DQR 선택 → 제품 문서 RAG → 답변 생성기
목표   자연어 → A2A가 DQR 선택 → 지식 그래프 관계 투영
                                  → 문서 RAG
                                  → 근거 답변 생성기

• 1차 연결에서는 DQR·ODL·DEF·FRG 경계를 정하기 위해 계획 수립기가 필요하다.
• 검색 결과는 근거 위치, 출처와 answerability를 반환한다.
• 근거가 부족하거나 실행 의도가 섞이면 DQR에서 억지로 끝내지 않는다.
• 계획 수립기를 거치지 않아도 생성형 AI를 쓸 수 있다. 향후 확실한 DQR이 경로 모델을 우회해도, 검색 근거를 자연스럽게 구성하는 답변 생성기는 사용할 수 있다.

경로 C · 검증된 단일 기능·작업 흐름

자연어 → 경로 선택·계획 → 구조화 단계 → 계획 검증 → TaskManager

“안방 청정 후 스테이션 복귀”는 안방 이동 → 이동 완료 대기 → 청정 → 완료 조건 확인 → 스테이션 복귀로 변환된다. 현재는 계획 수립기가 이 구조를 만든다. 검증된 작업 흐름으로 자연어를 바로 보내는 일반 의미 해석기는 아직 없으므로, 모델 없는 자연어 직행은 현재 기능이 아니다.

경로 D · 통합 경로 선택·계획 수립

조건, 여러 전문 영역, 앞 단계 결과 의존성, 확인 질문 또는 의미 재계획이 필요한 요청이다.

요청 + 기능 후보 + 필요한 문맥
  → 담당 주체(owner_selection) + 실행 계획(execution_plan)
  → 계약 검증
  → 전문 처리 / TaskManager

“청정이 끝나면 오늘 뉴스를 요약해줘”는 청정 완료 증거를 받은 뒤에만 뉴스 검색 단계를 연다. 뉴스 검색은 계획 시점이 아니라 해당 단계가 실행될 때 시작한다.

LLM은 경로 D에서만 사용되는가?

아니다. 빠른 처리로 끝나지 않은 자연어 B·C·D는 같은 경로 선택·계획 모델을 기본 1회 거친다. D는 LLM을 처음 사용하는 곳이 아니라 복합 의존관계와 의미 재계획으로 추가 호출 가능성이 가장 큰 경로다.

지식 그래프 조회와 RAG 검색 자체는 생성형 AI 호출이 아니다. 관계와 문서 근거를 사용자 문장으로 구성할 때 전문 업무 모델을 사용할 수 있다.

계획 수립기가 필요한 경우

계획 수립기가 필요하지 않은 경우

정상 진행 중에는 생성형 AI를 다시 호출하지 않는다. 정해진 재시도, 제한 시간, 보상 동작과 다음 단계 진행은 TaskManager가 처리한다. 새로운 의미 선택이 필요할 때만 계획 수립기를 다시 연다.

제3부. 지식과 실행의 책임 경계

5. 지식 그래프가 필요한 이유

RAG는 질문과 비슷한 원문을 찾는 데 강하다. 그러나 기능 사이의 관계를 이어야 하는 질문은 문장 유사도만으로 부족할 수 있다.

“프라이버시 모드에서 바이탈사인을 쓸 수 있어?”에는 다음 관계가 필요하다.

프라이버시 모드 ──카메라 사용 제한──▶ 카메라
바이탈사인 측정 ──카메라 필요──────▶ 카메라
제품 설명서 ─────위 관계의 근거────▶ 문서 위치

지식 그래프가 프라이버시 모드 → 카메라 제한 → 바이탈사인 영향을 연결하고, RAG가 각 관계를 뒷받침하는 원문을 찾는다. 답변 생성기는 관계와 원문을 함께 사용해 이유를 설명한다.

전체 그래프를 모델에 넣지 않고 이번 요청에 필요한 관계만 투영한다. 이 작은 관계 묶음이 scoped projection이며, 검색 범위와 계획 문맥을 줄이는 핵심 입력이다.

그림 3 · 지식 그래프는 관계를 좁히고 RAG는 원문을 찾는다. 계획 수립기와 검증기가 실행 구조를 결정하며 TaskManager가 실제 완료를 관리한다. SVG 크게 보기

6. 계층별 책임

같은 정보처럼 보여도 저장 위치가 다르다

이 경계를 섞으면 오래된 상태가 지식으로 남거나 검색 문장이 실행 명령으로 바뀔 수 있다. 검색 점수와 지식 관계는 실행 권한이 아니다.

결과 환류와 화자 기반 개인화

지식 그래프의 다음 확장은 사람을 알아보는 데서 끝나지 않는다. 누가 요청했는지, 그 사람에게 어떤 기억을 읽어도 되는지, 이번 실행에서 무엇이 실제로 확인됐는지를 연결해야 개인화가 다음 요청에도 안전하게 이어진다.

여기서 회귀는 온라인 모델 재학습이 아니다. 실행 결과와 사용자 수정을 출처가 있는 기억 후보로 되돌리고, 검증된 관계만 다음 scoped projection에 포함하는 결과 환류다. 모델 가중치를 실시간으로 바꾸거나 단일 성공을 선호로 확정하지 않는다.

그림 4 · 화자 판정 근거는 개인 문맥의 읽기 범위를 좁히고, 목표·계획·실행 결과는 검증 관문을 거쳐 다음 개인화로 돌아간다. Voice ID와 검색 점수는 권한이 아니며, 현재 발화가 항상 과거 기억보다 우선한다. SVG 크게 보기

현재와 목표 구조

Profile Cloud와 User KG는 목표 구조다. 현재 코드가 화자별 장기 지식 그래프를 자동으로 쓰거나, 실행 결과만으로 개인 선호를 승인한다고 해석하면 안 된다.

개인화 폐루프

1. 온디바이스는 identified, unknown, ambiguous, multi_speaker와 Voice ID, 신뢰도, 모델 버전을 화자 판정 근거로 보낸다. 원본 음성과 임베딩은 보내지 않는다.
2. Identity Resolver는 Voice ID를 Person Profile과 연결하고 개인화 동의·역할·유효 상태를 확인해 개인 범위를 만든다.
3. 문맥 서비스는 해당 사람에게 허용된 명시 선호·공간 별칭과 공용 제품 지식, 최신 StateMirror만 묶어 범위 한정 문맥을 만든다.
4. 라우터와 플래너는 현재 요청을 먼저 해석하고 필요한 문맥만 사용한다. 현재 발화가 가장 높은 우선순위이며 과거 선호는 보조 근거다.
5. TaskManager와 기기 도메인은 실행 상태와 완료 증거를 반환한다. ACK나 TTS 안내를 성공으로 학습하지 않는다.
6. 검증 관문은 결과를 목표·단계·화자에 귀속한 뒤 후보 → 검증 → 승인 또는 stale/revoked로 전이한다. 승인된 저위험 관계만 다음 개인화에 사용한다.

unknown·ambiguous·multi_speaker는 전체 요청의 실패가 아니다. 개인화만 끄고 기본 경로로 처리하며, 민감 정보 조회나 권한이 필요한 동작은 확인 또는 별도 인증으로 전환한다. 화자 식별은 권한 승인이 아니다.

개인화가 실제로 바꾸는 것

이 구조의 직접 효과는 개인화 정확도만이 아니다. 사용자별 그래프 전체를 프롬프트에 넣지 않고 필요한 관계만 투영하므로 입력 문맥과 토큰을 줄이고, 잘못된 사람의 기억을 섞는 위험을 낮추며, “왜 이 공간과 기능을 선택했는가”를 관계 경로로 설명할 수 있다.

확장 영역과 안전 경계

단일 성공을 선호로 확정하지 않는다. 사용자 취소를 기능 실패로 기록하지 않으며, Voice ID만으로 보안·건강·개인 일정 권한을 열지 않는다. 상세한 기억 상태와 동의·삭제 계약은 Experience Goal × 지식 그래프와 보이스 프로필 개발 문서를 따른다.

제4부. 시간과 성능

7. 사용자가 기다리는 두 개의 시계

시스템 시간은 하나가 아니다.

• 첫 응답 시간: 요청을 받은 뒤 접수·답변·실행 시작 안내가 사용자에게 도달하기까지
• 실제 완료 시간: 이동·청정·측정·앱 세션 등 물리 작업의 최종 완료 증거가 오기까지

첫 응답이 끝나도 작업은 계속될 수 있다. 요청 접수 응답(ACK)은 실제 완료가 아니다. 이동은 도착, 청정은 정지 또는 정의된 완료 조건, 측정은 사용자 완료·취소 같은 terminal evidence가 확인되어야 끝난다.

그림 5 · 현재 실측값과 설계 예상 범위를 분리한다. A2A 평균 시간과 RAG p95는 측정 범위가 다르므로 그대로 더해 전체 응답시간으로 사용하지 않는다. SVG 크게 보기

8. 수치의 네 등급

예상치는 실측치가 아니다. 범위의 중앙값도 SLA나 보장시간으로 사용하지 않는다. 독립 계측이 쌓이면 설계 예상은 p50·p95 실측으로 교체한다.

단계별 소요시간

A2A 클라우드 판단 전체의 실측 분포는 평균 3.267초, 중앙값 3.208초, 느린 5% 경계 5.688초, 최댓값 8.942초다. 이 값은 Planner 단독 시간이 아니라 router·planner·추가 검토와 결과 생성이 포함된 전체 시간이다.

물리 동작 완료 예상

물리 완료는 클라우드 지연과 성격이 다르다. 아래 범위는 UX와 timeout 설계를 위한 초기 예상이며, 이동 거리·환경·사용자 행동에 따라 크게 달라진다.

이동 4분, 청정 3분, 측정 10분은 일반적인 평균값이 아니라 상한 보호를 포함한 운영 범위다. 제품별 실기기 p50·p95가 쌓이면 동작·공간·상태별로 다시 나눈다.

경로별 임계 경로

경로 B의 목표 시간이 단순히 3.267초 + 1.216초인 것은 아니다. 두 값은 각각 평균과 p95이고 측정 범위도 다르다. 지식 그래프 투영, 답변 생성, 네트워크는 아직 빠져 있다. 따라서 RAG 1.2초 + 계획 수립기 3.3초라는 표현은 약 4.5초가 될 수 있다는 산술 예시다. 여기에 관계 투영과 답변 구성을 더해 B 목표 경로를 약 5~6초로 잡았다. D는 넓은 범위로 합치지 않고 기본 계획 3.3초 + 선택적 전문 처리 + 선택적 재계획으로 분리한다. 실제 수치는 병렬화·캐시·전문 모델 호출 여부에 따라 달라진다.

계측 계약

다음 단계부터는 하나의 trace_id 안에서 각 시간을 따로 기록해야 한다.

9. 측정 범위와 현재 근거

S-029는 검색 가능성을 보여주지만 답변 정확도, 지식 그래프 관계 정확도, 경로 정확도를 증명하지 않는다. 지식 그래프 결합과 DQR→RAG 전체 연동 시간은 아직 측정되지 않았다.

제5부. 도입과 검증

10. 단계별 도입 순서

11. 품질 문턱과 중단 조건

12. 우회와 최적화의 경계

모든 요청 앞에 지식 검색을 두거나 검색 유사도로 실행을 확정하는 구조는 기본 경로로 채택하지 않는다. 발화별 예외 규칙을 쌓아 빠른 처리 경로를 만드는 방식도 사용하지 않는다.

부록 A. 연동 계약

A.1 문서 검색 결과

{
  "query_id": "q-...",
  "answerability": "sufficient | insufficient | conflicting",
  "retrieval_evidence": [
    {
      "source_id": "manual-v...",
      "location": "chapter/page/row",
      "claim": "질문을 직접 지지하는 근거"
    }
  ],
  "index_version": "..."
}

근거가 부족하거나 충돌하면 답을 만들지 않고 확인 질문 또는 경로 재검토 사유를 반환한다.

A.2 지식 그래프 관계 투영

{
  "entities": ["privacy_mode", "camera", "vital_sign"],
  "relations": [
    {"from": "privacy_mode", "type": "restricts", "to": "camera"},
    {"from": "vital_sign", "type": "requires", "to": "camera"}
  ],
  "source_refs": ["policy-v3#privacy", "manual-v5#vital-sign"],
  "valid_at": "2026-08-30T10:00:00+09:00"
}

관계 묶음은 출처와 유효 시점을 포함하며, 전체 그래프가 아니라 요청 범위만 전달한다.

A.3 경로 선택과 계획

{
  "owner_selection": {
    "route_family": "DQR",
    "flow_id": "DQR.DQR.device_knowledge_answer",
    "selected_agent": "DQR",
    "selected_skill": "device_knowledge_answer"
  },
  "execution_plan": {
    "steps": [],
    "missing_slots": [],
    "ask_follow_up": false
  }
}

owner_selection은 담당을, execution_plan은 단계와 누락 입력값을 소유한다.

A.4 실행 결과

{
  "workflow_id": "wf-...",
  "step_id": "step-1",
  "status": "COMPLETED | FAILED | BLOCKED | CANCELLED",
  "reason_code": "...",
  "terminal_evidence": ["movement.arrived"],
  "observed_at": "..."
}

단계별 상태와 최종 증거를 합친 묶음은 execution_evidence로 전달한다.

부록 B. 측정 근거

• 현재 경로 선택기: gemini/a2a/planner/main_router_api.py
• 후보 생성과 경계 보정: gemini/a2a/planner/flow_selection_core.py, planner/preclassifier.py
• DQR 전문 처리: gemini/a2a/agents/dqr/api.py
• 실행 환경: gemini/a2a/runtime/orchestrator.py, runtime/device_task_mapper.py
• A2A 기준선: artifacts/a2a_planner_taskmanager_non_motion_60_20260808-r12-shadow.json
• DQR 검색 실험: dqr_rag_service_guide.html의 S-029 검색·메모리·적재 시간

관련 문서

• Experience Goal × 지식 그래프
• TaskManager 기준 사양서

현재 RAG 수치는 로컬 문서 검색 실험 결과다. 실제 DQR→RAG 연동, 지식 그래프 투영, 전문 답변 생성, 네트워크, 동시 처리 자원과 기존 A2A 회귀는 별도로 검증해야 한다.