데이터베이스24분
PostgreSQL은 단순한 데이터베이스가 아니다: 알아두면 좋은 확장 프로그램 총정리
PostgreSQL을 처음 접하면 MySQL과 비슷한 관계형 데이터베이스라고 생각하기 쉽습니다.
PostgreSQL을 처음 접하면 MySQL과 비슷한 관계형 데이터베이스라고 생각하기 쉽습니다.
에이전트 RAG라는 말을 처음 들었을 때 떠올린 그림은, 모델이 스스로 판단해 도구를 부르는 거였습니다. "이 질문은 검색을, 이 질문은 DB 조회를" 모델이 결정하고, 그 결과를 받아 다시 답을 쓰는 구조. 그런데 막상 작은 로컬 모델로 이걸 짜려니 한 가지가 걸렸습니다. 도구를 고르는 결정을 모델에게 맡길 수가 없었…
처음 RAG를 짤 때는 문서를 고칠 때마다 전체를 다시 색인했습니다. 문서가 백 개쯤 될 때는 그래도 됐습니다. 잠깐 기다리면 끝났거든요. 그런데 문서가 천 개를 넘고, 거기에 재고 아이템까지 색인에 들어가니 얘기가 달라졌습니다. 전체를 다시 임베딩하면 수천 번 모델을 부르는 셈이고, 그 사이에 질문이 들어오면 답이 늦…
처음 RAG를 짤 때는 벡터 검색만 썼습니다. 코사인 유사도 하나로 충분할 줄 알았죠. 그런데 한국어 질문에서 이상한 일이 잦았습니다. 분명 문서에 있는 단어를 물었는데 검색이 안 됩니다. 비슷한 의미의 다른 문서만 계속 위에 뜹니다. 원인을 찾다 보니, 벡터 검색이 "의미가 비슷한가"는 잘 재는데 "그 단어가 실제로 …
RAG 답변 품질을 재는 정량 프레임워크가 있습니다. RAGAS, TruLens 같은 도구가 답변의 충실도(faithfulness), 관련성, 맥락 적합성을 점수로 냅니다. 처음엔 이런 걸 달아야 하나 고민했습니다. 그런데 막상 혼자 쓰는 RAG를 짜고 보니, 정량 점수보다 답이 거짓말을 안 하게 만드는 "코드"가 먼저…
멀티모달 RAG라는 말을 처음 들었을 때, 이미지를 임베딩해서 문서 텍스트와 같은 벡터 공간에 올리는 걸 상상했습니다. CLIP 같은 모델로 그림과 글을 하나의 공간에 두면, "이런 느낌의 다이어그램 찾아줘" 같은 질문도 답이 나올 것 같았죠.
RAG를 "문서 검색"이라고만 생각하면 놓치는 게 많습니다. 제가 실제로 자연어로 묻고 싶은 질문의 절반은 문서가 아니라 데이터베이스에 들어있는 구조화된 데이터에 대한 것이었습니다. "이 철제장에 뭐 있지", "이 브랜드 물건 중 정리 대기 걸린 건 뭐지", "유효기간 지난 거 있어?". 이런 건 문서로 안 적어둡니다.…
ChatGPT에 문서를 전부 올리면 끝나는 일 아닌가,라고 한동안 생각했습니다. 그런데 제가 쓰는 데이터를 전부 올리는 건 사정이 달랐습니다. 재고 목록, 영업 리드, 기도 기록, 가계부까지 한 사람의 전 삶이 들어있는 DB였거든요. 그래서 로컬 LLM 기반 RAG를 직접 짰습니다. 이 글은 그 과정에서 내린, 그리고 …
사내 문서 1,290건을 넣어 둔 RAG 챗봇이 있습니다. 검색은 그럭저럭 맞는 문서를 찾아오는데, 답변이 계속 얕았습니다. 맞는 말이긴 한데 한 줄로 끝나거나, "문서에서 충분한 근거를 찾지 못했습니다"가 나오는 일이 잦았습니다.
사내 문서에 AI 챗봇을 붙이면 도입 첫 달이 제일 똑똑합니다. 문서 열 개짜리 인덱스에서는 뭘 물어도 정답 문서가 걸리니까요. 그런데 반년쯤 지나 문서가 수백 개로 불어나면 슬슬 이상한 답이 늘어납니다. "데이터를 더 넣었는데 왜 더 멍청해지지?"라는 질문은 RAG를 운영해 본 팀이라면 반드시 만나는 질문입니다.
사내 데이터에 AI 챗봇을 붙이면 누구나 한 번쯤 이런 질문을 던지게 됩니다.
사내 문서를 근거로 답하는 RAG 챗봇을 도입하면 대부분 비슷한 지점에서 막힙니다. 첫 질문에는 그럴듯하게 답하는데, 이어서 "그럼 그건 언제 바뀐 거야?" 같은 질문을 던지면 갑자기 엉뚱한 문서를 근거로 들고 옵니다. 사용자는 "AI가 헛소리를 한다"고 느끼고, 도입은 거기서 멈춥니다.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.
RAG 시스템에는 검색 결과가 질문과 충분히 관련 있는지 판단하는 기준이 필요합니다. 기준이 너무 낮으면 무관한 문서를 근거로 답하고, 너무 높으면 답이 있는 질문도 “근거가 없다”고 처리합니다.
문서 RAG를 처음 만들 때는 “문서를 검색하고 모델에 넣으면 된다”는 설명이 충분해 보입니다. 실제 서비스에 붙이기 시작하면 질문이 달라집니다. 문서를 언제 나누고, 어떤 기준으로 다시 색인하며, 관리자 문서와 공개 문서를 어떻게 분리하고, 답변의 근거를 사용자가 어떻게 확인하게 할 것인가가 중요해집니다.
문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.
사내에 AI를 도입하려는 회사가 가장 먼저 부딪히는 질문이 있습니다. "모델 하나면 되는 것 아닌가요?"
DUOLABS AI의 기능을 하나씩 살펴보는 연속 기획 첫 번째 글입니다. 첫 주제는 사내 문서에서 근거를 찾아 답하는 지식베이스와 RAG 질의응답입니다.