LightRAG 지식 허브 · 메일 에이전트
에이전트 4곳이 같은 지식 허브에서 근거를 찾고, 메일은 근거 있는 초안만 직원 초안함에 갑니다
벤더 CS, 인플루언서 CS, Spark, 판매 파트너사 매칭이 LightRAG 지식 허브(워크스페이스 13개) 하나를 같이 씁니다. 질문마다 자료를 먼저 찾아 붙여 답하는 RAG 저장소입니다. 워크스페이스마다 설명·주인·채널·민감도가 붙어 있고, 모르는 워크스페이스에 쓰려 하면 바로 오류가 납니다. 공용 메일함 문의에는 근거를 붙인 답장 초안을 담당자 Gmail 초안함에 넣습니다. 보내는 일은 직원이 합니다.
- 워크스페이스 이름이 어긋나면 서버가 뜨지 않습니다. 에이전트마다 이름을 달리 부르면 쓰기가 엉뚱한 저장소로 갈 수 있습니다. 정식 이름 13개는 Literal 타입으로 고정하고, 별칭 약 50개는 저장소 하나로 모읍니다. 모듈을 불러올 때 누락이나 저장소 불일치가 보이면 RuntimeError로 기동을 멈춥니다.
- LLM 검색 계획은 검증을 통과해야 씁니다. 계획은 Pydantic으로 검사합니다. 실시간 DB 조회는 등록된 (프로젝트, 테이블) 조합만 허용하고, GET만 쓰며 최대 500행입니다. 호출·파싱·허용 목록 중 하나만 실패해도 규칙 라우터로 돌아갑니다. 이유는 fallback:<예외명>으로 남깁니다.
- 리랭크가 실패하면 두 단계 더 대신합니다. 문서를 20개로 자른 뒤 LLM 리랭커가 먼저 실행합니다. 실패하면 FlashRank, 그것도 실패하면 원래 순서에 점수를 매겨 결과는 늘 나옵니다. 검색 단계 동시 실행은 3으로 낮췄습니다. 그 덕에 병합 단계의 Neo4j 동시 쓰기가 문서당 8개에서 6개로 줄었습니다.
- 초안 검사기 13개가 오류 패턴을 하나씩 맡습니다. 요청 방향 반전, 없던 이전 메일 언급, 확정 조건 되묻기, 제안가를 확정가처럼 쓰기 같은 패턴입니다. 검사기마다 08-21~08-23 실제 메일 재현 사례를 넣었습니다. 처음엔 정규식이었는데 오탐이 이어져, 판정은 LLM 검사기로 옮겼습니다.
- 새 거짓말을 만든 수정은 받지 않습니다. 위반 점수 합만 비교하면 2점짜리 사실 위반이 10점짜리 금지어를 고친 대가로 통과합니다. 그래서 고쳐 쓴 초안에 없던 사실 위반이 새로 생기면, 다른 위반을 고쳤어도 그 수정을 버립니다. 고쳐도 남는 위반은 종류별로 "Draft rejected"를 남기고 폐기합니다.
- 근거 묶음은 한 번만 보냅니다. 주장 6개를 검증할 때마다 최대 15만 자짜리 근거 묶음을 다시 보내고 있었습니다. 묶음을 sha256 키로 5분 캐시해 다시 씁니다. 캐시가 실패하면 원래 방식으로 돌아가므로 판정 결과는 달라지지 않습니다.
- 보낸 메일 커서는 Gmail 지연까지 셈합니다. 배포 때 보낸 메일 1,943건 중 48건이 학습에서 빠졌습니다. 지금은 10분 단위로 읽고 단위마다 커서를 저장합니다. 검색 인덱스가 늦게 잡히니 커서는 현재보다 180초 뒤에 두고, 경계는 90초 겹쳐 읽습니다. 500건이 넘는 단위에서는 커서를 밀지 않습니다.
- 직원이 고친 사실은 서버가 범위를 정합니다. 고친 사실이 회사 전체 것인지 거래 하나의 것인지는 서버 규칙으로 판단합니다. 거래 하나의 사실을 파트너 전체로 넓히지 않습니다. 결과는 추가 전용 관찰 로그에만 쌓고, 초안과 검색에는 쓰지 않는 섀도 모드로 돌립니다.