Copy English

Why

The motivating slide for every fault-detection project says the same thing, and it says more than it means to. Unplanned downtime costs multiples of planned maintenance; the failure modes underneath it are safety, quality and throughput. That is a correct and well-known argument. What is usually missed is that it has already specified the model — a statement that missing a failure costs ten to a hundred times more than an unnecessary inspection is a statement about where the alert threshold goes, and it was available before anyone touched the data.

The part the slide does not say is that the saving is a function of time, not of correctness. Three different problems share the name: detection asks whether behaviour is abnormal now, diagnosis asks what is abnormal, and prognosis asks when it will fail. The economics quoted are prognosis economics, and they only pay out if the warning arrives with enough room to act. A model that flags a bearing two hours before seizure, in a plant where the spare takes three days, has converted an unplanned stop into a slightly better-documented unplanned stop. The lead time has to exceed the time to repair, and the time to repair is an organisational fact that can be measured this week without a single model.

That reframing changes what the first deliverable is. Not accuracy on a held-out set, but a horizon: given how long a repair actually takes, how much warning is required before an alert is worth acting on. Every modelling decision downstream — the label horizon, the feature window, the sampling rate — is set by that number. Projects that skip it end up optimising a metric that is real and a product that is not, and the failure is invisible in every plot they produce.

Then the data problem, which is the opposite of what people expect. The machines whose downtime is expensive are the machines that rarely fail — that is the same sentence said twice. So labelled failures are scarce, often a few dozen across years, and frequently not labelled at all: a maintenance log records that a bearing was replaced, not that degradation began eleven days earlier. Supervised classification on that is not a hard problem, it is an under-specified one. The workable route is to model normal behaviour and score deviation from it, which trades a labelling problem for a different and more honest one — an anomaly is not a failure. Most deviations in real plant data are sensor faults, maintenance actions, product changeovers and ambient shifts. The base rate of "anomaly that turns out to be an impending failure" is the number that decides whether an alarm is worth anything, and it is almost never measured.

Finally, this domain triggers every leak in the-split-is-the-experiment at once, plus one of its own. Sensor data is ordered in time, grouped by machine, and labelled by a forward window — so a random split lets the future predict the past, a time-only split lets the model memorise machine identity and then fail on a new installation, and a forward-horizon label overlaps the validation period even after a clean date cut. The extra one is specific to this literature: run-to-failure datasets are pre-truncated, ending at the failure they document, so remaining useful life is partly inferable from position in the file. A model can learn that the recording is ending rather than that the bearing is degrading, and it will score beautifully right up until it meets a machine that is still running.

How it works

Three problems wearing one name

The value of the whole thing is a function of lead time minus time to act, and that difference can be negative while every accuracy metric looks excellent. A detector that is perfect and late is worth zero, which is not a statement about models at all.

The cost ratio is the threshold

Let k = cost(missed failure) / cost(false alarm). The motivating slide asserts k is somewhere between ten and a hundred. Three consequences follow immediately:

• F1 assumes k = 1. Precision and recall are weighted equally, which is a claim that an unnecessary inspection costs exactly as much as a destroyed machine. Nobody believes that, and models are tuned on it constantly.
• At k = 10 you should accept roughly ten false alarms per catch. That feels wrong to operators and is arithmetically correct, which is exactly the conversation the number exists to make possible.
• The threshold precedes the data. This is the same point the-70-has-to-be-wrong makes about probabilistic output — a threshold is a statement about costs, not a property of the model — and here the costs were written on slide one.

One honest correction to the arithmetic. Alarm fatigue is a real cost that does not appear in cost(false alarm). If operators stop investigating after the twentieth false alarm, the effective k collapses toward one, because a missed failure is now certain rather than unlikely. So "ten false alarms per catch" is an upper bound set by economics, not a target, and the binding constraint is usually the credibility budget rather than the inspection cost.

Why the first model should not be supervised

The cheapest first artifact is not a model at all. Take the anomalies the plant already noticed and label their causes from the maintenance log. If most of them are changeovers and sensor faults, the honest conclusion is that the project's first deliverable is a changeover detector, and finding that out costs a day rather than a quarter.

The build: a cost curve, not a model

1. Time to repair — from maintenance, not from data. Sets H.
2. The cost ratio — from the motivating slide. Sets the threshold.
3. Any scorer — a moving-average residual on one sensor is enough to draw the curve. indicators-add-a-decision applies directly: the transform adds no information, it adds a decision, and the decision is where the value is.
4. Sweep the threshold, plot expected cost per machine-month, and report the threshold, the lead time it buys, and the false-alarm rate at that point.

The baseline is the part people get wrong. It is not "do nothing". Almost every plant already runs schedule-based maintenance, which prevents some failures at a known cost. A model that beats doing nothing and loses to replacing the part every six months is a negative result that looks like a positive one, and only the cost curve shows it.

Where it lands in Jayverse

• Devnet: set alert thresholds by repair time, not model accuracy. For any Devnet/Anvil node-health or RPC-failure monitor, log the actual restart/redeploy time first — that number is the horizon below which an alert is worthless, and it comes from ops, not from a model.
• gitboard: report threshold, lead time, and false-alarm rate, not a red/green light. Any anomaly indicator on the dashboard should ship with the cost ratio it was tuned against, so a viewer can see what it costs to ignore versus to chase.
• Auditor: write the cost ratio k before tuning any alert. For liquidation, slashing, or oracle-dispute monitors, state cost(missed event) versus cost(false alarm) up front, and compare against the honest baseline — the schedule or check already in place — not against doing nothing.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

제품은 리드타임이다 — 고장 나는 순간 감지한 것은 값이 0이다

고장 감지를 설득하는 슬라이드는 비용비를 말합니다 — 비계획 다운타임은 계획정비의 수배~수십 배. 그 비율은 동기가 아니라 경보 임계값입니다. 다만 그 절감은 경보가 수리를 잡을 수 있을 만큼 일찍 올 때만 존재하므로, 프로젝트의 첫 숫자는 수리 소요시간 분포이고 모델이 필요 없습니다.

아직 범위 미정이고, 처음 두 단계에는 데이터 과학이 전혀 들어가지 않습니다. 첫째, 해당 설비의 수리 소요시간 분포를 구합니다 — 작업지시부터 기계가 다시 도는 데까지, 부품 조달 리드타임 포함. 이 숫자가 그 아래로는 어떤 경보도 값이 없는 지평 H 를 정하고, 이건 모델링이 아니라 정비팀에 물어서 나옵니다. 둘째, 슬라이드가 이미 주장하는 비용비를 받아 적습니다. 그게 경보 임계값이니까요. 그다음에야 모델이고, 그건 사소해도 됩니다 — 센서 하나에 이동평균 잔차만 있어도 곡선은 그려집니다. 임계값을 훑으며 그 비용비로 기계·월당 기대비용을 그리고, 숫자 셋을 보고합니다 — 선택한 임계값, 그것이 사주는 리드타임, 그 임계값에서의 오경보율. 비교 대상은 "아무것도 안 하기"가 아니라 이미 돌고 있는 주기적 정비 간격입니다.

왜

모든 고장 감지 프로젝트의 동기 슬라이드는 같은 말을 하고, 자기가 뜻한 것보다 많은 말을 합니다. 비계획 다운타임은 계획정비의 수배~수십 배이고, 그 아래 고장 양식은 안전·품질·생산성입니다. 맞고 잘 알려진 논증입니다. 보통 놓치는 것은 그 문장이 이미 모델을 명세했다는 점입니다 — 고장을 놓치는 비용이 불필요한 점검의 10~100배라는 진술은 경보 임계값을 어디 둘지에 대한 진술이고, 데이터를 만지기 전에 이미 손에 있었습니다.

슬라이드가 말하지 않는 부분은, 그 절감이 정확도가 아니라 시간의 함수라는 것입니다. 한 이름을 공유하는 서로 다른 문제가 셋입니다 — 탐지는 지금 이상한가, 진단은 무엇이 이상한가, 예지는 언제 고장 나는가. 인용된 경제성은 예지의 경제성이고, 행동할 여유를 두고 경보가 와야만 지급됩니다. 소착 2시간 전에 베어링을 잡아내는 모델은, 예비품 조달이 3일 걸리는 공장에서는 비계획 정지를 조금 더 잘 기록된 비계획 정지로 바꾼 것입니다. 리드타임이 수리 소요시간을 넘어야 하고, 수리 소요시간은 모델 하나 없이 이번 주에 잴 수 있는 조직의 사실입니다.

이 재구성이 첫 결과물을 바꿉니다. 홀드아웃 정확도가 아니라 지평입니다 — 수리가 실제로 얼마나 걸리는지를 감안할 때, 경보가 행동할 값어치를 가지려면 얼마나 미리 와야 하는가. 그 아래 모든 모델링 결정이 — 라벨 지평, 피처 윈도, 샘플링 주기 — 그 숫자로 정해집니다. 이 단계를 건너뛴 프로젝트는 지표는 진짜인데 제품은 아닌 것을 최적화하게 되고, 그 실패는 자기가 그리는 어떤 그림에도 나타나지 않습니다.

그다음은 데이터 문제인데, 사람들이 예상하는 것과 정반대입니다. 다운타임이 비싼 기계는 좀처럼 고장 나지 않는 기계입니다 — 같은 문장을 두 번 말한 것이죠. 그래서 라벨된 고장은 희소하고(수년에 걸쳐 수십 건), 아예 라벨이 없는 경우도 잦습니다 — 정비 기록은 베어링을 교체했다고 적지 열하루 전에 열화가 시작됐다고 적지 않습니다. 그 위의 지도학습은 어려운 문제가 아니라 미명세된 문제입니다. 쓸 만한 경로는 정상을 모델링하고 이탈을 점수화하는 것이고, 이건 라벨링 문제를 다르고 더 정직한 문제로 바꿉니다 — 이상은 고장이 아닙니다. 실제 공장 데이터의 이탈 대부분은 센서 고장, 정비 작업, 품종 교체, 외기 변화입니다. "이상 중에서 실제로 임박한 고장이었던 것의 비율"이 경보의 값어치를 결정하는 숫자이고, 거의 아무도 재지 않습니다.

마지막으로, 이 도메인은 the-split-is-the-experiment 의 누수를 한꺼번에 전부 켜고, 자기만의 것을 하나 더 얹습니다. 센서 데이터는 시간순이고, 기계로 그룹져 있고, 미래 창으로 라벨됩니다 — 그래서 무작위 분할은 미래가 과거를 예측하게 하고, 시간만 나눈 분할은 모델이 기계 정체성을 외우게 해서 신규 설치 기계에서 무너지며, 미래 지평 라벨은 날짜를 깨끗이 잘라도 검증 구간과 겹칩니다. 하나 더는 이 분야 고유의 것입니다: run-to-failure 데이터셋은 미리 잘려 있습니다. 자기가 기록한 고장에서 끝나므로 잔여수명이 파일 안 위치에서 부분적으로 유추됩니다. 모델은 베어링이 열화한다가 아니라 녹음이 끝나간다를 배울 수 있고, 여전히 돌고 있는 기계를 만나기 직전까지 훌륭한 점수를 냅니다.

동작 방식

이름 하나를 쓴 문제 셋

전체의 값어치는 리드타임 빼기 행동 소요시간의 함수이고, 모든 정확도 지표가 훌륭해 보이는 동안 그 차이가 음수일 수 있습니다. 완벽하지만 늦은 탐지기의 값은 0이고, 이건 애초에 모델에 대한 진술이 아닙니다.

비용비가 곧 임계값이다

k = 고장을 놓친 비용 ÷ 오경보 비용 이라 두면, 동기 슬라이드는 k 가 10에서 100 사이라고 주장하고 있습니다. 결과 셋이 바로 따라옵니다:

• F1 은 k = 1 을 가정합니다. 정밀도와 재현율에 같은 가중치를 준다는 것은 불필요한 점검 한 번이 기계 한 대 파손과 정확히 같은 값이라는 주장입니다. 아무도 그렇게 믿지 않는데 모델은 끊임없이 그 위에서 튜닝됩니다.
• k = 10 이면 잡아내는 한 건당 오경보 열 건까지 받아들여야 합니다. 현장 감각에는 틀리게 느껴지고 산수로는 맞으며, 정확히 그 대화를 가능하게 하려고 이 숫자가 존재합니다.
• 임계값이 데이터보다 먼저입니다. the-70-has-to-be-wrong 이 확률 출력에 대해 하는 말과 같습니다 — 임계값은 비용에 대한 진술이지 모델의 속성이 아니다 — 그리고 여기서는 그 비용이 1페이지에 적혀 있었습니다.

산수에 대한 정직한 보정 하나. 경보 피로(alarm fatigue)는 오경보 비용에 안 잡히는 진짜 비용입니다. 스무 번째 오경보 뒤에 현장이 확인을 그만두면 놓친 고장이 드문 일이 아니라 확정 사건이 되므로 실효 k 가 1 쪽으로 붕괴합니다. 그래서 "건당 오경보 열 건"은 경제성이 정한 상한이지 목표가 아니며, 실제로 묶이는 제약은 대개 점검 비용이 아니라 신뢰 예산입니다.

왜 첫 모델이 지도학습이면 안 되는가

가장 싼 첫 산출물은 모델이 아닙니다. 현장이 이미 알아챈 이상들을 가져와 정비 기록에서 원인을 라벨링하십시오. 대부분이 품종 교체와 센서 고장이면, 정직한 결론은 이 프로젝트의 첫 결과물이 품종 교체 감지기라는 것이고, 그걸 알아내는 데 분기가 아니라 하루가 듭니다.

만들 것: 모델이 아니라 비용 곡선

1. 수리 소요시간 — 데이터가 아니라 정비팀에서. H 를 정함.
2. 비용비 — 동기 슬라이드에서. 임계값을 정함.
3. 아무 점수기나 — 센서 하나의 이동평균 잔차면 곡선은 그려집니다. indicators-add-a-decision 이 그대로 적용됩니다 — 변환은 정보를 더하지 않고 결정을 더하며, 값어치는 그 결정에 있습니다.
4. 임계값을 훑어 기계·월당 기대비용을 그리고, 임계값·리드타임·그 지점의 오경보율을 보고합니다.

사람들이 틀리는 부분은 기준선입니다. "아무것도 안 하기"가 아닙니다. 거의 모든 공장이 이미 주기적 정비를 돌리고 있고, 그건 알려진 비용으로 일부 고장을 막고 있습니다. 아무것도 안 하기는 이기고 6개월마다 교체하기에는 지는 모델은, 양성처럼 보이는 음성 결과이며, 그것을 보여주는 것은 비용 곡선뿐입니다.

Jayverse에서의 위치

• Devnet: 알림 임계값은 수리 시간으로 정하지, 모델 정확도로 정하지 않는다. Devnet/Anvil 노드 상태나 RPC 장애 모니터는 실제 재시작·재배포 시간을 먼저 기록한다. 이 숫자가 알림이 무의미해지는 기준선이고, 모델이 아니라 운영에서 나온다.
• gitboard: 대시보드는 빨강/초록이 아니라 임계값, 리드타임, 오탐률을 보고한다. 대시보드의 이상 지표는 어떤 비용비로 튜닝됐는지와 함께 나와야, 무시할 때의 비용과 쫓을 때의 비용을 볼 수 있다.
• Auditor: 알림을 튜닝하기 전에 비용비 k를 적어둔다. 청산, 슬래싱, 오라클 분쟁 모니터라면 놓친 사건의 비용과 오탐 비용을 먼저 명시하고, 아무것도 안 하는 것이 아니라 이미 있는 일정 기반 점검과 비교한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑