[07:29:27] <pfischer>	 o/
[07:38:27] <dcausse>	 o/
[08:32:51] <dcausse>	 pfischer: when you have a moment could you take a look at https://gitlab.wikimedia.org/repos/search-platform/cirrus-streaming-updater/-/merge_requests/197?
[08:34:50] <pfischer>	 sure
[08:35:55] <pfischer>	 dcausse: done!
[08:38:57] <dcausse>	 thanks!
[10:39:42] <dcausse>	 lunch
[13:18:17] <inflatador>	 <o/
[13:41:24] <dcausse>	 o/
[14:29:19] <ebernhardson1>	 \o
[14:37:04] <ebernhardson>	 i forget, how big of runs did we typically do with relforge, like 10k queries?
[14:38:33] <ebernhardson>	 I guess i was pondering if its worthwhile to loop through the cirrus AST api to be sure we have queries of class "simple_bag_of_words"
[14:38:53] <dcausse>	 o/
[14:39:13] <ebernhardson>	 also, separately, the cirrusDumpQueryAST endpoint is returning an ast for the main wiki, and then responses from all the secondary searches (wiktionary, etc)
[14:39:25] <ebernhardson>	 not a big deal, but probably not intended :)
[14:39:43] <dcausse>	 indeed not really necessary :)
[14:39:57] <dcausse>	 the simple_bag_of_words tag should be in cirrus backend logs already
[14:41:33] <dcausse>	 but for historical data yes... might be tricky to get, cirrus backend logs might not have the same retention as query_clicks 
[14:42:11] <ebernhardson>	 dcausse: i guess i was expecting various inputs, i think in the past we sourced from various places depending on use case (webreq, mjolnir clicks, search sat).  But could limit to CSRQ 
[14:43:15] <dcausse>	 sure, calling cirrus is probably OK but we'll need to stop early before hitting sister wikis :)
[14:44:05] <ebernhardson>	 yea probably worth fixing
[14:44:56] <ryankemper>	 volans: what's the best way to test https://gerrit.wikimedia.org/r/c/operations/software/spicerack/+/1167299? it'd be nice to be able to run it before merging ideally
[14:45:10] <dcausse>	 or simple heuristics if we don't care too much about dropping good queries (no : " && || AND OR NOT, ~)
[14:45:28] <ebernhardson>	 yea maybe thats good enough
[14:45:39] <ebernhardson>	 some regex that rejects queries
[14:47:50] <dcausse>	 yesterday I noticed a bit of randomness in ltr results and was wondering how much of this is caused by the use raw freq features
[14:48:40] <volans>	 ryankemper: I'll defer to elukey as I'm currently in another team (I'm not sure how widespread the communication was). But keep in mind that currently spicerack on the bookworm cumin hosts has no elasticsearch support at all, so it can't break anything. That said there are potential ways to test it via spicerack-shell and some manual step.
[14:50:05] <ebernhardson>	 hmm, i suppose the freq feature do vary by shard, but i suppose i expected them to be close enough
[14:52:06] <dcausse>	 if you refresh you sometimes see some results flipping around, generally not huge movements more like move up or down by 1 pos
[14:53:40] <ebernhardson>	 yea thats probably unsolvable, too many things vary it must be right near a cutoff point
[14:53:51] <ryankemper>	 volans: thanks will follow up with him!
[15:05:39] <dcausse>	 can't remember if mjolnir is pushing a new featureset to the ltr index on every runs (after feature selection) or somehow is able to extract features without storing a predefined featureset
[15:13:04] <ebernhardson>	 it fetches the featureset from opensearch prior to uploading the model, then uploads a minimized feature set with the model. The features basically get stored inside the model on the plugin side
[15:13:29] <ebernhardson>	 in part needed because feature selection is run for every model, so it's always different
[15:13:38] <ebernhardson>	 (although it would be curious to run some analysis over chosen features some day)
[15:25:13] <dcausse>	 ok, so the process to push a new feature set is always "manual"
[16:06:41] <inflatador>	 break, back in ~15-20
[16:25:16] <inflatador>	 back
[17:49:39] <inflatador>	 lunch, back in ~40
[18:06:05] * ebernhardson realizes there are old notebooks in the relforge repo
[18:08:51] <ebernhardson>	 and i somehow have 15G of wikidata completion clicks data from 2022 in the my local relforge dir
[19:01:29] <gehel>	 ebernhardson: 1:1 in https://meet.google.com/stp-swkd-iho ?
[19:01:44] <ebernhardson>	 gehel: oh, sec
[19:01:52] <gehel>	 :)
[19:02:04] <gehel>	 you're not late yet!
[20:48:35] <ebernhardson>	 huh, never seen that: "parse_exception: Cannot parse 'newcastle united 2002/03': Lexical error at line 1, column 25.  Encountered: <EOF> after : "/03"
[21:42:43] <ebernhardson>	 relforge reports now generating again, although currently only from a notebook.  Will have to ponder how best to run this
[21:43:08] <ebernhardson>	 also i only wrote the bit that sources queries from mjolnir clicks, but the others shouldn't be that hard. Just need a dataframe with query strings for a single wiki
[21:44:07] <ebernhardson>	 as for if the relaxed query is better at some things...i dunno :P like `list of nail polish brands` gives `Nail (anatomy)`, a famous manicurist, and a multi-national beauty company as top 3.  relaxed gave `Nail polish`, `Nail art` and `Nail salon`.  Both sucked :P
[21:45:04] <ebernhardson>	 but it absolutely does something: Top 3 Sorted Results Differ: 79.0%