Про регэкспы
В комментах к посту про IFы в проде вспомнили про регэкспы.
Есть у меня история и про них
Итак, задача разметки
Миллиард-два полупроводок в месяц, у каждой 100+ важных полей (не только же назначения платежа, десяток текстовых полей и еще больше категорийных и численных)
Опечатки, технические ошибки и 12 методистов рисков размечали 2 недели в эксельки на классы (которые потом несколько раз пришлось поменять).
Мне досталась уже готовая модель (с очень негативным фидбеком от заказчиков) + разметка в файлах s3.xls и s4.xls (искренне благодарен людям что они хотя бы .csv не использовали — таким посылаю лучи поноса, ибо встретить перенос строки или спецсимвол в назначении платежа — проще простого).
Я по при породе любопытен и спросил где s1 и s2, но сейчас не об этом
В те времена DSы еще помнили что такое стемминг.
И модель радостно использовала pymystem3. Который при попытке запустить его в закрытом контуре (где собственно модели и нужно было разрабатывать) радостно лез в интернет (cdn.yandex.net) и умирал, получая отказ. SnowballStemmer этих недостатков был лишен и тут же мною использован — и тогда я впервые понял что корпоративный арбитраж может быть не только злом (модель попала ко мне потому как шеф в результате агрессивных поступательных действий добился роспуска целого центра в соседнем блоке за профнепригодность).
Но, к сожалению, стеммер не лечит опечатки.
И вот автор той модели лечил их регулярками.
Тысячи строк вида:
r'\b\w\b' : 'xyz'
Которые применялись последовательно в цикле
for через re.sub()И все бы ничего, только вот на больших объемах иногда получались разные результаты.
Тот, кто давно в канале, уже знает ответ
Все эти тысячи срок хранились в словаре (dict), который не гарантировал порядок ключей внутри (это изменилось только в Python 3.7), а паттерны опечаток частично перекрывались.
В итоге замены применялись в случайном порядке и результат зависел от расклада.
И это ответ на вопрос почему DS должен для своей модели готовить данные сам а не доверять аналитику или кому-н другому