데모 환경 · 의사·병원·평가 정보는 모두 가상이며 대화는 미리 준비된 시나리오입니다
메디나침반

진행 계획

서버 구조 · 안전 설계 · 검수 계획 · 미정 항목 의견 · 주차별 일정

1챗봇 서버 구조

앱 / 웹발주사챗봇 API조건 추출LLM질환 탐색사전 + 의미 검색DB 조회·정렬서버 코드답변 생성LLM답변 검증지어내기 차단응답 (검증 통과한 이름·수치·링크만)

LLM은 조건 추출과 문장 작성에만 씁니다. 의사·병원 선택과 순서는 서버 코드가 DB에서 정합니다.

챗봇 서버
Node.js (TypeScript)
자체 저장소
PostgreSQL + pgvector (사전·벡터·대화 상태·로그)
발주사 의사·병원 DB
읽기 전용 연결 + 변경 감지로 검색 색인 자동 갱신
LLM
상용 LLM API. 발주사 1차 챗봇과 같은 GPT 계열을 기본으로, 조건 추출은 빠르고 저렴한 모델, 답변은 상위 모델로 나눕니다. 검증 시나리오로 비교 후 확정.

2지어내기·진단 단정을 막는 설계

  • 답변에 들어가는 이름·수치·링크는 DB 조회 결과에서만 가져옵니다.
  • 생성 후 검증: 이름·병원·수치를 대조하고, 실패 시 문장 삭제 후 재생성, 그래도 실패하면 결과 카드만 안내합니다.
  • 증상 입력 시 질환명을 단정하지 않고 진료과 매핑표로 안내하며, 응급 의심 표현은 119·응급실 안내를 먼저 합니다.
  • 질환 일반정보는 등록된 근거 자료 범위에서만 답하고 출처를 표시합니다.

3완료 기준과 검수 계획

품질

검증 시나리오 240건 내외(분류 7개), 시나리오 단위 합격률 95% 이상, 중대 결함 0건

성능

첫 글자 p95 2초 이내, 전체 답변 p95 6초 이내, 동시 50 대화 10분간 오류율 1% 미만

측정: 시나리오 자동 실행 도구 + 부하 테스트. 결과는 대화 전문과 기대·실제 대조표로 제출합니다. 중간 검수 7주차, 최종 검수 10주차.

4아직 정하지 않은 범위에 대한 의견

① 1차 챗봇 — 서버는 새로 구축하는 것이 기본입니다. 살릴 수 있는 것은 실제 이용자 질문 기록(검증 시나리오 원천), 이미 정리한 동의어, 답변 말투 규칙입니다.

② 사전·프롬프트 관리 — 기본은 파일 교체 + 반영 전 자동 점검. 운영자가 자주 고친다면 관리 화면을 추가합니다. 같은 저장소 구조를 쓰므로 나중에 붙여도 서버를 고칠 일이 적습니다.

③ 질환 일반정보 근거 자료 — 공신력 있는 공개 자료를 수집·선별하고, 의료 내용 최종 확인은 발주사가 맡는 구조를 제안합니다.

5운영 비용 산정 기준

하루 대화 수 × 대화당 LLM 호출 수(약 2~3회) × 호출당 토큰 × 모델 단가

실제 대화 기록이 쌓이면 다시 계산해 드립니다.

6주차별 일정 (11주)

1~3주
요구사항·데이터·안전 정책 협의
검증 시나리오 초안 · 사무실 방문 미팅
4~7주
조건 추출·질환 탐색·매칭·대화 상태 개발
7주차 중간 검수
8~9주
웹·앱 API 연동, 답변 검증·예외 처리, 성능 튜닝
10주
최종 검수·보완 후 재검수
11주
발주사 서버 배포·복구 구성·안정화
매뉴얼 인도