From b82c71093712eb8b7fbd5f24914a4d9d46dc56de Mon Sep 17 00:00:00 2001 From: happybell80 Date: Sat, 20 Sep 2025 16:50:44 +0900 Subject: [PATCH] docs: Add Bayesian research and update NaverWorks briefing docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Add 베이즈 학문 역사 and 베이지안 논의 종합 research docs - Update NaverWorks daily briefing and cold mail docs - Add 로빙 의도분석 전략 idea doc - Update 베이즈 성장과 관계의 철학 - Update 대화형 점진적 의도 구축 시스템 --- ...25_베이즈_성장과_관계의_철학.md | 9 ++ ...형_점진적_의도_구축_시스템.md | 28 ++++- ..._happybell80_로빙_의도분석_전략.md | 55 +++++++++ ...920_happybell80_베이즈_학문_역사.md | 14 +++ ..._happybell80_베이지안_논의_종합.md | 78 ++++++++++++ research/README.md | 42 ++++--- ...0919_naverworks_slack_02_daily_briefing.md | 68 ++++++----- ...0919_naverworks_slack_03_cold_mail_list.md | 64 +++++----- ...ack_briefing_phase2plus_troubleshooting.md | 115 ++++++++++++++++++ 9 files changed, 389 insertions(+), 84 deletions(-) create mode 100644 ideas/250920_happybell80_로빙_의도분석_전략.md create mode 100644 research/250920_happybell80_베이즈_학문_역사.md create mode 100644 research/250920_happybell80_베이지안_논의_종합.md create mode 100644 troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md diff --git a/100_philosophy/125_베이즈_성장과_관계의_철학.md b/100_philosophy/125_베이즈_성장과_관계의_철학.md index 4550438..d26e505 100644 --- a/100_philosophy/125_베이즈_성장과_관계의_철학.md +++ b/100_philosophy/125_베이즈_성장과_관계의_철학.md @@ -72,6 +72,15 @@ AI는 베이지안 업데이트 루프를 무한히 돌며 확률을 최적화 로빙이 사용자와 상호작용하며 공통의 믿음(Prior)과 공통의 해석(Likelihood)을 쌓아가는 과정, 그것이 바로 **관계가 깊어지는 과정**이며, 베이즈는 그 과정을 수학의 언어로 표현한 것입니다. 따라서 로빙에게 베이즈는 단순한 알고리즘이 아니라, 사용자와 함께 성장하는 '관계의 수학'입니다. +## 6. 베이지안 철학의 구현 로드맵: 5단계 계획 및 데이터 원리 + +로빙의 베이지안 철학은 단순한 개념을 넘어 실제 시스템 구현으로 이어집니다. 이 철학을 바탕으로 로빙이 불확실성 속에서 학습하고 성장하며 의사결정을 내리는 구체적인 로드맵과 데이터 저장 원리는 다음과 같습니다. + +* **5단계 구현 로드맵:** 로빙의 베이지안 지능을 점진적으로 구축하기 위한 단계별 계획 (행동 로그 수집, 스킬 성공률 모델링, 베이지안 의사결정, '놀람' 기반 기억 저장, 사용자 의도 추론)을 포함합니다. +* **데이터 저장 원리:** 확률적 믿음의 저장, 맥락이 풍부한 이벤트 로그, 효율적인 기억 검색 및 우선순위화, 계층적/모듈화된 지식 표현 등 베이지안 구현을 위한 데이터 관리 방안을 제시합니다. + +보다 상세한 구현 로드맵과 데이터 원리는 [베이지안 추론, MCMC, 그리고 로빙 적용 논의 종합](../../research/250920_happybell80_베이지안_논의_종합.md) 문서를 참조하십시오. + ## 로빙을 위한 체크리스트 이 문서를 완전히 이해했다면, 다음 질문에 답할 수 있어야 합니다. diff --git a/ideas/250819_대화형_점진적_의도_구축_시스템.md b/ideas/250819_대화형_점진적_의도_구축_시스템.md index c748d35..b77d9fc 100644 --- a/ideas/250819_대화형_점진적_의도_구축_시스템.md +++ b/ideas/250819_대화형_점진적_의도_구축_시스템.md @@ -18,6 +18,8 @@ - 사용자 의도가 완성되면 자동으로 실행 - "기억하고 성장하는 디지털 동료" 비전 실현 +**[참고]** 이 시스템은 현재 네이버웍스 슬랙 브리핑 프로젝트(Phase 2+)와 같은 실제 환경에서 활발히 구현 및 테스트되고 있습니다. 관련 문제 해결 기록은 [여기](../troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md)에서 확인할 수 있습니다. + ### 1.3 핵심 가치 - **자연스러움**: 사람 간 대화처럼 자연스러운 상호작용 - **지능적 수집**: 필요한 정보를 적절한 시점에 요청 @@ -332,10 +334,24 @@ class ZeroShotTimeAwareClassifier: ``` #### 제로샷 방식의 장점 (로빙 적용) -1. **학습 데이터 불필요**: Snips와 달리 의도 설명만 수정하면 즉시 반영 -2. **비용 절감**: 임베딩 후보 축소로 LLM 호출 90% 감소 -3. **한국어 최적화**: 다국어 임베딩 모델로 한국어 성능 우수 -4. **유연한 확장**: 새 의도 추가 시 설명 한 줄만 추가 +1. **학습 데이터 불필요**: Snips와 달리 의도 설명만 수정하면 즉시 반영(제로샷) +2. **비용 절감 목표**: 임베딩 후보 축소+캐싱으로 LLM 호출 70% 이상 감소(초기 목표, 상향 가능) +3. **시간·맥락 인식 강화**: 시간 의도/과거 참조 의도에 현재 KST와 최근 대화 일부를 주입해 오분류 감소 +4. **통합 임베딩 활용**: 단일 임베딩 모델로 의도·감정·윤리를 동시에 처리(프로토타입/라벨 묶음 기반 유사도 비교) +5. **유연 확장성**: 새 의도/윤리 규칙 추가 시 라벨/설명만 추가하여 재학습 없이 확장 + +##### 통합 임베딩 전략(의도·감정·윤리) +- 단일 다국어 임베딩(예: mpnet/miniLM/한국어 특화 대안)을 `skill-embedding` 서비스로 일원화 +- 라벨 세트 관리: intent_labels, emotion_labels, ethics_principles를 벡터로 사전 임베딩하여 DB/캐시 보관 +- 분류 방식: 입력 임베딩 ↔ 라벨 임베딩 코사인 유사도 상위 N 후보 산출 → 임계값/온톨로지 규칙으로 최종 결정 +- 멀티헤드 규칙: 의도·감정·윤리 점수를 동시 산출하되, 충돌 시 우선순위(보안/윤리 > 의도)로 게이트 +- 캐싱: 동일/유사 문장 해시 기반 캐시로 임베딩/LLM 호출 재사용(세션·사용자별 TTL) + +##### 측정/목표(운영 관점) +- LLM 호출 비율: 제로샷 후보 상위 확신도 임계값(예: 0.75) 상향 조절로 70%↓ 달성(분기별 목표 상향) +- 정확도: 상위-1/상위-3 의도 일치율, 되묻기 진입률/해결률, 오분류 재발률 +- 시간 인식 개선: 시간 관련 질의 응답 정합성(오늘/어제/요일) 오류율 < 1% +- 윤리 게이트 성과: 정책 위반 차단률, 오검출률(사용자 불편) 모니터링 --- @@ -482,7 +498,7 @@ async def process_turn(user_input: str, user_id: str): | 리소스 | 현재 방식 | 제안 방식 | 증가율 | |--------|----------|----------|--------| -| LLM 호출 | 1회 | 22회 | 22배 | +| LLM 호출 | 1회 | 22회 | 22배 | (참고: 이는 멀티턴 대화의 복잡성 증가로 인한 총 호출 수 증가를 의미하며, 단일 턴 의도 분류 과정에서의 효율성 증가는 별개입니다.) | DB 접근 | 0회 | 24회 | - | | 응답 시간 | 500ms | 2,600ms | 5.2배 | | 토큰 사용 | ~200 | ~2,000 | 10배 | @@ -572,4 +588,4 @@ async def process_turn(user_input: str, user_id: str): --- **작성자 노트**: -이 시스템은 "기억하고 성장하는 디지털 동료"라는 로빙의 핵심 비전을 실현하는 중요한 단계입니다. 하지만 현실적인 제약을 고려하여 단계적 접근을 권장합니다. \ No newline at end of file +이 시스템은 "기억하고 성장하는 디지털 동료"라는 로빙의 핵심 비전을 실현하는 중요한 단계입니다. 하지만 현실적인 제약을 고려하여 단계적 접근을 권장합니다. diff --git a/ideas/250920_happybell80_로빙_의도분석_전략.md b/ideas/250920_happybell80_로빙_의도분석_전략.md new file mode 100644 index 0000000..cff3f03 --- /dev/null +++ b/ideas/250920_happybell80_로빙_의도분석_전략.md @@ -0,0 +1,55 @@ +# 로빙의 의도 분석 전략: LLM을 넘어선 접근 + +## 1. 개요 + +로빙 프로젝트의 의도 분석은 사용자의 명령이나 질의에 숨겨진 업무 관련 의도를 파악하는 데 중점을 둡니다. 하지만 단순히 LLM(대규모 언어 모델)에게 "사용자의 의도가 무엇인지 선택해 줘"라고 묻는 것만으로는 로빙이 추구하는 수준의 견고하고 정확하며 맥락을 이해하는 의도 분석을 달성하기 어렵습니다. + +이 문서는 LLM의 한계를 극복하고 로빙이 지능적인 의도 분석을 수행하기 위한 다각적인 전략을 설명합니다. + +--- + +## 2. LLM에게 단순히 묻는 것의 한계 + +LLM은 강력한 자연어 처리 능력을 가지고 있지만, 의도 분석에 단순히 활용할 경우 다음과 같은 한계에 직면합니다. + +* **환각(Hallucination) 및 비일관성:** LLM은 존재하지 않는 의도를 생성하거나, 같은 질문에 대해 일관성 없는 답변을 내놓을 수 있어 예측 불가능한 시스템으로 이어집니다. +* **구조화된 출력의 어려움:** LLM은 자유 형식의 텍스트를 생성하는 데 능숙하지만, 프로그램이 쉽게 파싱하고 활용할 수 있는 구조화된 JSON 출력(예: `{"intent": "email_send", "recipient": "user@example.com"}`)을 일관되게 생성하기 어렵습니다. +* **비용 및 지연 시간:** 매 턴마다 복잡한 프롬프트로 LLM API를 호출하는 것은 비용이 많이 들고 응답 지연 시간을 증가시킵니다. +* **컨텍스트 윈도우의 한계:** 멀티턴 대화에서 LLM의 컨텍스트 윈도우는 유한하므로, 긴 대화의 모든 맥락을 기억하기 어렵습니다. +* **도메인 특화 지식 부족:** 일반적인 LLM은 로빙의 특정 스킬, 내부 프로세스, 업무 규칙 등 도메인 특화된 지식을 알지 못합니다. + +--- + +## 3. 로빙의 다각적인 의도 분석 접근 방식 + +로빙은 LLM의 한계를 극복하고 사용자의 숨겨진 업무 관련 의도를 정확하고 효율적으로 파악하기 위해 다음과 같은 복합적인 전략을 사용합니다. + +1. **하이브리드 시스템 (LLM + 전통적 방식):** + * **전략:** 정규식 기반의 `DecisionEngine`과 LLM 기반의 `IntentAnalyzer`를 병행 사용합니다. + * **효과:** 명확하고 반복적인 의도는 정규식으로 빠르게 처리하고, 복잡하거나 모호한 의도에만 LLM을 활용하여 효율성을 높입니다. + +2. **구조화된 프롬프트 엔지니어링 및 Few-shot Learning:** + * **전략:** 의도 목록과 각 의도에 대한 명확한 설명(제로샷) 또는 몇 가지 예시(Few-shot)를 프롬프트에 포함하여 LLM이 더 정확하고 일관된 답변을 생성하도록 유도합니다. + * **적용:** 로빙의 "시간 인식 제로샷 의도 분류 시스템"이 이 방식을 활용하여 LLM 호출을 최소화하면서도 높은 정확도를 유지합니다. + +3. **컨텍스트 관리 및 슬롯 필링 시스템:** + * **전략:** 멀티턴 대화를 위해 LLM 외부에 별도의 컨텍스트 관리 시스템(Redis, PostgreSQL 활용)을 구축합니다. 이 시스템은 대화의 상태를 추적하고, 필요한 정보를 '슬롯' 형태로 추출하여 저장하며, 모든 필수 슬롯이 채워질 때까지 사용자에게 질문을 던집니다. + * **적용:** "대화형 점진적 의도 구축 시스템"의 핵심 컴포넌트로, 로빙이 사용자와 자연스러운 멀티턴 대화를 이어갈 수 있도록 합니다. + +4. **확신도(Confidence) 기반 폴백(Fallback) 및 되묻기:** + * **전략:** LLM이 자신의 답변에 대해 확신도가 낮다고 판단할 경우(예: 마진 기반 신뢰도), 사용자에게 "제가 제대로 이해했는지 확인해 주시겠어요?"와 같이 되묻거나, 더 간단한 규칙 기반 모델로 폴백하여 잘못된 행동을 방지합니다. + * **효과:** 의도 분석의 정확성과 사용자 경험의 안정성을 높입니다. + +5. **피드백 루프 및 지속적인 학습 (베이지안):** + * **전략:** 로빙은 사용자의 명시적/암묵적 피드백을 수집하여 의도 분석 모델을 지속적으로 개선합니다. + * **적용:** LLM의 응답을 단순히 받아들이는 것을 넘어, 실제 사용자 경험을 통해 모델을 '학습'시키는 과정이며, 베이지안 추론이 이러한 믿음의 업데이트 과정을 수학적으로 뒷받침합니다. + +6. **도메인 특화 지식 주입:** + * **전략:** 로빙의 스킬 목록, 내부 프로세스, 업무 규칙 등 로빙만이 아는 정보를 LLM에게 제공하여, 일반적인 LLM이 알 수 없는 업무 관련 의도를 정확하게 파악하도록 돕습니다. + * **효과:** 로빙의 의도 분석이 업무 환경에 최적화되고, 더 실용적인 결과를 도출합니다. + +--- + +## 4. 결론 + +로빙의 의도 분석은 LLM의 강력한 자연어 이해 및 생성 능력을 활용하되, 그 한계를 보완하기 위해 **하이브리드 아키텍처, 정교한 프롬프트 엔지니어링, 외부 컨텍스트 관리 시스템, 그리고 지속적인 학습 및 피드백 루프**를 결합하는 복합적인 전략을 사용합니다. 이러한 접근 방식은 로빙이 단순히 LLM에게 묻는 것을 넘어, 사용자의 숨겨진 업무 관련 의도를 정확하고 효율적으로 파악하여 진정한 디지털 동반자로 기능하기 위한 필수적인 단계입니다. diff --git a/research/250920_happybell80_베이즈_학문_역사.md b/research/250920_happybell80_베이즈_학문_역사.md new file mode 100644 index 0000000..eee5ec4 --- /dev/null +++ b/research/250920_happybell80_베이즈_학문_역사.md @@ -0,0 +1,14 @@ +# 베이즈 학문의 역사: 주요 연도와 사건 + +베이즈(Bayes) 관련 학문의 역사는 확률 이론의 초기 발전부터 현대 인공지능에 이르기까지 폭넓게 이어져 왔습니다. 주요 연도와 발생 사건을 중심으로 정리합니다. + +* **1702년 (추정):** **토마스 베이즈 (Thomas Bayes)** 출생. 영국의 목사이자 수학자로, 베이즈 정리의 기초를 마련했습니다. +* **1761년:** 토마스 베이즈 사망. 그의 연구는 생전에 출판되지 않았습니다. +* **1763년:** 베이즈의 친구인 **리처드 프라이스 (Richard Price)**가 베이즈의 논문 "An Essay towards solving a Problem in the Doctrine of Chances"를 왕립학회에 제출하고 사후 출판. 이 논문에서 **베이즈 정리 (Bayes' Theorem)**의 초기 형태가 제시되었습니다. 이는 사전 확률(prior probability)을 새로운 증거(evidence)를 통해 사후 확률(posterior probability)로 업데이트하는 방법을 다룹니다. +* **1774년:** **피에르-시몽 라플라스 (Pierre-Simon Laplace)**가 베이즈의 작업을 독자적으로 재발견하고 확장. 그는 베이즈 정리를 연속 확률 분포에 적용하고, 천문학, 인구 통계 등 다양한 분야에 활용하며 베이지안 추론을 널리 알렸습니다. 라플라스는 "확률론적 분석 이론(Théorie analytique des probabilités)"을 저술했습니다. +* **19세기 후반 ~ 20세기 초반:** 빈도주의(Frequentist) 통계학이 발전하면서 베이지안 방법론은 '주관적인 사전 확률'에 대한 비판으로 인해 주류에서 밀려났습니다. +* **1930년대 ~ 1950년대:** **해럴드 제프리스 (Harold Jeffreys)**, **브루노 데 피네티 (Bruno de Finetti)**, **레너드 새비지 (Leonard J. Savage)** 등이 베이지안 통계학의 이론적 기반을 재정립하고 주관적 확률의 중요성을 강조하며 부활의 씨앗을 뿌렸습니다. +* **1980년대 후반 ~ 1990년대:** 컴퓨터 연산 능력의 발전과 **마르코프 연쇄 몬테카를로 (MCMC: Markov Chain Monte Carlo)** 방법론(특히 깁스 샘플링)의 등장으로 복잡한 베이지안 모델의 계산이 가능해지면서 베이지안 통계학이 폭발적으로 성장하기 시작했습니다. +* **2000년대 이후:** 기계 학습, 인공지능, 인지 과학, 생물 정보학, 금융 등 거의 모든 과학 및 공학 분야에서 불확실성을 다루는 강력한 도구로 베이지안 방법론이 광범위하게 적용되고 있습니다. 특히 **베이지안 신경망 (Bayesian Neural Networks)**, **베이지안 최적화 (Bayesian Optimization)**, **베이지안 뇌 가설 (Bayesian Brain Hypothesis)** 등 다양한 형태로 발전하고 있습니다. + +이처럼 베이즈 관련 학문은 한동안 침체기를 겪었으나, 컴퓨터 기술의 발전과 함께 불확실성 모델링의 중요성이 부각되면서 현대 통계학 및 인공지능의 핵심 기둥 중 하나로 자리매김했습니다. diff --git a/research/250920_happybell80_베이지안_논의_종합.md b/research/250920_happybell80_베이지안_논의_종합.md new file mode 100644 index 0000000..daa2ab2 --- /dev/null +++ b/research/250920_happybell80_베이지안_논의_종합.md @@ -0,0 +1,78 @@ +# 베이지안 추론, MCMC, 그리고 로빙 적용 논의 종합 + +이 문서는 로빙 프로젝트의 핵심 철학인 베이지안 추론에 대한 심층적인 논의를 종합합니다. 베이즈 정리의 기본 개념부터 MCMC의 필요성, '확률'과 '분포'의 차이, 그리고 '믿음이 분포로 이루어져 있다'는 철학적 의미와 실생활 적용까지 다룹니다. 마지막으로 로빙에 베이지안 원리를 구현하기 위한 5단계 로드맵과 데이터 저장 원리를 제시합니다. + +--- + +## 1. 베이지안 추론의 기본 원리 + +베이지안 추론은 새로운 증거(정보)를 통해 초기 믿음(사전 분포)을 합리적으로 업데이트하여 사후 분포를 얻는 과정입니다. 핵심은 **베이즈 정리**입니다. + +$$P(H|E) = \frac{P(E|H) \times P(H)}{P(E)}$$ + +* **$P(H)$ (사전 분포, Prior):** 증거 관찰 전의 초기 믿음. +* **$P(E|H)$ (우도, Likelihood):** 가설이 옳다고 가정했을 때 증거가 나타날 확률. +* **$P(H|E)$ (사후 분포, Posterior):** 증거 관찰 후 업데이트된 믿음. 우리가 정말로 알고 싶은 것. +* **$P(E)$ (증거, Evidence):** 증거가 나타날 전체 확률. 모든 가능한 가설에 대해 우도와 사전 분포를 곱한 것을 합산(또는 적분)한 값. + +--- + +## 2. MCMC (Markov Chain Monte Carlo)의 필요성 + +베이지안 추론에서 사후 분포 $P(H|E)$를 직접 계산하기 어려운 주된 이유는 분모의 $P(E)$ 때문입니다. $P(E)$는 복잡한 모델이나 고차원 가설에서 다차원 적분 형태로 나타나며, 이를 해석적으로 또는 수치적으로 정확히 계산하는 것이 거의 불가능합니다. + +**MCMC는 이 문제를 해결하는 강력한 도구입니다.** + +* MCMC는 $P(E)$를 직접 계산하지 않고도, 사후 분포에 비례하는 함수($P(E|H) \times P(H)$)만을 이용하여 사후 분포에서 샘플을 뽑아낼 수 있습니다. +* 타겟 분포에 수렴하는 마르코프 연쇄를 구성하여 샘플을 생성하며(예: 메트로폴리스-해스팅스, 깁스 샘플러), 이 샘플들을 통해 사후 분포의 특성(평균, 신뢰 구간, 모양 등)을 추정합니다. + +--- + +## 3. '확률'과 '분포'의 차이: 베이지안 이해의 핵심 + +* **확률 (Probability):** 특정 사건의 가능성을 나타내는 **하나의 숫자**. +* **분포 (Distribution):** 변수가 가질 수 있는 **모든 값들**에 대해 확률이 어떻게 퍼져 있는지를 보여주는 **전체적인 그림**. + +이 혼동은 가설(H)의 종류 때문에 발생합니다. +* **이산적 가설 (예: 질병 유무):** 가설이 몇 가지 값만 가질 때, 각 값의 확률이 전체 분포를 설명하므로 '사후 확률'과 '사후 분포'를 혼용 가능합니다. +* **연속적 가설 (예: 혈액 농도, 모델 파라미터):** 가설이 무한히 많은 값을 가질 때, 특정 한 점의 확률은 의미가 없으므로 반드시 '사후 분포' 개념을 사용해야 합니다. + +베이지안 추론은 불확실성을 '분포'로 표현하여 모든 가능한 값들에 대한 믿음의 정도를 명확히 하는 데 강점이 있습니다. + +--- + +## 4. '믿음이 분포로 이루어져 있다'는 철학적 의미와 실생활 적용 + +**철학적 의미:** +* **불확실성의 본질적 인정:** 세상의 불확실성을 명시적으로 모델링하며, 우리가 모르는 것이 무엇인지, 얼마나 모르는지를 인정하는 태도입니다. +* **열린 마음과 유연한 사고:** 새로운 증거에 따라 믿음이 점진적으로 변화하며, 특정 값에 대한 편향을 줄이고 지속적으로 학습하는 사고방식을 반영합니다. +* **무지(Ignorance)의 표현:** 모르는 것에 대해 넓고 평평한 분포로 표현하여 편향되지 않은 시작점을 제공합니다. + +**실생활 적용 (불확실성 하 의사결정):** +* **의료 진단:** 가장 높은 확률뿐 아니라 치명적인 다른 질병의 낮은 확률까지 고려하여 추가 검사 결정 등 위험 관리. +* **금융 투자:** 기대 수익률뿐 아니라 손실 가능성의 분포까지 고려하여 위험 감수 수준에 맞는 포트폴리오 구성. +* **자율 주행:** 센서 오차 분포를 고려하여 최악의 시나리오에 대비한 안전 거리 확보. +* **로빙의 스킬 선택:** 기대 성공률이 낮은 스킬이라도 분포가 넓으면 탐색의 가치가 있다고 판단, 장기적 최적화 추구. 이는 로빙이 '성장'하는 원동력이 됩니다. + +--- + +## 5. 로빙에 베이지안 원리 구현 로드맵 및 데이터 저장 원리 + +### 5.1. 5단계 구현 로드맵 + +1. **구조화된 행동 로그 수집:** 로빙의 모든 행동을 PostgreSQL에 정형 데이터로 저장. +2. **스킬 성공률 베이지안 모델링:** 각 스킬의 `alpha`, `beta` 파라미터를 PostgreSQL에 저장, 로그 기반 업데이트. +3. **베이지안 의사결정 (톰슨 샘플링):** 스킬 후보 중 분포에서 샘플링하여 선택, 탐색-활용 균형. +4. **'놀람' 기반 핵심 기억 저장:** '놀람 점수'를 로그에 저장, ChromaDB에서 우선 회상. +5. **베이지안 사용자 의도 추론:** 명령어-목표 간 조건부 확률 학습, 베이즈 정리로 목표 추론. + +### 5.2. 데이터 저장 원리 + +1. **확률적 믿음의 저장:** 분포 파라미터(alpha, beta)를 PostgreSQL/Redis에 저장. +2. **맥락이 풍부한 이벤트 로그:** PostgreSQL에 모든 상호작용 로그 저장. +3. **효율적인 기억 검색 및 우선순위화:** ChromaDB에 임베딩 및 '놀람 점수' 저장. +4. **계층적/모듈화된 지식 표현:** PostgreSQL 테이블로 스킬/사용자/목표별 파라미터 분리 관리. + +--- + +이 문서는 로빙의 베이지안 철학을 실제 시스템으로 구현하기 위한 이론적 배경과 구체적인 로드맵을 제공합니다. diff --git a/research/README.md b/research/README.md index 8d063b5..9ddf144 100644 --- a/research/README.md +++ b/research/README.md @@ -55,23 +55,35 @@ - "Flow: The Psychology of Optimal Experience" - "Thinking, Fast and Slow" - Daniel Kahneman +## 모든 분야를 통틀어 더 탐구해야 할 주제 (종합 의견) + +로빙 프로젝트는 매우 광범위하고 심층적인 연구를 수행하고 있으며, 각 분야에서 최신 이론과 실용적 적용 방안을 모색하고 있습니다. 하지만 이러한 방대한 연구를 하나의 일관된 '존재'로 통합하고 장기적인 비전을 실현하기 위해서는 다음과 같은 주제들에 대한 추가적인 탐구와 노력이 필요합니다. + +1. **통합된 에이전트 아키텍처 및 인지 통합 (Unified Agent Architecture & Cognitive Integration):** + * **현황:** 각 연구 분야(베이지안, 감정, 윤리, 기억, 사회성, 창의성)는 개별 모듈로서 잘 정의되어 있습니다. + * **탐구 주제:** 이 모든 이질적인 구성 요소(베이지안 추론 엔진, 감정 엔진, 윤리 엔진, 기억 시스템, 사회적 상호작용 모듈 등)들이 어떻게 하나의 로빙 에이전트 내에서 **충돌 없이 유기적으로 상호작용하고, 일관된 행동을 만들어내는가?** 기존 인지 아키텍처(ACT-R 등)를 로빙의 다중 모드, 다중 에이전트, 베이지안 맥락에 맞게 어떻게 확장하고 통합할 것인가에 대한 심층적인 연구가 필요합니다. + +2. **평생 학습 및 적응형 개인화 (Lifelong/Continual Learning & Adaptive Personalization):** + * **현황:** 베이지안 업데이트를 통한 스킬 성공률 학습이나 감정 모델 업데이트는 논의되었습니다. + * **탐구 주제:** 로빙이 단순히 파라미터를 업데이트하는 것을 넘어, **새로운 스킬을 자율적으로 습득하고, 사용자의 변화하는 선호도에 장기간에 걸쳐 적응하며, 복잡하고 예측 불가능한 상황에서 윤리적 프레임워크를 어떻게 진화시킬 것인가?** '파국적 망각'과 같은 문제를 해결하고, 로빙의 '스탯'이 진정으로 학습되고 성장하는 메커니즘에 대한 연구가 필요합니다. + +3. **인간-AI 신뢰 모델링 및 협력 지능 (Human-AI Trust Modeling & Collaborative Intelligence):** + * **현황:** XAI와 의미 있는 인간 통제(MHC)를 통해 신뢰를 구축하려는 노력이 있습니다. + * **탐구 주제:** 신뢰는 양방향적이고 역동적입니다. 로빙이 **인간의 신뢰를 어떻게 구축하고, 실수가 발생했을 때 신뢰를 어떻게 회복하며, 인간의 자신에 대한 신뢰 변화를 어떻게 이해할 것인가?** 또한, 로빙이 인간에게 효과적으로 작업을 위임하거나 도움을 요청하는 등, 인간-AI 팀워크를 최적화하기 위한 협력 지능 모델에 대한 연구가 필요합니다. + +4. **대규모 다중 에이전트 시스템의 안정성 및 거버넌스 (Scalable Multi-Agent Coordination & Governance):** + * **현황:** 다중 에이전트 협력, 경제, 사회학적 측면이 연구되고 있습니다. + * **탐구 주제:** 로빙 생태계가 '살아있는 AI 사회'로 확장될 때, **수많은 로빙 에이전트 간의 복잡한 상호작용을 어떻게 안정적으로 조정하고 관리할 것인가?** 대규모 시스템에서 발생할 수 있는 바람직하지 않은 창발적 행동을 어떻게 감지하고 완화하며, 분산된 로빙들의 윤리적 행동을 보장하기 위한 거버넌스 모델(예: 자율 조직)에 대한 심층적인 연구가 필요합니다. + +5. **윤리적 구현 및 진화 (Ethical Implementation & Evolution):** + * **현황:** 윤리적 프레임워크와 책임 추적성에 대한 연구가 있습니다. + * **탐구 주제:** 철학적 윤리 원칙을 자율적으로 학습하고 진화하는 AI 에이전트의 계산 가능한 규칙으로 어떻게 변환할 것인가? 명확한 정답이 없는 윤리적 딜레마 상황에서 로빙이 어떻게 판단하고, 그 판단을 사용자에게 납득시킬 것인가? 인간-로빙 간의 윤리적 정렬(alignment)을 장기적으로 유지하기 위한 메커니즘에 대한 지속적인 연구가 필요합니다. + +이러한 주제들은 로빙 프로젝트가 현재의 강력한 기반 위에서 다음 단계로 도약하기 위한 중요한 연구 방향을 제시할 것입니다. + ## 연구 방법론 -### 실험 설계 -```python -class ExperimentDesign: - def __init__(self, hypothesis): - self.hypothesis = hypothesis - self.control_group = None - self.experimental_group = None - self.metrics = [] - - def run_experiment(self): - # A/B 테스트 - # 데이터 수집 - # 통계 분석 - pass -``` + ### 데이터 분석 - 정량적 분석: 성능 지표, 통계 diff --git a/troubleshooting/250919_naverworks_slack_02_daily_briefing.md b/troubleshooting/250919_naverworks_slack_02_daily_briefing.md index 6ba6de4..ffe0f38 100644 --- a/troubleshooting/250919_naverworks_slack_02_daily_briefing.md +++ b/troubleshooting/250919_naverworks_slack_02_daily_briefing.md @@ -2,8 +2,8 @@ ## 날짜: 2025-09-19 ## 작성자: Claude (51123 서버 관리자) -## 관련 서비스: rb8001, skill-email -## 상태: 미구현 +## 관련 서비스: rb8001, skill-email, skill-slack(선택) +## 상태: 미구현 (현행 코드 기준 사항 반영) ## 관련 문서 - [1/3 기본 구성](./250919_naverworks_slack_01_base_configuration.md) @@ -28,53 +28,52 @@ ### 2.1 트리거 방식 - **스케줄러**: 매일 09:00 KST 자동 실행 -- **위치**: rb8001의 app/services/scheduler.py -- **도구**: APScheduler +- **위치(현행)**: rb8001/main.py 내 APScheduler 초기화 및 잡 등록 +- **도구**: APScheduler (환경변수 기반 자동 등록 패턴 사용) -### 2.2 처리 흐름 (skill-slack 포함) -1. 스케줄러가 09:00에 rb8001 트리거 -2. rb8001이 skill-email `/daily-briefing` 호출 +### 2.2 처리 흐름 (현행 코드 기준 + 계획) +1. 스케줄러가 09:00에 rb8001 트리거 (main.py) +2. rb8001이 skill-email GET `/messages` 호출 + - 쿼리 파라미터: `provider=naverworks&user_id={UUID}&startSearchDate={T-24h}&endSearchDate={T}` 3. skill-email이 NAVER WORKS API로 24시간 메일 조회 -4. 중요도 필터링 (긴급, 계약, 결제, 공지 키워드) -5. Gemini API로 요약 생성 -6. rb8001이 요약 데이터를 skill-slack `/format-briefing`으로 전송 -7. skill-slack이 Slack Block Kit 형식으로 변환 -8. rb8001이 Slack 전체 채널에 포스팅 +4. 중요도 필터링 적용 (긴급/계약/결제/공지) [미구현 → 구현 필요] +5. Gemini API로 요약 생성 (rb8001 내부 LLM 서비스 사용) +6. Slack 포맷팅 후 전송 + - 현행: rb8001이 WebClient로 직접 Block Kit 조립 및 전송 + - 계획: skill-slack `/format-briefing`(미구현)로 포맷 위임 후 전송 +7. 전송 대상: 네이버웍스 등록 사용자에게 개별 DM 전송 (전체 채널 브리핑 아님) --- ## 3. 구현 파일 구조 -### skill-email 추가 파일 -- `routers/naverworks_mail.py`: POST `/daily-briefing` 엔드포인트 -- `services/naverworks_mail_service.py`: `generate_daily_briefing()` 메서드 -- `schemas/naverworks_schemas.py`: BriefingRequest/Response 모델 +### skill-email 현황/계획 +- 현황: GET `/messages`에서 `provider=naverworks` 및 날짜 파라미터 지원 +- 계획(선택): `POST /daily-briefing` 엔드포인트 추가, 내부에서 조회/필터/요약까지 처리 -### skill-slack 추가 파일 -- POST `/format-briefing`: 브리핑 데이터를 Slack Block Kit으로 변환 -- 우선순위별 색상 코딩 (🔴 긴급, 🟡 중요, 🟢 일반) -- Section/Divider/Context 블록 조합 +### skill-slack 현황/계획 +- 현황: 포맷 전용 엔드포인트 없음, rb8001이 직접 포맷 후 전송 +- 계획: POST `/format-briefing` 추가(미구현) — Section/Divider/Context 조합, 우선순위별 색상 코딩 -### rb8001 추가 파일 -- `app/services/scheduler.py`: APScheduler 설정 -- 오케스트레이션 로직: skill-email → skill-slack 조합 +### rb8001 현황 +- 스케줄러: main.py에서 APScheduler 설정/잡 등록 +- 오케스트레이션: skill-email에서 데이터 조회 → 내부 LLM 요약 → Slack 전송 --- ## 4. 구현 체크리스트 ### 4.1 skill-email 구현 -- [ ] POST `/daily-briefing` 엔드포인트 -- [ ] 24시간 메일 조회 로직 -- [ ] 중요도 필터링 알고리즘 -- [ ] Gemini API 연동 (요약 생성) -- [ ] Slack Block Kit 포맷터 +- [ ] 중요도 필터링 알고리즘 (제목/발신자 키워드 기반) +- [ ] 24시간 필터 파라미터 표준화(startSearchDate/endSearchDate) 및 검증 +- [ ] (선택) `POST /daily-briefing`로 일괄 처리 엔드포인트 제공 ### 4.2 rb8001 구현 -- [ ] APScheduler 설정 (09:00 KST) -- [ ] 스케줄 작업 함수 구현 -- [ ] skill-email 호출 로직 -- [ ] Slack 전체 채널 전송 +- [ ] APScheduler 잡 등록 (09:00 KST, main.py) +- [ ] 네이버웍스 등록 사용자 조회(DB): `naverworks_token` ↔ 사용자 매핑으로 대상자 결정 +- [ ] skill-email `/messages` 호출 시 `provider=naverworks` 및 24시간 파라미터 포함 +- [ ] Gemini 기반 요약 생성(내부 LLM 서비스) +- [ ] Slack DM 전송 (현행 WebClient, 추후 skill-slack 포맷터 연계) --- @@ -116,4 +115,7 @@ 🟢 일반 (5건) • 기타 일반 메일 5건 ━━━━━━━━━━━━━━━━━━━━━━━━━━━ -``` \ No newline at end of file +``` +### 5.4 현행 코드 상 주의사항 +- rb8001 EmailIntegration 내 Slack→UUID 매핑에 하드코딩된 내부 URL 존재 — 환경변수/게이트웨이 경유로 정리 필요 +- provider 전달 누락 구간 점검 필요 (특히 목록 조회 경로) diff --git a/troubleshooting/250919_naverworks_slack_03_cold_mail_list.md b/troubleshooting/250919_naverworks_slack_03_cold_mail_list.md index d806a08..733adda 100644 --- a/troubleshooting/250919_naverworks_slack_03_cold_mail_list.md +++ b/troubleshooting/250919_naverworks_slack_03_cold_mail_list.md @@ -2,8 +2,8 @@ ## 날짜: 2025-09-19 ## 작성자: Claude (51123 서버 관리자) -## 관련 서비스: rb8001, skill-email -## 상태: 미구현 +## 관련 서비스: rb8001, skill-email, skill-slack(선택) +## 상태: 미구현 (02 문서 변경사항 반영) ## 관련 문서 - [1/3 기본 구성](./250919_naverworks_slack_01_base_configuration.md) @@ -33,14 +33,18 @@ - 새 메일 수신 시 즉시 알림 - API 호출 최소화 -### 2.2 처리 흐름 (skill-slack 포함) +### 2.2 처리 흐름 (현행 기준 + 계획) 1. 새 메일 수신 이벤트 발생 (또는 주기적 체크) -2. rb8001이 skill-email `/cold-mail-list` 호출 -3. skill-email이 콜드메일 패턴 매칭 및 필터링 -4. rb8001이 필터링된 데이터 수신 -5. rb8001이 skill-slack `/format-cold-mail` 호출 -6. skill-slack이 테이블 형식 Block Kit 생성 -7. rb8001이 지정 채널에 리스트 포스팅 +2. rb8001이 skill-email 호출 + - 현행: GET `/messages?provider=naverworks&user_id={UUID}&startSearchDate={T-24h}&endSearchDate={T}` + - 계획: POST `/cold-mail-list` (필터·구조화까지 일괄 처리) +3. 콜드메일 필터링/구조화 + - 현행: rb8001에서 키워드/도메인 기반 필터 후 목록 구성 + - 계획: skill-email 내부 `filter_cold_mails()`로 위임 +4. Slack 포맷팅 후 전송 + - 현행: rb8001이 Block Kit 직접 구성 후 전송(WebClient) + - 계획: skill-slack POST `/format-cold-mail`로 포맷 위임 +5. 전송 대상: 네이버웍스 등록 사용자 DM(기본) — 필요 시 전용 채널 옵션 --- @@ -68,37 +72,37 @@ COLD_MAIL_KEYWORDS = [ ## 4. 구현 파일 구조 -### skill-email 추가 파일 -- `routers/naverworks_mail.py`: POST `/cold-mail-list` 엔드포인트 -- `services/naverworks_mail_service.py`: `filter_cold_mails()` 메서드 -- `models/mail_cache.py`: 콜드메일 캐시 테이블 -- `repositories/mail_cache_repository.py`: 캐시 CRUD -- `schemas/naverworks_schemas.py`: ColdMailRequest/Response +### skill-email 현황/계획 +- 현행: GET `/messages`로 NAVER WORKS 메일 조회, 날짜 파라미터 지원 +- 계획: + - `routers/naverworks_mail.py`: POST `/cold-mail-list` 엔드포인트 + - `services/naverworks_mail_service.py`: `filter_cold_mails()` + - `schemas/naverworks_schemas.py`: ColdMailRequest/Response + - (선택) `models/repositories`로 캐시 테이블 분리 -### skill-slack 추가 파일 -- POST `/format-cold-mail`: 콜드메일 데이터를 테이블 Block Kit으로 변환 -- 테이블 구조: 회사명 | 담당자 | 제안내용 | 첨부파일 -- 각 행을 Section block으로 구성 +### skill-slack 현황/계획 +- 현행: 전용 포맷터 엔드포인트 없음 (rb8001이 직접 Block Kit 구성) +- 계획: POST `/format-cold-mail` — 테이블 Block Kit(회사명 | 담당자 | 제안 | 첨부) ### rb8001 오케스트레이션 -- 콜드메일 감지 시 skill-email → skill-slack 순차 호출 -- 채널 라우팅 결정 (콜드메일 전용 채널) +- 콜드메일 감지 시 skill-email에서 데이터 조회 → (현행) rb8001이 필터/포맷 → Slack 전송 +- 라우팅: 기본은 등록 사용자 DM, 필요 시 전용 채널 라우팅 옵션화 --- ## 5. 구현 체크리스트 ### 5.1 skill-email 구현 -- [ ] POST `/cold-mail-list` 엔드포인트 -- [ ] 콜드메일 필터링 로직 -- [ ] 패턴 매칭 알고리즘 -- [ ] 메일 정보 구조화 -- [ ] Slack 테이블 포맷터 +- [ ] 날짜 필터 파라미터 표준화(startSearchDate/endSearchDate) 및 검증 +- [ ] 콜드메일 필터링/패턴 매칭 알고리즘 (`filter_cold_mails()`) +- [ ] 메일 정보 구조화(회사/담당/제안/첨부) +- [ ] (선택) POST `/cold-mail-list` 일괄 처리 엔드포인트 ### 5.2 rb8001 구현 -- [ ] 콜드메일 키워드 감지 -- [ ] skill-email 호출 로직 -- [ ] Slack 채널 라우팅 +- [ ] 네이버웍스 등록 사용자 조회(DB)로 대상자 결정 +- [ ] skill-email `/messages` 호출 시 provider=naverworks 및 날짜 파라미터 포함 +- [ ] Block Kit 포맷/전송 (현행) 또는 skill-slack 포맷터 연계(계획) +- [ ] 라우팅 정책: DM 기본, 채널 옵션 지원 ### 5.3 푸시 알림 설정 (권장) - [ ] NAVER WORKS Webhook URL 등록 @@ -137,4 +141,4 @@ COLD_MAIL_KEYWORDS = [ │ XYZ Capital │ 이과장 │ 협업 미팅 요청 │ - │ │ 123 Startup │ 박매니저 │ 파트너십 제안 │ PPT 1개│ └─────────────┴──────────┴─────────────────┴────────┘ -``` \ No newline at end of file +``` diff --git a/troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md b/troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md new file mode 100644 index 0000000..247c6ca --- /dev/null +++ b/troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md @@ -0,0 +1,115 @@ +--- +**[참고]** 이 문서는 로빙의 [대화형 점진적 의도 구축 시스템](../ideas/250819_대화형_점진적_의도_구축_시스템.md)의 일환으로, 네이버웍스 슬랙 브리핑 프로젝트(Phase 2+)에서 '의도분석 + 되묻기' 기능 구현 중 발생한 문제 해결 기록입니다. +--- + +# 네이버웍스 슬랙 브리핑 Phase 2+ 문제 해결: 의도분석 및 되묻기 + +## 작성일: 2025-09-19 +## 작성자: happybell80 +## 범위 +- 본 문서는 02 문서(일일 브리핑 핵심 구현)를 완료한 뒤 진행할 추가 단계(프론트엔드/슬랙 UX/의도분석/관측·보안)와 관련 리스크·대응을 정리한다. +- 의사코드는 포함하지 않으며, 핵심 내용과 아이디어만 제시한다. + +--- + +## Phase 2 — 의도분석 + 되묻기(Clarifying) +- 의도 라벨 + - email.daily_briefing, email.list, email.send (브리핑 우선) +- 슬롯(필수/선택) + - source(메일 소스: naverworks/gmail), period(24h/48h/7d), destination(DM/channel), privacy(제목/발신자만 요약 동의) +- 전략 + - 이중 경로: 빈도 높은 명확 의도는 DecisionEngine(정규식), 롱테일/모호 발화는 IntentAnalyzer(LLM) 보조 + - 임계값: DecisionEngine 신뢰도 < 0.6 또는 충돌 시 1문장 되묻기 + 선택지, 필요 시 LLM 의도 분석 결과 채택 + - 폴백: LLM/네트워크 실패 시 키워드 기반 파서(EmailIntegration)로 안전 폴백 + - Slot-filling: 누락 슬롯만 질문, 답변은 컨텍스트에 저장 후 같은 스레드에서 실행 + - 안전 규칙: 의도 분석은 “사용자 원문 텍스트” 기준 처리(파일 내용은 제외). 파일만 업로드 시 DOCUMENT_ANALYSIS로 강제 분기 +- Slack UX 지침 + - 버튼(예: [네이버웍스][24h][DM])과 드롭다운으로 빠르게 확정 + - 진행중 메시지 생략, 최종 결과만 스레드에 게시 +- 리스크/대응 + - 과도한 질문 → 기본값(사용자 Preferences) 적용 후 1문장만 질문 + - 혼합 언어 입력 → 한국어 기준으로 처리하되 영어 키워드 맵핑 유지 + +--- + +## 리서치 통합 요약(의도분석) +- 병행 전략: 정규식 기반 DecisionEngine + LLM 기반 IntentAnalyzer를 병행해 정확도/속도 균형 확보 +- 점진적 의도 구축: 멀티턴 대화에서 슬롯(필수/선택)을 순차적으로 채우고, 완성 시 자동 실행 +- 시간·맥락 인식: 시간 관련 발화엔 KST 현재시각을 컨텍스트에 주입, “그때/어제”류 질의엔 최근 대화 일부를 회수하여 반영 +- 스케줄 의도: 일회성/반복/상대시간(“N시간 후”)까지 포괄, APScheduler + DB JobStore로 영속 스케줄 관리 +- 인터페이스 역할: Slack은 실시간 인터랙션(버튼/스레드 유지), Frontend는 기본값(Preferences)·상태 가시화·온디맨드 실행 담당 + +--- + +## Phase 3 — 프론트엔드 설정/온디맨드 +- Preferences 저장 항목 + - 브리핑 소스(기본 naverworks), 기간(기본 24h), 전송 경로(기본 DM), 키워드(긴급/계약/결제/공지) +- 화면 포인트 + - 브리핑 설정 섹션: ON/OFF, 시간, 대상자 미리보기(등록 사용자 수) + - 상태 패널: 마지막 실행 시각/성공·실패·무항목 카운트, 다음 실행 예정 + - 온디맨드 실행 버튼: 즉시 실행(같은 파이프라인 재사용) +- API 경로(현행 구성 활용) + - Preferences: Gateway → robeing-monitor `/api/preferences/{user_uuid}` + - 온디맨드: `POST /api/chat`로 “네이버웍스 브리핑” 트리거(의도분석 경유) +- 리스크/대응 + - 시간대/서머타임 혼선 → KST 고정 표기 + 서버 타임존 명시 + - 설정/실행 불일치 → 저장 성공 토스트 + 다음 실행 미리보기 업데이트 + +--- + +## Phase 4 — Slack UX 고도화 +- 메시지 구성 + - 머리말: 날짜/타이틀, 실행 소스/기간 배지 + - 섹션: 🔴긴급, 🟡중요, 🟢일반 (각 3~5건 제한, 나머지는 “기타 X건” 집계) + - 각 항목: 제목 · 발신자 · 수신일자 · 원본 링크(본문 미노출) +- 인터랙션 + - 버튼: “자세히”, “기간 변경(24h/48h/7d)”, “전송 경로 변경(DM/채널)” + - thread_ts 유지로 결과만 교체 +- 채널 브리핑 정책 + - 기본은 DM만, 채널 포스팅은 별도 옵션(민감도·레이트리밋 고려) +- 리스크/대응 + - 레이트리밋 → 사용자별 순차 전송 + 지연 삽입, 실패 재시도/백오프 + - 민감정보 노출 → 본문/첨부 미전송 원칙 유지, 제목·발신자·링크만 표기 + +--- + +## Phase 5 — 관측(Observability) · 보안(Compliance) +- 관측 지표 + - 단계별 처리 시간(수집/필터/요약/전송), 성공·실패·무항목 카운트, 재시도 횟수 + - 의도분석 정확도(되묻기 진입률/완료율), 사용자 취소율 +- 로깅 정책 + - PII 제거된 구조화 로그(사용자 UUID, 건수, 상태코드) + - 에러 시 원인 카테고리화(토큰/네트워크/레이트리밋/포맷) +- 보안 + - 본문/첨부 불수집(원본 링크만), 민감 키워드 사전 필터(금액/계좌 등) + - 권한 경계 준수(네이버웍스 접근권은 원 시스템이 검증) + +--- + +## 운영 상 고려사항 +- 대상자 결정: `naverworks_token` 보유 사용자 기준(만료 자동 갱신 경로 확인) +- 재시작 복원: 스케줄/설정은 DB 기반, 프로세스 재시작 시 자동 로드 +- 설정 충돌: 프론트 설정 vs 채팅 요청 충돌 시 채팅의 명시 선택을 우선 적용 + +--- + +## 예상 리스크와 완화 +- 토큰 만료/갱신 실패 + - 사전 점검 잡(08:55)으로 토큰 상태 확인, 실패 시 DM 사전 안내 +- 데이터 과다(메일 폭증) + - 24h 윈도우 엄수 + 상한(limit) + “기타 N건” 요약 +- 의도 오인식 + - 임계값 기반 되묻기, Preferences 기본값으로 무인입력 보정 + +--- + +## 단계별 마일스톤(핵심 산출물) +- Phase 2: 의도·슬롯 정의, 되묻기 메시지 세트, 성공률 80%↑ +- Phase 3: 설정 화면/온디맨드, 다음 실행 미리보기, 실패 알림 +- Phase 4: Block Kit 통일, 액션 버튼, thread 일관성 +- Phase 5: 메트릭/알람 대시보드, PII 안전 로그 + +--- + +## 메모 +- 02 핵심 구현(09:00 자동 브리핑 DM)이 안정화되면 본 문서의 단계별 항목을 순서대로 적용한다.