Почему цена Bitcoin «сломалась»: разбор аномалий 2022–2026 с WhyTrend

[Kriketo]

А почему не проще было просто поднять timeout для 32B секунд до 400-500, раз модель явно не укладывается в 180? Может там дело вообще не в размере модели, а просто в жёстком лимите?

[AlexProvatorov]

Спасибо за вопрос.

По коду Pipeline на том прогоне восемь explain шли через asyncio.gather, то есть стартовали вместе. Wall-clock — а время до завершения самого позднего запроса.

Ollama на одной GPU при этом обычно почти сериализует генерацию. Запрос в очереди для httpx — всё ещё ожидание ответа, поэтому хвост очереди на 32B чаще упирается в 180 с и уходит в fallback. Поднять timeout до 400–500 с имело бы смысл, если цель — дождаться именно 32B-ответов: больше шансов, что хвост очереди успеет посчитаться. Цена — дольше ждать весь gather (ближе к сумме инференсов в очереди). Для статьи важнее было уложиться в разумное время и получить воспроизводимый прогон, а не выжать максимум из 32B.

14B тут не костыль вокруг лимита, а практичный выбор: на той же GPU она быстрее → короче очередь → реже timeout при 180 с → меньше fallback. Для этого шага пайплайна топовая модель и не обязательна: на вход уже есть детекция, окно и отранжированные evidence, на выход нужен структурированный JSON-черновик гипотез. Сильнее модель имеет смысл позже, точечно, когда правишь формулировки или разбираешь спорные даты.

Надеюсь ответил на вопрос.

[CrissSquirrel]

Слушай, а как отличить настоящий вывод модели от fallback, не листая JSON и не сверяя confidence вручную? Может стоит просто помечать fallback прямо в отчёте отдельным полем?

[AlexProvatorov]

Спасибо за вопрос.

Да, сейчас единственный способ отличить их снаружи это confidence=1.00 + один cause + шаблонная фраза "may be related to X", но это эвристика читателя, а не явный флаг от системы. Как раз в roadmap стоит post-ranker фильтр с разметкой "correlation_only / likely_cause" — по сути это и есть явный флаг вместо угадывания по паттерну. Пока не сделал, потому что хотелось сначала понять частоту и природу самого fallback на реальных данных — эта статья и была таким замером.

[CrissSquirrel]

Спасибо за ответ

[AlexProvatorov]

Всем привет! Решил сразу подсветить пару моментов в комментариях, чтобы направить обсуждение в продуктивное русло:

1. Почему именно Bitcoin? Данные по BTC взяты исключительно как живой, агрессивный и максимально волатильный датасет. На нём очень удобно гонять детекторы аномалий (Ruptures) — тут вам и крах FTX, и Terra/Luna, и банковские кризисы. Задача была проверить фреймворк на "грязных" реальных данных за 4.5 года, а не спекулировать на цене.

2. Проблема с котами и уверенностью 1.0 (Fallback): Да, подстановка первого документа по BM25 при ReadTimeout от Ollama с выдачей confidence=1.00 — это явный архитектурный костыль текущей версии, который будет поправлен в будущем релизе. Я специально не стал вырезать этот failure mode из отчётов, чтобы честно показать, как это работает на текущий момент с локальной моделью.

Буду рад обсудить, как вы боретесь с латентностью локальных LLM в длинных пайплайнах и какие эвристики используете для отсечения текстового шума до отправки контекста в модель.