지난해 저는 애그테크(agtech)와 "AI 어시스턴트" 데모에서 동일한 패턴을 계속 목격했습니다. 범용 모델(generic model)을 감싸고 있는 챗봇, 몇 권의 PDF, 그리고 아무도 읽지 않는 면책 조항이 전부였습니다.

저는 개발자이지 농학자가 아닙니다. 하지만 저는 두 가지 관련 프로젝트를 진행하고 있습니다. 하나는 근거 있는 RAG 플랫폼(grounded-llm, 프라이빗 리포지토리)이고, 다른 하나는 이 플랫폼의 첫 번째 프로덕션 형태의 도메인 팩(domain pack)입니다. 이는 러시아 학술지인 'Plodovodstvo i vinogradstvo Yuga Rossii'의 수백 편의 논문을 기반으로 구축된 원예 어시스턴트입니다(사과, 배, 자두 등 약 500편의 소스 논문을 기반으로 하며, 블로그 포스트 5개 수준이 아닙니다).

저는 단순히 "정원사를 위한 ChatGPT"를 원하지 않았습니다.
저는 실제로 문헌을 읽은 사람처럼 행동하며, 문헌이 질문에 대한 답을 포함하고 있지 않을 때는 이를 인정하는 답변을 원했습니다.

그 격차를 메우기 위해 수개월간의 엔지니어링 작업이 이어졌습니다. 저는 이 이야기를 공개적으로 공유하지만, 전체 코퍼스(corpus)와 코드베이스는 비공개로 유지합니다.

가장 먼저 무너진 것: "그럴듯하게 들림" ≠ "정답임"
초기 실험들은 지루하고 반복적인 방식으로 실패했습니다.

1. 도메인 언어가 범용 검색(generic retrieval)과 일치하지 않음
러시아 원예 분야는 대목(rootstock) 라벨, 질병 이름, 지역 품종 등 동의어와 표기 변형으로 가득 차 있습니다. 사용자가 'марссониоз'라고 쓰면, 문헌에는 'Marssonina', 약어, 또는 OCR 노이즈가 섞인 철자로 되어 있을 수 있습니다. 단순한 검색(naive retrieval)은 이를 놓치고, 모델은 그 공백을 자신 있게 채워버립니다.

2. 과학 텍스트는 FAQ 형태가 아님
논문에는 실험 섹션, 표, "재배자를 위한 요약" 블록 등이 포함되어 있습니다. 모든 것에 동일한 청크 크기(chunk size)를 적용하면, 올바른 논문을 찾더라도 잘못된 단락을 가져오게 되어 유창하지만 틀린 답변을 내놓게 됩니다.

3. 생성(Generation)은 검색(retrieval) 문제를 해결하기 위한 적절한 장소가 아님
올바른 구절이 프롬프트(prompt)에 도달하지 못한다면, 어떤 시스템 프롬프트도 당신을 구할 수 없습니다. 저는 초기에 관심사 분리(separation of concerns)를 수행했습니다:

Python 서비스 → 검색 전용 (/rag/context)
Go 서버 → 세션, LLM 호출, 답변 정제, 가드레일(guardrails)

이는 마이크로서비스(microservices)가 유행이라서가 아니라, 제품 전체를 재배포하지 않고도 검색 기능을 변경하고 측정해야 했기 때문입니다.

내가 구축한 것: 두 개의 레이어, 하나의 제품

레이어	내용
플랫폼 코어 (grounded-llm)	인증 (Telegram + API 키), Postgres 세션, 오케스트레이션 (orchestration), 배포
도메인 팩 (원예)	코퍼스 (corpus), 작물 설정, 프롬프트 (prompts), 평가 기준선 (eval baselines)

플랫폼이 사과 질병에만 고정되어 있지 않음을 보여주기 위해, 동일한 파이프라인을 사용하는 비농업용 샌드박스(demo_hr — 인사(HR) 정책 문서)도 마련했습니다.

원예 팩은 학술지 코퍼스에서 추출한 약 14,500개의 텍스트 청크 (text chunks) 순서로 인덱싱됩니다. 이 정도 규모에서는 "벡터 검색 (vector search)만 하면 된다"거나 "프롬프트에서 해결하면 된다"는 식의 접근은 더 이상 신뢰할 수 없습니다.

저는 전체 논문 텍스트를 오픈 소스로 공개하지는 않습니다 (저작권 및 집중도 문제). 대신 아키텍처의 교훈, 실패 사례, 그리고 지표들을 공유하며, 누군가의 시간을 들일 가치가 있을 때 통제된 데모를 제공하고자 합니다.

나를 정직하게 유지하게 만든 한 가지 질문
우리 지역의 경사지/테라스 재배 연구에서 어떤 대목 (rootstocks)과 수형 (training systems)이 등장하는가?

범용 LLM은 품종과 숫자를 지어냅니다.
근거 있는 (grounded) 시스템은 관련 실험 맥락(대목, 재식 거리, 지형, 지역 시험 등)을 검색해오거나, 그렇지 못할 경우 답변을 거부해야 합니다.

이러한 요구 사항 때문에 제가 봐왔던 대부분의 튜토리얼용 RAG 스택들은 제외되었습니다. 또한, 모델이 질병 이미지로 실제로 학습되기 전까지는 "마케팅용 사진 → 질병 진단"을 핵심 기능으로 내세우는 것도 배제했습니다. 비전 (Vision) 기능은 로드맵에 포함되어 있으며, 현재 프로덕션 단계에 맞춘 것은 논문에 근거한 텍스트 기반 시스템입니다.

의도적으로 (아직) 최적화하지 않은 것들

• 멀티 테넌트 (Multi-tenant) SaaS 과금 체계
• 바이럴 중심의 B2C Telegram 성장
• ImageNet 백본 (backbone)을 이용한 진단 수준의 비전 기능 주장

내가 최적화한 것들:

• 회귀 테스트 (regression-test)가 가능한 검색 (Retrieval)
• 사용자가 보기 전에 검증(gate)할 수 있는 답변
• 몇 달이 아닌 며칠 만에 다른 수직 시장 (vertical)용으로 재포장할 수 있는 플랫폼

다음 단계 (파트 2)
파트 1은 '이유'에 대한 것이었습니다.

파트 2는 모든 것을 바꾼 결정에 관한 것입니다. 즉, 단 하나의 생성 토큰(generated token) 비용을 지불하기 전에, 고정된 도메인 질문 세트(현재 사과, 배, 자두 및 HR 샌드박스에 걸친 68개 질문)가 검색을 통과할 때까지 파이프라인을 신뢰하지 않는다는 결정입니다.

스포일러: 그 단계에 도달하는 방법은 "더 큰 임베딩 모델 (embedding model)을 사용하는 것"이 아니었습니다. 그것은 청킹 (chunking), 하이브리드 검색 (hybrid search), 재순위화 (reranking), 용어집 확장 (glossary expansion)과 같은 화려하지 않은 엔지니어링 작업이었으며, 포스트마다 한 단계씩 자세히 풀어내겠습니다.

이 내용이 공감된다면
저는 전체 코퍼스 (corpus)를 GitHub에 쏟아붓는 방식이 아니라, 글쓰기를 통해 공개적으로 구축(building in public)하고 있습니다.

Part 2를 보려면 Dev.to를 팔로우하세요
규제 대상 분야나 과학적 도메인에서 유사한 RAG 실패 모드 (failure modes)를 경험했다면 댓글을 남겨주세요
짧은 데모(HR 샌드박스 또는 제한된 원예 미리보기)를 원하시면 연락해 주세요 (GitHub / 프로필의 이메일)
면책 조항: 어시스턴트의 출력은 정보 제공용입니다. 현장 결정에는 현지 전문가와 규정을 준수하는 제품 라벨이 필요합니다.