DataCook DataCook

그림. 화면에 보이는 기록과 실제 모델 입력에 남은 사실은 다를 수 있습니다.reader_decision: 에이전트가 기억하지 못한 원인을 답변의 말투로 추측하지 않고, 실제 모델 입력에 sentinel이 있었는지·잘렸는지·요약에서 보존됐는지를 먼저 확인합니다.핵심 구분화면의 대화 기록, 세션에 남은 파일, 실제 모델 호출에 들어간 context는 서로 다를 수 있습니다. “스크롤하면 보인다”는 사실만으로 모델이 그 내용을 현재 입력에서 보고 있다고 결론내리지 않습니다.방금 말한 파일을 다시 물어본 이유긴 에이전트 작업에서 금지한 파일 규칙이 화면 기록에는 남아 있는데, 모델이 나중에 그 파일을 수정하는 장면을 본 적이 있습니다. 또 대화가 약 30턴을 넘긴 뒤에는 파일명이 여전히 채팅 화면에 보이는데도..

그림. memory는 저장 성공·검색 성공·답변 반영 성공을 따로 확인해야 합니다.reader_decision: 외부 memory를 쓸 때 저장 성공·검색 성공·답변 반영 성공을 세 개의 독립된 사건으로 기록하고, 어느 단계가 실패했는지 확인한 뒤 다음 작업을 진행합니다.저장됐다는 로그는 답이 아닙니다write가 성공했다는 메시지는 backend에 레코드가 실제로 남았다는 증명이 아닙니다. 검색 결과가 나왔다는 사실도 모델이 그 결과를 답변에 사용했다는 증명은 아닙니다. 세 단계를 분리해서 readback합니다.4.3만 건인데 시간축은 거의 비어 있었습니다영속 memory 상태를 점검했을 때 항목은 약 4.3만 건, embedding coverage는 100%로 보였습니다. 그런데 timeline 항목은..

그림. 배치 원가는 공통 비용·개별 비용·실패 비용을 분리해야 설명됩니다.reader_decision: 배치 비용을 결과물 수로 단순히 나누지 않고 공통 비용·개별 비용·실패 비용의 배분 규칙을 먼저 정합니다. 핵심은 분모입니다배치에서 10개를 생성했다는 사실과 3개가 검증을 통과했다는 사실은 서로 다른 카운트입니다. 비용을 나누기 전에 결과물의 상태와 공통 단계의 귀속 규칙을 먼저 고정해야 합니다. 토큰 비용만으로는 배치 원가를 설명할 수 없습니다에이전트 배치에는 공통으로 발생한 프롬프트·검증·정리 비용, 특정 결과물에만 붙은 생성 비용, 실패와 재시도 비용, 사람의 검토와 재작업 시간이 함께 들어갑니다. 토큰 가격만 합치면 숫자는 깔끔하지만, 왜 READY 결과물의 비용이 달라졌는지 설명할 수 없습니..

그림. Test-Time Scaling은 품질·지연·토큰·비용을 같은 문제 집합에서 함께 봐야 합니다.reader_decision: TTS 사용 여부를 정확도 하나로 결정하지 않고, 같은 문제 집합의 품질·문제당 지연·토큰·비용과 변동성을 함께 보고 정합니다.이 글에서 말하는 TTS의 범위추론 시점에 계산을 더 쓰는 방법은 하나가 아닙니다. 아래 결과는 Apple M4 Max에서 실행한 speculative decoding 계열의 관측이며, 모든 Test-Time Scaling 방법의 일반 법칙이 아닙니다. 속도·메모리와 정답 품질을 서로 다른 증거로 분리해 읽습니다.더 빨리 생성됐다는 말만으로는 부족합니다추론 계산을 늘리면 한 문제를 더 오래 생각하거나 여러 후보를 비교할 수 있습니다. 반대로 draf..

핵심: p-value 하나로 중요도를 결론내리지 않고, 효과크기·절대 차이·분산·신뢰구간을 함께 확인합니다.p-value가 작으면 차이도 큰 걸까요? 꼭 그렇지는 않습니다. 표본이 충분히 크면 아주 작은 차이도 통계적으로 유의해질 수 있고, 표본이 작으면 꽤 큰 차이도 유의하지 않을 수 있습니다. 그래서 결과표에서 p-value만 떼어 읽으면 실제 판단에 필요한 크기와 불확실성을 놓치게 됩니다.이번 글에서는 실제 사용자나 고객 데이터 대신, 조건을 공개할 수 있는 합성 fixture 두 개를 고정해 비교했습니다. 두 fixture는 t 통계량과 유의성 판정을 같게 만들었지만, p-value가 같은 것은 아닙니다. 표본 수와 평균 차이를 다르게 설계해 비슷한 p-value가 실제로는 얼마나 다른 차이를 가..

그림. 검정 이름보다 먼저 관측치의 독립성·대응 구조와 비교 질문을 확인합니다.reader_decision: T-test와 Mann-Whitney 중 하나를 고르기 전에 비교 질문·독립/paired 구조·측정 척도·분포를 확인하고, 두 검정으로 닫을 수 없는 경우에는 억지로 선택하지 않습니다.한 줄 결론정규성 검사 결과 하나로 검정을 고르지 않습니다. 무엇을 비교하는지, 관측치가 독립인지 대응되는지, 측정값의 척도와 분포가 어떤지를 먼저 고정한 뒤 그 질문에 맞는 검정을 선택합니다.검정 이름보다 비교 질문이 먼저입니다T-test와 Mann-Whitney는 버튼 두 개 중 하나를 누르는 문제가 아닙니다. 독립된 두 집단의 평균을 묻는지, 같은 대상의 전후 차이를 묻는지, 순위나 분포의 위치를 묻는지에 따라..

그림. 사용량 환산액과 계정 청구액은 서로 다른 장부로 기록해야 합니다.reader_decision: ccusage의 정가 환산액과 실제 결제액을 같은 숫자로 쓰지 않고, 각각 사용 강도와 예산 판단에 따로 사용합니다.이 글의 기준화면에 크게 찍힌 금액을 곧바로 청구액이라고 부르지 않습니다. 사용량 도구의 환산액, 계정의 청구액, 둘을 연결하는 조정 항목을 한 장부의 서로 다른 열로 기록합니다.13만 달러라는 숫자를 먼저 분해했습니다예전에 ccusage로 4개월 사용량을 정산한 글을 썼을 때 가장 먼저 눈에 들어온 숫자는 약 13만 2천 달러였습니다. 하지만 이 숫자는 API 가격표를 사용량에 대입한 정가 환산액이었습니다. 통장에서 빠져나간 실제 결제액을 뜻하지 않았습니다. 숫자가 크다는 사실보다 어떤 ..

그림. 완료 보고의 digest는 목표 파일의 현재 바이트와 다시 대조해야 합니다.reader_decision: 완료 보고에 붙은 digest를 그대로 믿지 않고, 목표 파일의 현재 바이트를 독립적으로 다시 해시하고 검증 시점·commit 또는 버전을 함께 확인합니다.완료의 단위는 말이 아니라 대상 파일입니다“수정했고 테스트가 통과했다”는 보고가 있어도 목표 파일이 바뀌었는지, 그 테스트가 실제 목표를 겨냥했는지, 검증 뒤 파일이 다시 바뀌지 않았는지를 따로 확인합니다. 상태 개수만 세는 checksum과 파일 내용 digest도 같은 것으로 취급하지 않습니다.테스트가 통과했는데 화면은 그대로였습니다이전에 쓴 완료 증거 글에서 가장 먼저 확인한 것은 diff였습니다. AI는 화면 버그를 고쳤다고 했지만 ..