<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>파인튜닝 on monkshark.dev</title><link>https://monkshark.github.io/tags/%ED%8C%8C%EC%9D%B8%ED%8A%9C%EB%8B%9D/</link><description>Recent content in 파인튜닝 on monkshark.dev</description><generator>Hugo -- gohugo.io</generator><language>ko</language><lastBuildDate>Mon, 20 Jul 2026 12:00:00 +0900</lastBuildDate><atom:link href="https://monkshark.github.io/tags/%ED%8C%8C%EC%9D%B8%ED%8A%9C%EB%8B%9D/index.xml" rel="self" type="application/rss+xml"/><item><title>#3 - 모른다고 말할 수 있게 만들기</title><link>https://monkshark.github.io/p/dodam-say-i-dont-know/</link><pubDate>Mon, 20 Jul 2026 12:00:00 +0900</pubDate><guid>https://monkshark.github.io/p/dodam-say-i-dont-know/</guid><description>&lt;p&gt;파이프라인에 빈 칸이 하나 있었다. 로컬 데이터베이스에도 없고 식약처 가이드라인에도 걸리지 않는 성분이 나오면 뭘 보여줄 것인가.&lt;/p&gt;
&lt;h2 id="그냥-ai-한테-맡기자"&gt;&lt;a href="#%ea%b7%b8%eb%83%a5-ai-%ed%95%9c%ed%85%8c-%eb%a7%a1%ea%b8%b0%ec%9e%90" class="header-anchor"&gt;&lt;/a&gt;그냥 AI 한테 맡기자
&lt;/h2&gt;&lt;p&gt;팀원 하나가 말했다. 모델이 알아서 그럴듯한 답을 만들게 하면 되지 않냐고.&lt;/p&gt;
&lt;p&gt;틀린 말로 들리지 않는다는 게 문제였다. 데모에서는 그쪽이 확실히 낫다. 심사위원 앞에서 제품을 스캔했는데 &amp;ldquo;정보가 없습니다&amp;quot;가 뜨면 그건 실패한 데모처럼 보인다. 빈 화면보다 뭐라도 나오는 게 낫다는 논리는, 적어도 해커톤의 문법 안에서는 합리적이다.&lt;/p&gt;
&lt;h2 id="비대칭"&gt;&lt;a href="#%eb%b9%84%eb%8c%80%ec%b9%ad" class="header-anchor"&gt;&lt;/a&gt;비대칭
&lt;/h2&gt;&lt;p&gt;나는 반대했다.&lt;/p&gt;
&lt;p&gt;임산부가 이 앱을 믿고 장바구니에 담는다. 틀린 답을 보여주면, 그 사람은 그게 틀렸는지 모른 채로 결제하고 며칠 뒤에 먹는다. 나는 그 사람이 누군지도 모르고, 앱은 아무 일 없었다는 듯 다음 화면으로 넘어간다.&lt;/p&gt;
&lt;p&gt;그 비대칭이 무서웠다. 이 앱이 잘못했을 때 대가를 치르는 쪽과, 잘못한 걸 아는 쪽이 다르다. 앱은 절대 모른다. 사용자만 안다. 그것도 나중에, 혹은 영영 모른 채로.&lt;/p&gt;
&lt;p&gt;일반적인 서비스라면 틀린 추천은 불편으로 끝난다. 여기서는 아니었다. 우리가 고른 사용자와 고른 주제가 그런 자리였다.&lt;/p&gt;
&lt;h2 id="답이-없는-것과-틀린-답이-있는-것"&gt;&lt;a href="#%eb%8b%b5%ec%9d%b4-%ec%97%86%eb%8a%94-%ea%b2%83%ea%b3%bc-%ed%8b%80%eb%a6%b0-%eb%8b%b5%ec%9d%b4-%ec%9e%88%eb%8a%94-%ea%b2%83" class="header-anchor"&gt;&lt;/a&gt;답이 없는 것과 틀린 답이 있는 것
&lt;/h2&gt;&lt;p&gt;설득은 쉽지 않았다. 결과물이 당장 덜 화려해 보이니까.&lt;/p&gt;
&lt;p&gt;그래서 계속 같은 걸 물었다. 답이 없는 것과 틀린 답이 있는 것 중 뭐가 더 위험하냐고.&lt;/p&gt;
&lt;p&gt;답이 없으면 사용자는 다른 방법을 찾는다. 검색하거나, 의사한테 묻거나, 그냥 담지 않는다. 판단이 사용자에게 되돌아간다. 틀린 답이 있으면 사용자는 찾기를 멈춘다. 이미 답을 받았다고 생각하니까. 우리가 제일 하면 안 되는 일은 사용자의 탐색을 끊고 그 자리에 잘못된 확신을 놓는 거였다.&lt;/p&gt;
&lt;p&gt;비어 있는 화면은 정직하다. 채워진 화면은 정직할 수도 있고 아닐 수도 있는데, 사용자는 그 둘을 구분할 방법이 없다.&lt;/p&gt;
&lt;h2 id="모른다고-말하도록-파인튜닝했다"&gt;&lt;a href="#%eb%aa%a8%eb%a5%b8%eb%8b%a4%ea%b3%a0-%eb%a7%90%ed%95%98%eb%8f%84%eb%a1%9d-%ed%8c%8c%ec%9d%b8%ed%8a%9c%eb%8b%9d%ed%96%88%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;모른다고 말하도록 파인튜닝했다
&lt;/h2&gt;&lt;p&gt;결국 데이터가 부족하거나 희귀 성분이 나오면, 모델이 추론을 멈추고 데이터 없음이라고 말하도록 파인튜닝했다.&lt;/p&gt;
&lt;p&gt;말로는 한 줄인데, 이게 기본 동작의 반대라는 게 핵심이다. 언어 모델은 빈칸을 채우도록 만들어진 물건이다. 모르는 걸 물어도 뭔가는 내놓는다. 그럴듯함을 만드는 게 그 모델의 일이니까. 그래서 모른다는 출력은 가만히 두면 안 나온다. 명시적으로 가르쳐야 나온다.&lt;/p&gt;
&lt;p&gt;우리가 준 건 지식이 아니라 경계였다. 여기까지가 네가 아는 범위고, 그 밖에서는 말을 멈춰라.&lt;/p&gt;
&lt;h2 id="화려함-하나를-포기했다"&gt;&lt;a href="#%ed%99%94%eb%a0%a4%ed%95%a8-%ed%95%98%eb%82%98%eb%a5%bc-%ed%8f%ac%ea%b8%b0%ed%96%88%eb%8b%a4" class="header-anchor"&gt;&lt;/a&gt;화려함 하나를 포기했다
&lt;/h2&gt;&lt;p&gt;이 결정으로 데모에서 보여줄 수 있는 그림 하나를 잃었다. 어떤 걸 찍어도 답이 나오는 앱이라는 그림.&lt;/p&gt;
&lt;p&gt;대신 앱이 거짓말을 안 하게 만들었다. 도담도담이 뭔가를 안전하다고 말하면 그건 근거가 있어서 말한 거고, 모른다고 말하면 정말 모르는 거다. 이 두 문장이 항상 참이어야 앱이 임산부에게 쓰일 자격이 있다고 생각했다.&lt;/p&gt;
&lt;h2 id="돌아보면"&gt;&lt;a href="#%eb%8f%8c%ec%95%84%eb%b3%b4%eb%a9%b4" class="header-anchor"&gt;&lt;/a&gt;돌아보면
&lt;/h2&gt;&lt;p&gt;기술적으로 어려운 결정은 아니었다. 어려웠던 건 곧 심사를 받는 상황에서, 심사에 덜 유리한 쪽을 고르는 일이었다.&lt;/p&gt;
&lt;p&gt;지금도 이 프로젝트에서 내가 제일 잘한 일을 하나만 꼽으라면 이걸 꼽는다. 모델한테 모른다고 말할 능력을 준 것.&lt;/p&gt;</description></item></channel></rss>