대부분의 RAG 데모는 영어 PDF로 시작합니다. 하지만 SVSU Knowledge Assistant는 힌디어와 영어로 된 지저분한 종이 공지사항 더미에서 시작했습니다. 이 문서들은 각도에 맞춰 복사된 스캔본이었고, 줄이 그어진 표들로 가득했으며, 답변을 찾아야 하는 대학 직원들에게 필요했습니다. 제가 이것을 구축하면서 배운 순서대로 정리해 보았습니다.
OCR 품질이 모든 것을 결정한다
저는 처음 몇 주 동안 검색(retrieval)과 모델에 집중했습니다. 그곳부터 시작해야 했습니다. 만약 OCR에서 나오는 텍스트가 깨지거나 틀리면, 그 이후의 어떤 것도 좋을 수 없습니다. 세 가지 요소가 모든 것을 바꾸어 놓았습니다:
-
페이지별 스크립트 감지: Tesseract를 실행하기 전에 페이지별로 스크립트를 감지하고 적절한 언어 모델을 사용해야 합니다. 일부 페이지는 힌디어와 영어가 혼합되어 있습니다. 따라서 두 가지 모두 실행하고, 신뢰도가 더 높은 것을 선택합니다.
-
표 셀 단위 재구성: 공지사항은 대부분 표로 이루어져 있습니다. 학비 일정, 학사 일정, 코드 목록 등이 그렇죠. 원시 OCR 출력물은 표를 뒤죽박죽으로 만듭니다. 줄이 그어진 선을 감지하고 각 셀을 읽음으로써,
의미론적 검색(Semantic search)은 "연체료 정책이 무엇인가요?" 같은 질문에는 잘 작동합니다. 하지만 "코드 EX-2024-17은 뭐라고 말하나요?"와 같은 것에는 완전히 실패합니다. 공지사항들은 코드, 날짜, 정확한 금액으로 가득 차 있습니다. 사람들이 실제로 검색하는 것은 바로 그런 것들입니다. 해결책은 검색(retrieval)이었습니다:
- 질문을 쿼리이자 힌디어 쿼리로 재작성합니다. 사용자들은 힝글리시(Hinglish)로 말하고 문서도 어느 언어일 수 있습니다.
- 벡터 검색(vector search)을 실행하여 유사한 구절을 찾습니다.
- 코드, 날짜 및 희귀 토큰에 대한 매칭을 실행합니다.
- 결과를 병합하고 크로스 인코더 모델(cross-encoder model)을 사용하여 재순위화(re-rank)합니다.
재순위화기(re-ranker)가 프로젝트 전체에서 가장 큰 개선점이었습니다.
구절로부터 답변을 생성한 후, 그 답변을 확인하기
언어 모델은 검색된 구절들을 받아 오직 그것들만을 사용하여 번호가 매겨진 인용과 함께 답변하도록 요청받습니다. 그런 다음 두 번째의 더 빠른 모델이 출처와 비교하여 답변을 검사합니다. 이 모델은 뒷받침되지 않은 모든 주장을 표시합니다. 이러한 오류는 드뭅니다. 하지만 신뢰를 무너뜨릴 수 있는 바로 그 오류들입니다.
답변들은 작성되는 대로 스트리밍됩니다. 덕분에 검색에 시간이 걸리더라도 전체 과정이 빠르게 느껴집니다.
지루한 부분들이 제품이다
-
문서가 검토될 때까지 사용될 수 없도록 하는 초안-활성 승인 워크플로우(draft-to-active approval workflow).
-
역할 및 문서별 가시성(Roles and per-document visibility). 일부 공지사항은 직원들을 위한 것입니다.
-
대량 처리. 자동 만료(Bulk. Automatic expiry). 종료 날짜가 있는 공지사항은 자동으로 폐기됩니다.
-
2단계. 잠금 기능(Two-step. Lockouts). 이것은 대학 데이터입니다. 보안이 중요합니다.
-
자동 답변 품질 테스트(automatic answer-quality test). 알려진 정답이 있는 질문 세트가 모든 푸시마다 CI에서 실행됩니다. 만약 검색 과정에 퇴보가 생기면 배포가 실패합니다.
CI/CD는 GitHub Actions에서 AWS 서버로 Docker와 Caddy를 사용하여 실행됩니다. 특별한 것은 없습니다. 그것이 핵심입니다.
하나의 API, 두 개의 클라이언트
웹 앱은 Next.js로 구축되었고, 안드로이드 앱은 Flutter를 사용합니다. 두 앱은 API와 동일한 계정을 공유합니다. 모바일 앱은 종이 편지 사진을 찍어 스캔된 내부 공지사항을 보여줄 수 있습니다. CI(Continuous Integration)에서 모든 화면을 휴대폰 뷰포트로 테스트하는 위젯 테스트가 수행됩니다. 이미 견고했던 API를 기반으로 두 번째로 앱을 구축하는 데는 웹 앱을 만들 때보다 훨씬 적은 시간이 걸렸습니다.
다르게 하고 싶은 점
-
채팅 UI가 아닌 OCR 평가 세트부터 시작해야 합니다.
-
청킹(chunking)을 문서 구조와 연관시켜야 합니다. 행, 섹션 단위로요. 처음부터 고정된 창 크기가 아니라요.
-
승인 워크플로우에 대한 시간을 초기에 배정해야 합니다. AI가 아닌 것이 데이터 모델을 더 많이 형성했습니다.
스캔된 문서 더미를 가지고 있고 팀이 신뢰할 수 있는 무언가가 필요한 경우, 제가 하는 일이 바로 이런 종류의 작업입니다. AI 어시스턴트 서비스 페이지에 버전 정보가 있습니다. 프로젝트 페이지에는 스크린샷이 있습니다.
원래 게시된 곳: abhishekdev.online. 저는 인도 메루트에서 웹사이트, Laravel 앱 및 AI 도구를 구축하는 웹 개발자입니다.