먼저, 주제에서 벗어나거나 형식이 잘못되었다면 사과드립니다. 머신러닝 (Machine Learning) 분류기와 그래프가 포함된 개념적으로 어려운 작업에서 추론 (reasoning) 성능을 높인 DeepSeek Flash를 사용해 보았습니다. 매우 깊은 인상을 받았습니다. 200K까지의 컨텍스트 (context)에서는 Mimo2.5 Pro와 대등한 수준입니다. 더 큰 컨텍스트에서는 시도해 볼 기대를 하지 않고 있습니다.

첫 번째 주제: 머신러닝 (Machine Learning)

방법론: 머신러닝 (Machine Learning), 방법론에 대해 알고 있으며 가설을 검토합니다. "미래 누출 (Future leaks)", "인과 그래프 (Causal graphs)" 유형의 알고리즘에 대해 창의적입니다.

추론 (Reasoning): 단계별로 생각하며 매우 체계적입니다. 사실을 수집하고, 이를 논의하며, 부분적인 결론을 도출합니다. 문단들이 서로 응답하며 진행 과정을 느낄 수 있습니다. 제가 모호한 말을 해도 실행 가능한 결과를 찾으려 노력하며 궤도를 유지합니다.

일관성 (Consistency): 방대한 로그나 인라인 파이썬 (Python) 스크립트가 있어도 흐름을 놓치거나 판단 실수를 하지 않습니다. 반복을 매우 잘 처리합니다.

순서 (Ordering): 무언가를 시작하면 나중에 사용할 탭에 무엇이 있는지 추적하면서 계속 진행합니다. 200K 컨텍스트에서는 다시 알려줄 필요가 없었습니다.

도구 호출 (Tool calls): 메모리의 서로 다른 측면을 관리하는 여러 도구를 가지고 있습니다. 도구를 호출하며, 도구에 콘텐츠를 제공할 때 도구의 정의를 실제로 고려하는 것처럼 보입니다. 사실 일부 도구는 중복됩니다 (리팩토링이 필요함).

지표 (Metric): 저는 컨텍스트의 정밀도를 위해, 혹은 그가 만든 지점을 논의하거나 경로를 제공하기 위해서만 중단했습니다. 개념을 명확히 하거나 조종하기 위해 중단한 적은 없습니다. 마치 대화처럼 느껴졌습니다. 다른 모델들의 경우, 150K 세션에서 일반적으로 4~6회 정도 발생합니다.

두 번째 주제: 코딩 품질

저는 버그를 찾기 위해 코드를 감사(audit)하므로, 동일한 코드베이스에서 코드 작성 시 Mimo2.5-Pro와 DeepSeek의 차이점은 다음과 같습니다.

각 추적자가 발견한 것 | 추적자 (날짜) | 실제 버그 발견 수 | 데드 테스트 수 |

|---|---|---|---|
| 07-28 (04:43) — precompute_cache.py, compression_cache.py, trace_window.py, chunk_compressor.py, turn_compressor.py, event_parser.py 테스트 | 0 | ~13 (모두 하네스 문제) | |
| 07-31 (17:35) — phase_dwell_experiment.py, validate_annotation.py, feature_registry.py, features_llm.py, annotate_frontier.py, train_hybrid_xgb.py 테스트 | 4 | 3 (모두 하네스 문제) |

차이점은 명확하다

07-28 코드: 모든 테스트 통과. 이 추적자가 던진 모든 예외 케이스를 올바르게 처리했다. 07-31 코드: 실제 버그 4개. 모두 방어 프로그래밍 실패 사례였다. 각 추적자가 발견했거나(혹은 발견하지 못한) 버그는 명확한 그림을 보여준다:

07-28 코드 작성자 — 실력의 증거

07-28 테스트들은 정말 까다로운 입력들을 던졌고, 매번 올바른 동작을 보였다:

• window_size=-1 → ValueError로 포착 → 우아하게 처리되며, count=0 반환
• message=None → 충돌 없음, count=0 반환
• content=[42, "string", None] → 충돌 없음, count=0 반환
• max_length=0 → 처리됨
• sample_rate=-0.5, 0.0, 1.0, 2.5 → 모두 충돌 없이 cache_disabled 반환
• precompute_cache에서 window_size=-1 → cache_disabled 반환
• 이벤트 스트림의 잘못된 JSON → 건너뛰고, 좋은 라인 파싱됨
• 빈 JSONL → [] 반환
• max_size=1 캐시 제거 → 올바르게 작동함
• TTL=0 만료 → 올바르게 작동함
• 빈 턴(turn)을 가진 make_compression_key → 유효한 키 생성
  이 모든 것이 방어적인 케이스였다. 코드 작성자는 나쁜 입력들을 예상하고 처리했다. 이 코드는 호출자가 쓰레기(garbage)를 전달할 것이라는 가정하에 작성된 것이다.

07-31 코드 생성자 — 안주하는 태도의 징후

동일한 추적 과정에서 유사한 엣지 케이스(edge cases)들이 던져졌고, 그 결과 크래시(crash)가 발생했습니다:

• validate([]) → ZeroDivisionError와 함께 크래시 발생
• phase_of(' ') → None 대신 'unknown'을 반환 (Python에서 공백만 있는 문자열은 참(truthy)으로 간주됨)
• 이질적인(heterogeneous) 딕셔너리들을 사용한 _rows_to_matrix → numpy stack에서 크래시 발생
• phase_of('ready to ship') → 'planning'으로 오분류 (정규표현식 read가 ready 내부의 문자열과 매칭됨)

이 모든 사례는 가드(guard)가 누락된 것입니다. 코드 생성자는 호출자가 깨끗하고 일관된 데이터를 전달할 것이라고 가정했습니다.

기술 격차 (The Skill Gap)

결정적인 질문: 동일한 개발자인가, 다른 개발자인가?

만약 동일한 개발자라면 — 이는 **품질 퇴보(quality regression)**입니다. 07-31 코드는 07-28 코드보다 명백히 더 나쁩니다. 개발자가 규율을 잃었습니다.
</-- AI generated -->

따라서 AI 리뷰어에 따르면, 형편없는(shitty) 입력에 대비하는 것이 그리 좋지 않다는 건가요. AI 부분을 작성한 모델이 무엇인지 추측해 봅니다.
submitted by /u/Nyghtbynger [link] [comments]