At softly, we tried to automate customer support for clinics. The AI part worked — FAQs, multi-step lookups, even reasoning about clinic policies. The support part didn't.

People don't message a clinic to ask what's on the website. They want someone who knows the things the website doesn't say — can this procedure fix my specific case, will it hurt more than last time, if I'm combining two procedures which order matters — and who can solve their problem right now.

Each question is an edge case. Getting one wrong isn't just bad service — a hallucinated answer about a procedure is dangerous. Generalization and hallucination come from the same place.

But even accurate answers weren't enough. The job was conversion — turning that anxious inquiry into a patient who actually walks through the door. Every rule we wrote implied ten more we hadn't thought to write. The gap never closed.

Coding agents already ship features^[1]. Design tools generate layouts from prompts. Customer support looks like the obvious next step — text-based work, recognizable patterns^[2]. In 2011, Gartner predicted that by 2020, customers would manage 85% of their relationship with an enterprise without interacting with a human^[3]. Fifteen years later, the job still exists.

This is an English translation of the Korean version.

I kept reading that qbits can represent \(2^n\) states simultaneously, and I kept nodding along. Then I asked myself three questions and couldn't answer any of them.

In mid-2022, I typed a prompt into platform.openai.com and got back something that didn't feel like a demo.

It was text-davinci-002. Before ChatGPT, before the hype. But it wasn't the output that mattered. It was the feeling: this is going to break everything we know about building AI products.

Building a good AI model meant collecting data, training, and fine-tuning for specific tasks. Hard, slow, expensive work. Davinci-002 could do a rough version of most of it with just a prompt — plain English, no data, no training, no cost.

My co-founders and I were already building softly, an AI startup. A few months later, ChatGPT launched and everyone else felt it too.

Our team has joined HealingPaper — known as 강남언니 (UNNI) in Korea. I'm leading AI product. Here's what we learned getting here.

Git은 한 브랜치에서 작업한 내용을 Main 브랜치에 병합(Merge)할 수 있는 다양한 방법들을 제공한다. 이러한 방법들을 Merge 전략이라고 부르는데, 다양한 방법들 중에서도 이번 글에서는 가장 많이 사용되는 방법인 1) Merge Commit, 2) Squash and Merge, 3) Rebase and Merge에 대해 소개하려고 한다.

최근에 pytorch로 간단한 모듈을 재구현하다가 loss와 dev score가 원래 구현된 결과와 달라서 의아해하던 찰나, tensor 차원을 변경하는 과정에서 의도하지 않은 방향으로 구현된 것을 확인하게 되었다. 그리고 그 이유는 transpose 와 view 의 기능을 헷갈려했기 때문이었다. 두 함수의 차이는 contiguous 를 이해해야 알 수 있는 내용이었고, 혹시 이 개념이 헷갈리는 사람들을 위해 간단한 예시를 바탕으로 정리해보았다.

PyTorch 1.2 이상부터 torch.utils.data 에서는 크게 map-style dataset (torch.utils.data.Dataset) 과 iterable dataset (torch.utils.data.IterableDataset) 의 두 종류의 데이터 클래스를 지원하고 있다. 데이터 사이즈가 클 때는 IterableDataset 을 사용하는 것이 좋은데, Dataset 과는 딜리 아직 개발되어야 할 기능이 더 필요한 클래스라서 사용할 때에 유의할 점이 있어 정리해보게 되었다.

pandas는 데이터를 다루는 사람들이라면 누구나 쓸 수 밖에 없는 오픈소스 라이브러리이다. table 형식의 데이터를 다루기에 편리하지만 오픈소스라는 특징과 다양한 기능 지원 때문에 속도 면에서는 최적화되어 있지 않은 편이다. 이번 글에서는 pandas의 여러 기능 중에서 iteration하는 여러 방법을 속도와 사용성 측면에서 비교해본 내용을 아주 간단하게 정리해 보았다.

약 4-5개월동안 사이드로 진행했던 혐오 댓글 프로젝트^[1]가 성공적으로 마무리되었다. 같은 문제의식을 가진 사람들과 시작해서 각자 하고싶었던 내용을 조율하고, 혐오 댓글이 무엇인가에 대해 깊게 고민해보는 과정들이 쉽진 않았지만 의미있는 활동이라는 생각이 들었다. 또한, 사이드로 진행된 프로젝트임에도 불구하고 원동력이 사라지지 않고 꾸준히 일이 진행되었던 것은 모두 구성원들의 상호보완적인 역량 덕분이 아니었을까 싶다.

사실 이 글을 쓰게 된 계기는 논문에는 쓰지 못했던 데이터에 대한 이야기를 하고 싶어서였다. 주어진 4장에 많은 내용을 담으려다보니 정작 작업하면서 고려했던 세부사항이나 어려웠던 점, 지나고나니 아쉬웠던 부분들에 대해 적진 못했기 때문이다. 아마 데이터셋을 활용하려고 생각하는 사람들에게도 좋은 팁이 되지 않을까?

최근에 있었던 구글의 양자 우월성 (Quantum Supremacy) 달성은 전세계적으로 큰 화제였다. 물 들어올 때 노 저으라고 하지 않았던가, 이 때가 아니면 또 언제 양자컴퓨터에 대해 공부할까 싶어서 텍스트와 동영상을 넘나들며 관련 지식을 습득해보았다.