부산 AI 개발 · RAG
RAG 챗봇은 모델보다 데이터에서 먼저 실패합니다
사내 문서를 검색해 답하는 RAG는 문서가 어디에 어떤 상태로 있는지가 성패의 대부분을 정합니다. 착수 전에 확인할 여섯 가지와, 각 항목이 왜 답변 품질로 이어지는지를 적었습니다.
Direct answer
한 문장으로 답하면
사내 문서 RAG 챗봇을 만들기 전에 확인할 것은 여섯 가지입니다 — 어떤 문서가 어디에 있고 최신본이 무엇인지, 누가 무엇을 볼 수 있는지(권한), 중복·구버전이 섞여 있는지, 개인정보·계약 정보가 들어 있는지, 답이 맞는지 판정할 질문 세트가 있는지, 문서가 바뀌면 누가 갱신하는지. SMK Labs는 이 점검을 데이터 연결 단계로 두고, 문서와 업무 지식을 검색·인용 가능한 답변 흐름으로 연결한 뒤 오답·누락·권한 오류·비용·지연을 검증합니다. 부산을 포함한 전국 방문·원격으로 진행합니다.
특정 모델·정확도 수치·배포 환경을 미리 약속하지 않습니다. 보안·운영 조건을 확인한 뒤 제안서에서 정합니다.
Checklist
착수 전 확인할 여섯 가지
각 항목의 두 번째 문장은 그것이 빠졌을 때 실제로 생기는 증상입니다.
01
문서 목록과 최신본
어떤 문서가 답변의 근거가 될지, 각 문서의 최신본이 어디 있는지. 없으면 챗봇이 구버전 규정을 자신 있게 인용합니다.
02
접근 권한
누가 어떤 문서를 볼 수 있는지의 규칙이 문서 저장소에 이미 있는지. 없으면 챗봇이 권한 밖 내용을 답하거나, 반대로 아무것도 답하지 못합니다.
03
중복·버전·형식
같은 내용의 문서가 여러 벌인지, 스캔 이미지·표·첨부 안에 핵심이 있는지. 중복은 서로 다른 답을, 이미지 속 표는 빈 답을 만듭니다. OCR·문서 처리가 선행 작업이 될 수 있습니다.
04
개인정보·계약 정보
문서에 개인정보나 계약 조건이 있는지, 외부 모델 API 로 보낼 수 있는지. 이 조건이 아키텍처와 비용을 가장 크게 바꾸며 착수 전에 정해야 합니다.
05
평가 질문 세트
실제 사용자가 물을 질문 20~50개와 정답 근거 문서. 없으면 "잘 되는 것 같다"는 느낌만 남고, 검증 단계에서 오답·누락을 잴 수 없습니다.
06
갱신 주체와 주기
문서가 바뀌면 누가 언제 반영하는지. 정하지 않으면 챗봇은 운영 첫 달부터 낡기 시작합니다. 운영·유지보수 범위에 이 항목을 넣습니다.
How we work
SMK Labs가 RAG를 다루는 순서
문제 정의(어떤 질문에 답해야 하는가) → 데이터 연결(위 여섯 가지 점검, 품질·보안 조건 설계) → 구축(검색·인용 가능한 답변 흐름) → 검증(정상 답변뿐 아니라 오답·누락·권한 오류·비용·지연) → 운영(갱신·관측·개선 인계). RAG는 업무 자동화·AI 에이전트·API 연동과 함께 쓰이는 경우가 많아, 범위는 문제 정의 단계에서 함께 정합니다.
RAG 구축 데이터 준비에 대해 자주 묻는 질문
Q01사내 문서 RAG 챗봇을 만들려면 어떤 데이터가 필요한가요?
근거가 될 문서의 목록과 최신본, 문서별 접근 권한 규칙, 중복·구버전 정리 상태, 개인정보·계약 정보 포함 여부, 실제 질문 20~50개와 정답 근거, 문서 갱신 주체. 이 여섯 가지를 아는 만큼만 적어 문의하시면 데이터 연결 단계에서 함께 점검합니다.
Q02문서가 PDF 스캔본이나 이미지면 어떻게 하나요?
OCR·문서 처리로 텍스트와 표를 먼저 추출·검수하는 선행 작업이 됩니다. 이 범위는 견적에 별도 항목으로 구분합니다.
Q03정확도를 얼마나 보장하나요?
수치를 미리 약속하지 않습니다. 대신 착수 전에 평가 질문 세트를 함께 만들고, 검증 단계에서 오답·누락·권한 오류·비용·지연을 그 세트로 측정해 수용 기준을 합의합니다.
Q04외부 모델 API 를 쓸 수 없는 환경도 가능한가요?
보안·운영 조건을 확인한 뒤 제안서에서 배포 환경과 모델 선택을 정합니다. 외부 API 사용 가능 여부는 아키텍처와 비용을 가장 크게 바꾸는 조건이라 문의 단계에서 먼저 알려 주시면 좋습니다.
답해야 할 질문과 지금 가진 문서부터 알려주세요
문서가 흩어져 있어도 괜찮습니다. 어떤 질문에 답해야 하는지와 문서가 어디 있는지를 적어 주시면 데이터 연결 단계의 확인 항목부터 안내합니다.