TL;DR

• 의사록 생성은 「녹음 → 텍스트 변환 (Transcription) → 정형화」가 정석으로 소개되지만, 실무 입력값은 대부분 낙서 같은 메모이며, LLM은 그것만으로도 충분히 읽어낼 수 있다.
• 하지만 제약을 걸지 않으면, LLM은 메모에 없는 결정 사항을 보완한다. 의사록이라는 문서 종류에서는 치명적이다. 효과가 있었던 것은 「추측으로 보완하지 말 것」 + 「불명확한 점은 『확인 필요』 섹션으로 격리할 것」 이 두 가지다. 반대로 포맷 지정에 공을 들이는 것은 거의 효과가 없었다.

배경

팀 회의에서 의사록 담당이 될 때마다, 낙서 같은 메모를 정리하는 데 20~30분을 쓰고 있었습니다. 텍스트 변환 기반의 워크플로우는 녹음 동의나 툴 도입이 필요하여, 사내의 작은 정기 회의에는 너무 무겁습니다.

그래서 「낙서 같은 메모를 그대로 붙여넣는」 운용을 수 주간 지속하며, 프롬프트를 깎아 나간 결과가 본 기사입니다.

최종 형태의 프롬프트

당신은 의사록 작성 전문가입니다. 다음은 나의 회의 낙서 메모입니다.
이를 배포용 의사록으로 정리해 주세요.
조건:
...

왜 「추측으로 보완하지 말 것」이 본질인가

LLM은 확률(Likelihood)이 높은 다음 내용을 생성하기 때문에, 의사록 템플릿의 「결정 사항」란이 비어 있으면 그럴듯한 결정 사항을 채워 넣으려 할 때가 있습니다. 실제로 이 한 줄을 넣는 것을 잊었을 때마다, 회의에서 말하지 않은 사양이 ToDo에 혼입되었습니다.

요약 계열 태스크의 환각 (Hallucination)은 「출력을 인간이 전문 리뷰하는 것」으로 방지하는 것이 정공법이지만, 그렇게 하면 정리 시간을 절약할 수 없습니다. 그래서 불확실성을 「■ 확인 필요」 섹션에 격리시키는 설계로 만들면, 인간의 리뷰 범위를 해당 섹션으로만 좁힐 수 있습니다. 전문 리뷰보다 빠르고, 방치하는 것보다 안전하다는 트레이드오프(Trade-off)의 위치입니다.

효과가 없었던 것

• 출력 포맷의 상세 지정 (표 형식, 들여쓰기 지정 등): 외관은 변하지만 정확성에는 기여하지 않는다.
• Few-shot 예시 동봉: 낙서 메모는 매번 형태가 너무 달라서, 예시가 오히려 출력을 예시에 끌려가게 만든다.
• 메모의 사전 정리: LLM 측의 독해에는 불필요하다. 정리할 바에는 직접 의사록을 쓰는 게 더 빠르다.

요약

의사록 프롬프트 설계는 「예쁘게 정형화시키는 것」보다 「거짓말을 쓰지 않게 함 + 불명확한 점을 격리함」에 투자하는 것이 리턴이 더 크다는 것이 수 주간 운용한 결론입니다. 동일한 구조(추측 금지 + 확인 필요 섹션)는 사양서 초안이나 장애 보고서 초안 등, 정확성이 필요한 다른 문서 생성에도 그대로 유용할 수 있습니다.

이 기사는 AI의 지원을 받아 집필되었으며, 인간이 내용을 확인 및 편집하여 공개하고 있습니다.

Discussion