부분 문서 수정 기능의 v2·v3 설계안과 구현 로드맵을 정리합니다. 아래 내용은 당시의 제안이며, 전체 구현이 완료됐다는 의미는 아닙니다.

PlanWeave의 문제 정의, 문서 생성 파이프라인과 서비스 기능을 정리합니다.

문서 부분 수정 배치 실험의 결과표와 20개 사례입니다. 각 사례의 Original Content와 Regenerated Content를 펼쳐 수정 전후를 비교할 수 있습니다.

보험 답변에서 가장 위험했던 오류는 모른다고 말하는 것이 아니었습니다. 약관에 “보상하지 않는다”고 적혀 있는데 보상받을 수 있다고 답하는 것이었습니다. Insurance_PF를 시작할 때는 PDF를 잘 나누고 도메인 모델을 학습하면 보험 질의응답의 정확도가 높아질 것으로 생각했습니다. 실험을 끝내고 보니 전처리, 검색, 생성은 기본 조건일 뿐이었습...

모델은 자신 있게 6,000만 원이라고 답했습니다. 약관의 계산 조건을 다시 적용하면 2,400만 원이었습니다. 문장은 자연스러웠지만 답은 틀렸습니다. Insurance_PF에서 파인튜닝을 적용한 이유는 보험 지식을 모델 파라미터에 모두 넣기 위해서가 아니었습니다. 일반적인 답변보다 보험 상담 문체에 가까운 설명을 만들고, 검색한 약관을 읽는 방식을...

처음에는 Kiwi가 보험 용어를 가장 잘 처리할 것으로 예상했습니다. 긴 복합명사를 보존하고 사용자 사전을 붙이기 쉬웠기 때문입니다. 30개 FAQ를 검색해보니 Mecab이 더 높은 순위에 정답을 올렸고 인덱싱도 빨랐습니다. 예상과 결과가 달랐던 첫 실험이었습니다. 세 토크나이저는 서로 다른 표현에서 강했다 Kiwi, Mecab, Okt를 법률 ...

“제3조”만 남은 chunk는 검색할 수 있어도 무슨 담보의 제3조인지 알기 어렵습니다. 자동차 보험 약관에는 보통약관, 특별약관, 담보, 조, 항이 겹쳐 있습니다. 표 안의 금액과 본문의 조건이 서로 연결되기도 합니다. Insurance_PF에서는 글자 수를 기준으로 자르기 전에 약관의 제목 경로를 복구하는 데 시간을 썼습니다. 원문을 요약하지 ...

검색 평가에서는 50개 질문 중 대부분의 정답 문서를 찾았습니다. 그런데 최종 답변에서는 “보상하지 않는다”는 조항을 놓쳤습니다. 아내가 운전한 차에 치인 상황에서도 Base Model, Fine-Tuned Model, RAG 조합이 모두 틀린 답을 만들었습니다. Insurance_PF는 자동차 보험 약관을 검색하고 일반 사용자의 질문에 답하는 개인...

생성 프롬프트를 고쳐 citation precision을 올렸는데 citation recall이 내려갔습니다. 더 엄격하게 인용하도록 만들면 근거를 잘못 붙이는 경우는 줄었지만, 답변을 지지하는 근거 일부가 citation에서 빠졌습니다. Solar Pro 3 generation v2 repaired를 기본값에서 뺀 이유입니다. 한 지표가 좋아졌다는...

HyDE를 5개 질문에 적용했을 때 Recall@5가 0.25 올랐습니다. 이 결과만 남겼다면 “HyDE로 검색 성능을 개선했다”고 쓸 수 있었습니다. 평가 범위를 40개로 늘리자 결과가 달라졌습니다. Recall@5는 0.033333 올랐지만 MRR은 0.035, nDCG@5는 0.018384 내려갔습니다. 생성 호출 때문에 지연시간도 늘었습니다....