Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
DentaNote는 오디오 입력만으로 구조화된 치과 진료 기록을 작성하는 로컬 도구입니다. Whisper로 음성을 전사하고, Gemma를 활용하여 추출 및 검증 과정을 거쳐 임상 기록을 생성합니다. 이 파이프라인은 수작업 대비 시간을 획기적으로 단축하며, 데이터가 외부로 유출되지 않는 높은 개인정보 보호 수준을 제공합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기저는 환자를 만나고 방문 기록을 구술하며, 여전히 구조화된 기록을 만드는 데 시간을 잃습니다. 필드, 치아 번호, 모든 과정이 그렇습니다. DentaNote는 제가 이 단계를 줄이기 위해 만든 도구입니다: 오디오 입력으로 구조화된 임상 기록 출력, 오직 로컬에서 100% 실행되며 제 기기를 벗어나는 데이터가 단 한 바이트도 없습니다.
Whisper를 사용한 전사(transcription), Gemma를 통한 Ollama 기반 추출, 스키마 검증, 그리고 렌더링까지의 전체 파이프라인은 30초 오디오 클립을 완전한 기록으로 변환하는 데 11.2초가 걸렸습니다 (전사: 7.7초; 추출: 2.1초; 렌더링은 결정론적 템플릿이라 시간 측정에 포함되지 않습니다).
CPU에서 작동하는 작은 Whisper 모델은 실시간보다 약 3.8배 빠르게 전사합니다. 따라서 3분 분량의 구술 기록은 약 45초 만에 텍스트가 되고, 여기에 추출에 약 2초가 더해져 — 제가 완전히 구술로 작성했을 기록을 한 분 이내에 처리할 수 있습니다.
저 자신의 기준으로는: 구조화된 방문 기록을 타이핑하는 데 약 10분이 걸립니다. 파이프라인의 1분 미만 소요 시간과 비교하면, 이는 진료당 대략 9분의 절약이며 — 하루 종일 여러 번의 진료를 거치면 이 시간이 한 건의 진료에 해당하는 작업량 이상으로 누적됩니다.
▶ 2분짜리 데모 시청하기 — 터미널에서 dentanote run visit.wav를 실행하면 완성된 기록, 항상 보이는 초안 경고 및 검토가 필요한 uncertain_items이 표시되는 Streamlit 인터페이스가 열립니다.
제가 실제로 실행해 본 데모: 두 가지 합성 케이스, 오디오를 기록으로 변환했으며, 타이밍은 metrics.jsonl에 기록되어 있습니다 (지속 시간과 카운트만 — PHI는 없으며, 자동화된 테스트가 이를 보장합니다).
uv sync && dentanote doctor # Ollama, 모델 및 GPU 확인
dentanote run visit.wav # 오디오 -> 구조화된 임상 기록
uv run streamlit run src/dentanote/app.py # 업로드 인터페이스
localhost:11434입니다. 이는 "믿어달라"는 것이 아니라 아키텍처 문제입니다.| Model | Precision (정밀도) | Recall (재현율) | F1 | Hallucination (환각) | uncertain_items | Avg. latency (평균 지연 시간) |
|---|---|---|---|---|---|---|
gemma4:e4b | 0.92 | 0.89 | 1.00 | 11.1% | 100% | 1.70 s |
gemma3:4b | 0.75 | 0.65 | 0.92 | 31.8% | 100% | 5.59 s |
두 모델 모두 첫 시도에서 100%의 유효한 JSON을 생성했습니다. 두 모델 모두 동일한 사례(urgencia_dor, 치아 47 대신 치아 37로 예측 — 모델이 아치에 있는 이웃을 "선택"함)에서 실패했습니다. 폐쇄형 API를 사용하면 저처럼 모델을 교체하고 비교할 수 없었습니다. (저의 코퍼스, 저의 하드웨어, 원하는 만큼 여러 번).
flowchart LR
A[Audio wav/mp3] --> B[Local Whisper]
B --> C[Ollama + Gemma]
...
고전적인 "LLM이 치과 사실을 지어내는" 실패를 방지하는 세 가지 결정:
format을 통한 구조화된 출력 (JSON Schema) — 제약 디코딩(constrained decoding)은 스키마 외부 토큰에 0 확률을 부여합니다. 그럼에도 불구하고, 클라이언트는 Pydantic으로 검증하는데, 이는 '사고하는' 모델이 스키마를 건너뛸 수 있기 때문입니다 (네, 정말로 발생합니다 — 레포지토리의 ADR-001에서 문서화됨).uncertain_items를 안전장치로 사용. 유효하지 않은 FDI 번호? 모호하게 언급된 치아? 이는 임상의가 확인하도록 목록화되며, 절대 조용히 해결되지 않습니다. 제가 겪은 사례 중 하나에서는 FDI 56 (잘못된 사분면의 어금니)이 폐기되어 정확히 그 형태로 노출되었습니다.구조: 7단계(phases), 단계별 커밋(commit), 매 단계마다 린트 및 테스트 수행(오늘 153개 테스트), 레포지토리에 짧은 ADR 작성.
gemma4:e4b는 11.1%의 사례에서 최소한 하나의 항목을 발명했으며 (gemma3:4b는 31.8%), 이것이 출력이 **항상 수정 가능한 초안(revisable draft)**인 이유입니다 — 이는 서명된 기록이 아니라 사전 채우기(pre-filling)입니다.libcublas.so.12 누락) — CPU 폴백이 실시간으로 작동했지만, '로컬'이라는 것이 곧 '당신이 기술 지원 담당자'라는 것을 상기시켜 줍니다.scripts/make_synthetic_audio.py에 더 많은 TTS 음성 및 언어가 추가되었습니다 (ES/EN의 이중 언어 파이프라인 테스트를 위한 합성 오디오).expected/ 폴더가 패키징되었으며, scripts/evaluate.py에서 각각의 영향을 측정합니다.이 저장소는 MIT 라이선스 하에 오픈 소스로 공개되었습니다. 만약 임상 기록을 다루고 절차 어휘를 조정하거나 자신의 하루 케이스(필연적으로 합성)를 추가하고 싶다면, 이슈와 CONTRIBUTING.md 파일을 참고하세요.
GitHub에서 저장소 확인 · README의 법적 및 윤리적 고지
think=false를 강제하고, 제약된 디코딩을 사용하더라도 항상 클라이언트에서 검증하는지.왜 중요한가: 환자 데이터의 경우, '오픈'은 미적인 선호도가 아니라 오프라인에서 감사할 수 있는 유일한 아키텍처입니다.
AI 에이전트의 도움을 받아 작성된 게시물입니다 ("some_ai" 공개 표시 on DEV).
#hf26challenge #devchallenge