📖 사용 가이드

추론 서버(dispatcher.decide)를 브라우저에서 검증하고, 사용자 튜닝 시나리오와 마이레시피·대화 로그를 관리하는 작업 콘솔입니다.

1. 사용자 튜닝 — 멀티턴 시나리오(사용자↔AI) 등록. git 관리 데이터 파일을 편집합니다.
2. 채팅 검증 — 앱(/api/v2/decide)과 같은 코드 경로로 발화를 보냅니다.
3. 마이레시피 — 사용자별 즐겨찾기 슬롯 5칸 조회·수정.
4. 로그 — 운영 기기의 대화 로그 조회·다운로드.

🗣️ 사용자 튜닝 — 멀티턴 시나리오

• 개념 — 들어온 발화가 시나리오의 사용자 메세지와 의미가 맞으면, 그 다음 AI 턴을 재생합니다. 매칭은 Gemini Pro 로 판정하며 도메인·인텐트 분류보다 먼저 일어납니다.
• 턴 type — AI 턴이 recipe 면 recipe_data 로 레시피가 추출되고, clarify 는 되묻기·안내입니다. 도메인이 water 인 시나리오는 정수 응답으로 재생됩니다.
• 저장 위치 — ECS 에서는 DynamoDB CuckooRecipe-UserTuning-{env}, 테이블이 설정되지 않은 로컬 실행은 barista_user_tuning.jsonl 파일입니다.
• 활성화 — 기본 비활성입니다. 검증 후 ECS 환경변수 ENABLE_USER_TUNING=true 로 켭니다.

💬 채팅 검증

• 앱과 같은 dispatcher.decide 를 통과하므로 결과가 실제 앱과 같습니다.
• session 을 바꾸면 대화 컨텍스트도 분리됩니다. 세션은 컨테이너 메모리에 있어 재배포하면 사라집니다.
• 응답 패널의 decision JSON 에서 domain·intent_id·data 로 어느 경로를 탔는지 확인합니다.

🌀 공기청정기 · 로봇청소기 · 스마트플러그 (CSV 7단계)

• 어디서 보나 — [💬 채팅 검증] 에서 그냥 말하면 됩니다. 기본은 등록 기기 전체로 보내고, 앱과 똑같이 dispatcher 가 발화를 보고 기기를 고릅니다. 어디로 갔는지는 답변 아래 메타 줄(예: 공기청정기 · AIR · command)에 나옵니다.
• 등록 기기 (registered_devices) — 그 집에 무엇이 있느냐에 따라 판정이 달라집니다. 체크를 풀면 그 기기가 없는 집이 되어, 해당 발화는 다른 기기로 가거나 양보합니다. 예를 들어 공기청정기를 빼고 "먼지가 많은 것 같아" 라고 하면 동시 동작 대신 로봇청소기만 돕니다. 전부 풀면 한 대도 없는 집이 되어 어떤 발화도 점유하지 않습니다.
• 문맥이 붙는 발화 — "너무 시끄러워" 처럼 두 가전 데이터에 모두 있는 표현은 직전 턴의 기기로 갑니다. 문맥 없이 처음부터 말하면 어느 기기인지 알 수 없어 정수기 피드백 되묻기로 빠지며, 실제 앱도 같습니다.
• 두 기기가 함께 도는 발화 — "먼지가 많은 것 같아", "손님 오시기로 했어" 처럼 양쪽에 다 해당하는 말은 공기청정기와 로봇청소기가 동시에 움직입니다. 메타 줄이 공기청정기 + 로봇청소기 · AIR+CLN 으로 나오고 data 배열에 기기별 명령이 [0], [1] 로 각각 들어갑니다. 어떤 말이 동시 동작인지는 container/ai/data/appliance/data/admin/multi_scenarios.csv 가 정합니다.
• 무엇이 도는가 — 데이터 정본 기반 7단계 파이프라인(domain → intent → slot → DM → dataset → mapping → firmware)이 대부분 LLM 호출 없이 판정합니다. 응답 패널의 domain 이 AIR/CLN/PLG 이면 이 경로를 탄 것입니다.
• 스마트플러그(CSP-1010TNW, PLG) — 이 기기는 자기 자신이 아니라 꽂혀 있는 기기를 켜고 끕니다. 그래서 제어 어휘가 "켜/꺼/예약" 뿐인 대신 상황 발화가 본체입니다("이제 외출할게", "다림질 끝났어", "충전 다 됐어"). 상황만 듣고 추론해 전기를 끊거나 넣는 발화는 바로 실행하지 않고 되묻습니다 — 무엇이 꽂혀 있는지 서버는 모르기 때문입니다. 반대로 "플러그 꺼줘" 처럼 직접 시킨 말과, 과열·탄 냄새 같은 안전 발화는 바로 실행합니다.
• 기기 상태 (선택) — 상태 조회·에러 안내·추천은 앱이 보내주는 device_status 가 있어야 열립니다. 실기기 없이 검증할 수 있도록 프리셋(공기청정기 · 미세먼지 나쁨 등)으로 상태를 흉내 냅니다. (상태 없음) 이면 해당 발화는 의도적으로 양보합니다. 프리셋은 등록된 기기의 것만 나오며, 상태를 걸어도 그 기기와 무관한 발화는 여전히 다른 기기로 갑니다(프리셋은 기기를 고르는 스위치가 아닙니다).
• 문구·명령 수정 — 코드가 아니라 기기별 데이터 패키지(container/ai/data/<기기>/)를 고칩니다. 행 단위 표는 data/admin/*.csv(관리자가 고치는 상황·발화·증상)와 data/device/*.csv(명령·상태·펌웨어 에러), 슬롯·피드백은 루트의 slots.yaml·feedback.yaml 입니다. 기기를 넘나드는 동시 동작 선언만 data/appliance/data/admin/multi_scenarios.csv 에 따로 있습니다. 편집 가이드는 docs/appliance/csv_guide.md.
• 운영 중 끄기 — ECS 환경변수 APPLIANCE_ROUTE (all / off / air,robot,plug 중 일부) 로 그 기기 경로만 끌 수 있습니다. 꺼진 기기는 제어되지 않고 Lambda 가 되묻기 안내만 합니다.
• 로그 — 운영 대화는 [📑 로그] 탭에서 mode air/cln 으로 조회합니다. 이 채팅 검증 화면의 턴은 저장하지 않습니다(무로그 정책).

⭐ 마이레시피 (사용자 슬롯)

• 사용자별 즐겨찾기 레시피 5칸. "내 레시피 1번으로 추출", "이거 2번에 저장" 같은 발화로 호출됩니다.
• 저장소는 DynamoDB CuckooRecipe-MyRecipe-{env} 입니다. 채팅 검증의 기본 사용자는 device:AAA 입니다.
• 사용자 ID 는 보통 user.user_id, 없으면 device:<device_id> 로 폴백됩니다.

📑 로그 — 대화 로그

• 저장 대상 — 앱 경로(/api/command → ECS)의 대화만 저장합니다. 채팅 검증 화면의 대화는 저장하지 않습니다.
• mode — barista(정수기) 외에 air(공기청정기) · cln(로봇청소기) 등이 있습니다. 가전 7단계 턴은 진입점에서 직접 기록합니다.
• 저장 단위 vs 조회 단위 — 저장은 턴(메시지) 단위(user 1턴·ai 1턴 각 1아이템), 조회는 conversation_id 로 그룹핑해 대화 단위로 보여줍니다. 같은 device_id 에서 대화 분할 간격(기본 30분) 이상 공백이면 새 대화로 나뉩니다.
• 검색 — device_id(또는 [🔍 디바이스] 팝업에서 선택) · device_model · mode · 날짜 기간 범위(KST 입력 → UTC 조회). 결과 1페이지 기본 최근 500건.
• 다운로드 — .json(decision/meta/spoken·raw text 전부 보존 + KST 시각) / .log({KST} [device_id] [session_id] [user|ai] 메시지 평문). 현재 검색 조건 전체를 서버에서 순회해 내보냅니다.
• 보존기간(retention) — [⚙ 보존/대화설정]에서 일수 입력(0=무기한). ⚠️ 기본 무기한이며 변경 즉시 신규 로그에 TTL 적용(기존 데이터 소급 미적용).
• 저장소 — DynamoDB(CONVERSATION_LOG_TABLE). 테이블이 설정되지 않은 로컬 실행은 JSON 파일에 저장합니다. 저장 실패는 응답에 영향을 주지 않습니다.