← 주요 프로젝트← Key projects

NVIDIA AI CORE · 팀 프로젝트

NVIDIA AI CORE · TEAM PROJECT

BrandGuard

BrandGuard

브랜드 언급을 수집해 급증과 부정 반응을 탐지하는 프로젝트입니다. 분석 보고서를 만들고 사람의 승인 후 알림을 보냅니다.

Collects brand mentions, detects spikes and negative reactions, and prepares reports. Alerts are sent after human approval.

PYTHONLANGGRAPHISOLATION FORESTFASTAPISTREAMLIT
담당 작업Work involved

수집 · 특징 설계 · 탐지 · 에이전트 · API 통합

Collection, feature design, detection, agent and API integration

현재 상태Current status

데모 데이터로 실행 가능 · 실제 운영 지표는 측정되지 않음

Runs with demo data; production metrics have not been measured

01

프로젝트 개요

BrandGuard의 문제 정의와 위험 탐지 범위

BrandGuard는 뉴스, 블로그, 커뮤니티와 웹의 브랜드 언급에서 위험 신호를 찾는 프로젝트다. 언급량 증가, 부정 반응, 위험 키워드와 확산 패턴을 분석한다. 보고서를 만들고 사람의 승인 후 알림을 보낸다.

핵심 기능

  • 6개 feature 그룹을 이용한 다차원 위험 신호 생성
  • Isolation Forest와 강제 승격 rule을 결합한 정상·주의·경보 판정
  • LangGraph 조건 분기로 정상 건은 기록하고 위험 건만 원인 분석
  • RAG 기반 분석, Markdown·Word 보고서와 근거 출력
  • 사람의 승인 이후에만 Slack·이메일 알림 발송
  • CLI, Streamlit dashboard와 FastAPI REST API 제공

담당 영역

NVIDIA AI 코어 엔지니어 과정에서 작업한 프로젝트다. 수집, 탐지, 에이전트 실행, 저장, API와 검증 시나리오를 구현했다.

현재 상태: demo 데이터와 선택적 live 수집으로 전체 파이프라인을 실행할 수 있다.

01

Overview

Problem and risk-detection scope of BrandGuard

BrandGuard looks for risk signals in brand mentions from news, blogs, communities and the web. It analyzes mention growth, negative sentiment, risk keywords and propagation patterns, prepares reports, and sends alerts after human approval.

Core capabilities

  • Six feature groups for multidimensional risk signals
  • Normal, caution and alert decisions combining Isolation Forest with promotion rules
  • LangGraph routing that logs normal cases and analyzes only risky cases
  • RAG-supported analysis, Markdown and Word reports, and explicit evidence
  • Slack and email notification only after human approval
  • CLI, Streamlit dashboard and FastAPI REST interfaces

Ownership

This project was developed during the NVIDIA AI Core Engineer course. It implements collection, detection, agent execution, storage, APIs and validation scenarios.

Current status: the full pipeline runs with demo data and optional live collection.

02

아키텍처

수집, 특징, 탐지, Agent와 승인 알림의 흐름

1. 수집과 공통 mention 계약

Naver 뉴스·블로그, RSS와 선택적 Tavily collector가 서로 다른 문서 구조를 title, body, source, author, published time과 URL을 가진 mention으로 정규화한다. source별 cursor와 중복 key가 같은 글의 재수집을 줄이고, 실패한 source는 다른 collector의 결과를 폐기하지 않는다. 원문과 수집 시점을 남겨 이후 보고서가 근거로 돌아갈 수 있게 한다.

2. 시간창과 특징 생성

Feature pipeline은 브랜드별 시간창에서 volume, growth, sentiment, keyword, user와 propagation 여섯 그룹을 계산한다. 최근 창과 29일 baseline을 분리하고 missing 값과 최소 표본을 명시적으로 처리한다. 계산된 feature vector와 baseline version을 저장해 동일 입력의 판정 이유를 재현할 수 있게 한다.

3. 복합 탐지와 severity gate

Isolation Forest가 다변량 이상 score를 만들고 domain rule이 급증률, 부정 비율, 위험 keyword 같은 설명 가능한 조건을 평가한다. combiner가 두 결과를 normal, caution, alert severity로 매핑한다. 모델만 높은 경우와 rule만 높은 경우를 구분해 보고서에 탐지 근거를 남긴다.

4. LangGraph 분석과 Human-in-the-loop

normal은 history에 기록하고 종료한다. caution·alert는 LangGraph의 evidence selection, 원인 가설, 대응안, 보고서 조립 노드를 통과한다. Human Review에서 approve, revise 또는 reject하기 전에는 외부 notification을 만들지 않는다. 승인된 보고서만 Slack·email notifier로 전달하며 설정되지 않은 채널은 console sink로 대체한다.

5. 저장·접근·운영 경계

Repository adapter가 SQLite와 PostgreSQL의 placeholder, auto increment와 UPSERT 차이를 흡수한다. CLI, Streamlit, scheduler와 FastAPI /analyze, /history, /reports, /monitor가 같은 application service를 호출해 판정 로직을 복제하지 않는다. collector 장애, LLM failure와 notifier failure는 단계별 상태로 남고 이미 저장된 detection과 review 기록은 유지된다.

6. 상태·데이터 모델 소유권

공통 mention·window·detection 모델이 수집기와 탐지기 사이 계약이고, RiskState가 LangGraph 실행 중 상태를 소유한다. repository adapter가 영속화 책임을 가져 API·대시보드·scheduler가 SQL 차이를 알지 않는다.

7. 성능·장애 복구

수집 fan-out, sentiment 처리, Isolation Forest fit과 LLM latency가 주요 병목이다. 채널별 timeout·부분 성공, 모델 재사용, bounded window와 idempotent incident 저장을 검증해야 하며 LLM 실패 때 규칙 기반 보고서가 fallback으로 남는다.

8. 보안·관측·기술 부채

API 키는 환경 변수로 격리하고 collector 입력·알림 대상·대시보드 접근을 검증해야 한다. 단계 상태와 저장 기록은 감사 근거를 제공하지만 분산 trace·SLO·실제 알림 승인 정책은 미구현 또는 계획이며 실서비스 precision/recall은 측정되지 않았다.

02

Architecture

Flow from collection and detection to reviewed alerts

1. Collection and mention contract

Naver news and blog, RSS and optional Tavily collectors normalize different documents into mentions with title, body, source, author, publication time and URL. Source cursors and duplicate keys reduce repeated ingestion, while a failed source does not discard successful collectors. Original evidence and collection time remain available to generated reports.

2. Windows and feature generation

The feature pipeline computes volume, growth, sentiment, keyword, user and propagation groups per brand window. Recent input and a 29-day baseline remain distinct, with explicit missing-value and minimum-sample behavior. Feature vectors and baseline versions are stored so a decision can be reconstructed.

3. Combined detection and severity gate

Isolation Forest emits a multivariate anomaly score, while domain rules evaluate explainable conditions such as growth, negative ratio and risk keywords. A combiner maps both outputs to normal, caution or alert. Model-only and rule-only triggers remain distinct evidence in the report.

4. LangGraph and human review

Normal detections are recorded and stop. Caution and alert enter LangGraph nodes for evidence selection, cause hypotheses, response options and report assembly. Nothing reaches an external channel before Human Review approves, revises or rejects the report. Approved reports go to Slack or email, with a console sink when channels are absent.

5. Storage, access and operations

A repository adapter absorbs SQLite and PostgreSQL placeholder, auto-increment and UPSERT differences. CLI, Streamlit, scheduler and FastAPI /analyze, /history, /reports and /monitor use the same application service. Collector, LLM and notifier failures become stage status while persisted detections and review records remain intact.

6. State and data-model ownership

Shared mention, window and detection models form the collector-detector contract, while RiskState owns state during LangGraph execution. The repository adapter owns persistence so API, dashboard and scheduler remain unaware of SQL dialect differences.

7. Performance and failure recovery

Collection fan-out, sentiment processing, Isolation Forest fitting and LLM latency are primary bottlenecks. Per-channel timeouts and partial success, model reuse, bounded windows and idempotent incident writes require validation; a rule-based report remains the LLM fallback.

8. Security, observability and debt

API keys are isolated in environment variables, while collector input, notification targets and dashboard access require validation. Stage status and persisted records provide audit evidence, but distributed tracing, SLOs and production-send approval are missing or planned. Production precision and recall have not been measured.

구조와 데이터 흐름

Structure and data flow

도식을 누르면 크게 볼 수 있습니다. 구현 여부와 참고한 코드도 표시했습니다.

Select a diagram to enlarge it. Labels show implementation status and source files.

01
시스템 컨텍스트 · 신뢰 경계System context · trust boundaries브랜드 운영자, 수집 채널, 탐지·에이전트와 알림 경계입니다.Boundaries across brand operators, collection channels, detection, agent and notifications.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
02
런타임 · 모듈 · 상태 소유권Runtime · modules · state ownership수집기, 특징 빌더, 복합 탐지기, LangGraph 노드와 저장 계층을 분해합니다.Decomposes collectors, feature builder, hybrid detector, LangGraph nodes and storage.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
03
핵심 사용자 흐름 · 요청 시퀀스Core user flow · request sequence신호 수집에서 severity gate, 사람 검토, 보고까지의 에이전트 시퀀스입니다.Agent sequence from signal collection through severity gate, human review and report.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
04
데이터 · 배포 · 보안 · 복구Data · delivery · security · recovery데이터베이스, 서비스 진입점, 비밀·관측과 채널 실패 복구를 표시합니다.Shows databases, service entry points, secrets, observability and channel recovery.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
03

기술적 결정

모델·규칙 결합과 사람 승인에 관한 선택

Isolation Forest와 rule 결합

이상 score만 사용하면 정상 데이터 안에서도 상대적인 최댓값이 위험처럼 보일 수 있다. 학습 분포의 중앙값~99분위로 score를 정규화하고, 부정 비율과 증가율이 함께 큰 경우 rule로 경보를 강제 승격한다.

채널별 감성 backend

짧은 소비자 발화에 맞는 한국어 감성 모델이 긴 경제 뉴스에서 오판하는 사례를 확인했다. 커뮤니티·SNS는 모델을, 뉴스·웹은 사전을 사용하며 모델이 없으면 사전 방식으로 fallback한다.

알림 전 Human-in-the-Loop

자동 경보는 대응 속도는 빠르지만 잘못된 외부 알림의 비용이 크다. 원인과 보고서는 자동 생성하되 실제 Slack·이메일 발송은 사람의 승인 뒤에만 허용한다.

선택 가능한 외부 서비스

LLM이나 Tavily 키가 없어도 rule 기반 원인 분석과 네이버 수집으로 실행되게 했다. 결과 품질 차이는 있지만 전체 pipeline을 재현할 수 있다.

03

Decisions

Model-rule combination and human approval choices

Combine Isolation Forest with rules

An anomaly score alone can make a relative maximum look dangerous even in normal data. Scores are normalized against the training distribution’s median-to-99th-percentile range, while simultaneous high negativity and growth can force an alert.

Route sentiment by channel

The Korean sentiment model worked on short consumer speech but produced errors on long financial news. Community and social text use the model, news and web use a lexicon, and all channels fall back to the lexicon when the model is absent.

Require human approval

Automatic alerts are fast but expensive when wrong. Cause analysis and reports are generated automatically, while external Slack and email delivery remains behind Human Review.

Keep external services optional

Without LLM or Tavily keys, rule-based cause analysis and Naver collection preserve an executable pipeline. Quality differs, but the system remains reproducible.

04

검증

BrandGuard의 합성 시나리오 결과와 해석 한계

자동 시나리오

python tests/test_pipeline.py는 공개 README 기준 5개 파이프라인 검사를 통과한다. 30일 평상시 데이터 뒤에 언급량과 부정 비율이 급증한 2일을 주입한 시나리오에서 위기 구간만 경보하고 앞선 29일은 정상으로 판정했다. 위기가 없는 평상시 시나리오도 정상으로 유지됐다.

근거 출력

경보는 score 하나만 반환하지 않는다. 언급량, 부정 비율, 위험 키워드, 공유량과 직전 평균 대비 증가 배수를 함께 제공해 사람이 승인 판단을 검토할 수 있게 한다.

알려진 한계

해당 결과는 파이프라인 검증용 합성 데이터이며 실제 브랜드 위기의 일반 정확도를 의미하지 않는다. 실서비스 precision, recall과 탐지 지연은 측정되지 않음이다. 검색 markup 변경과 외부 API 제한은 수집량에 영향을 준다.

04

Validation

Synthetic scenario results and interpretation limits

Automated scenarios

The public repository reports five passing checks from python tests/test_pipeline.py. In a scenario with 30 baseline days followed by two injected surge days, the crisis interval was alerted while the preceding 29 days remained normal. A no-crisis baseline scenario also remained normal.

Evidence output

Alerts do not return only a score. Mention count, negative ratio, risk-keyword ratio, shares and growth over the preceding average are provided for human review.

Known limits

These are synthetic pipeline checks, not a general accuracy claim for real brand crises. Production precision, recall and detection latency are not measured. Search markup changes and external API limits can alter collection coverage.

05

로드맵

BrandGuard의 완료 기능과 실사용 전 과제

완료

  • 다채널 mention 수집과 6개 feature 그룹
  • Isolation Forest + rule 기반 3단계 위험 판정
  • LangGraph 조건 분기, 원인 분석과 보고서 생성
  • Human Review 뒤 Slack·이메일·console 알림
  • SQLite/PostgreSQL 저장소, scheduler와 REST API
  • Streamlit dashboard와 합성 pipeline 테스트

진행 중

  • 실제 채널별 수집 안정성과 selector fallback 보강
  • 감성 backend routing과 위험 임계값 검증
  • 보고서 근거와 승인 이력의 추적성 개선

계획

  • 라벨이 있는 실제 사건 데이터로 precision·recall 측정
  • 브랜드·산업별 baseline과 threshold 분리
  • 수집 실패, 중복과 rate limit 관측 지표
  • 인증·권한·감사 기록을 포함한 운영 배포 설계

제외

사람의 승인 없이 외부 대응 메시지를 자동 발송하는 기능은 현재 범위가 아니다. 탐지와 의사결정 지원을 목표로 하며 최종 대응 판단은 사용자에게 남긴다.

05

Roadmap

Completed capabilities and work required for production use

Completed

  • Multi-channel collection and six feature groups
  • Three-level risk decisions using Isolation Forest and rules
  • LangGraph branching, cause analysis and report generation
  • Human-reviewed Slack, email and console notification
  • SQLite/PostgreSQL storage, scheduler and REST API
  • Streamlit dashboard and synthetic pipeline tests

In progress

  • More resilient channel collection and selector fallback
  • Validation of sentiment routing and risk thresholds
  • Stronger traceability between evidence, reports and approval

Planned

  • Precision and recall on labeled real-world incidents
  • Brand- and industry-specific baselines and thresholds
  • Collection failure, duplication and rate-limit observability
  • Production authentication, authorization and audit design

Out of scope

Sending external response messages without human approval is not a goal. BrandGuard supports detection and decision-making while final action remains with a person.

확대 보기Expanded view

도식을 좌우로 이동하거나 확대해 세부 흐름을 확인할 수 있습니다.

Pan or zoom the diagram to inspect the detailed flow.