실제 적용 가이드¶
RAG4U의 DB tools 구조는 데모 DB에만 묶인 형태가 아닙니다. 실제 PostgreSQL에 연결하고, 현장 시스템의 테이블 구조에 맞게 tool 쿼리를 바꾸면 운영 데이터 조회용으로 확장할 수 있습니다.
적용 원칙¶
운영 적용에서 가장 중요한 원칙은 LLM에게 DB 전체를 열지 않는 것입니다.
나쁜 방식: LLM이 SQL 생성 -> DB 실행
권장 방식: LLM이 업무 tool 선택 -> 앱이 검증된 read-only 쿼리 실행
RAG4U는 두 번째 방식을 사용합니다.
연결 방식¶
.env에서 실제 DB 연결 문자열을 지정합니다.
APP_ENABLE_AGENT_TOOLS=true
APP_TOOL_DB_URL=postgresql://rag4u_reader:password@db-host:5432/operations
운영 DB 계정은 필요한 테이블만 읽을 수 있어야 합니다.
CREATE USER rag4u_reader WITH PASSWORD 'change-me';
GRANT CONNECT ON DATABASE operations TO rag4u_reader;
GRANT USAGE ON SCHEMA public TO rag4u_reader;
GRANT SELECT ON assets TO rag4u_reader;
GRANT SELECT ON alarm_events TO rag4u_reader;
GRANT SELECT ON sensor_readings TO rag4u_reader;
GRANT SELECT ON maintenance_records TO rag4u_reader;
실제 스키마에 맞추기¶
현재 데모 tool은 다음 테이블을 기준으로 합니다.
assets
alarm_events
sensor_readings
maintenance_records
실제 DB 테이블명, 컬럼명, 시간 컬럼, 상태값이 다르면 app/tools/postgres.py의 tool별 쿼리를 수정합니다.
| 현재 tool | 실제 적용 예 |
|---|---|
get_alarm_history |
MES, SCADA, 설비 알람 테이블 |
get_sensor_trend |
Historian, IoT telemetry, sensor fact table |
get_maintenance_history |
CMMS, EAM, 작업오더 테이블 |
새 업무가 필요하면 raw SQL 입력창을 만들지 말고 tool을 추가합니다.
get_work_order_status
get_equipment_status
get_production_loss
get_quality_events
RAG와 DB 역할 분리¶
실제 적용에서는 문서와 DB의 역할을 명확히 나누는 것이 품질을 좌우합니다.
| 데이터 | 담당 |
|---|---|
| 매뉴얼, 기준서, 정책, 절차 | RAG |
| 최신 상태, 수치, 알람, 작업 이력 | DB tool |
| 원인 추정, 조치 요약, 비교 설명 | LLM |
예시:
P-101 진동 알람의 최근 발생 이력과 매뉴얼상 점검 절차를 같이 알려줘.
이 질문에서 최근 발생 이력은 DB tool, 점검 절차는 RAG, 최종 요약은 provider가 담당합니다.
운영 전 체크리스트¶
- read-only DB 계정을 사용합니다.
- tool별 row limit을 둡니다.
- 시간 범위 기본값을 둡니다.
- provider로 전송되는 DB 결과 preview를 제한합니다.
- 민감 컬럼은 tool 쿼리에서 제외합니다.
tool_calls이력을 저장하고 화면에 노출합니다.- 실제 답변 사용 전 citation과 tool 결과를 사람이 확인하는 절차를 둡니다.
데모에서 운영으로 넘어가는 순서¶
- 데모 DB로 tool calling 흐름을 확인합니다.
- 실제 DB의 읽기 전용 계정을 만듭니다.
- 현재 3개 tool 중 하나를 실제 테이블에 맞게 연결합니다.
- 샘플 질문 10개를 만들어 tool 선택과 row 결과를 검증합니다.
- 문서 RAG와 함께 묻는 복합 질문을 검증합니다.
- 사내 사용자에게 공개하기 전 외부 전송 동의와 보안 문구를 확정합니다.