[09:56:52] <dcausse>	 distillroberta has a limit at 128 word pieces, the 100 lexical tokens window is I think too big
[11:07:10] <pfischer>	 dcausse: https://phabricator.wikimedia.org/P86397
[11:11:46] <pfischer>	 That gives us paragraph level and info boxes, all nicely labeled
[11:15:19] <dcausse>	 pfischer: thanks! very nice indeed
[11:37:15] <pfischer>	 dcausse: Would you join the ML<>Research<>DPE meeting this afternoon? I have a conflict and can’t make it, but I think someone from Search should be around, there might be questions from Sucheta regarding the Semantic Search prototype.
[11:37:56] <dcausse>	 pfischer: sure, I planned to attend anyways
[11:38:09] <pfischer>	 dcausse: Great, thank you!
[14:51:51] <Trey314159>	 Staff meeting or retro in about an hour?
[14:52:25] <dcausse>	 no strong preference either ways
[14:56:32] <ebernhardson>	 \o
[14:56:42] <ebernhardson>	 dcausse: ouch, didn't realize it was word pieces, was thinking whole words :(
[14:56:53] <dcausse>	 o/
[14:57:19] <ebernhardson>	 i had heard modern tokenization for ml does pieces, but hadn't thought about it
[14:57:50] <dcausse>	 other models I saw claim a limit at 512 but often say "mainly trained with 256 word pieces"
[14:58:21] <dcausse>	 and opensearch won't try any magic to aggregate and average multiple vector if you're past the model limit
[15:01:31] <ebernhardson>	 :( yea kinda expected though
[15:02:07] <ebernhardson>	 looks like ozge is suggesting multilingual-e5-large-instruct, not 100% sure but the default max length is 512 tokens
[15:02:17] <ebernhardson>	 probably same idea
[15:03:27] <dcausse>	 yes, this one is quite large compared to others and will have to packaged to be opensearch compatible, but perhaps it's not too hard and just a matter of writing the proper model config
[15:04:24] <ebernhardson>	 should be interesting, sadly i don't expect i'll find the time to look into that
[15:04:35] <dcausse>	 he also suggested to do the intersection between simple & enwiki to speed things
[15:04:48] <ebernhardson>	 intersection, like both in same index?
[15:04:48] <dcausse>	 quickly filtered cirrus enwiki dumps and it's 10times smaller
[15:05:16] <dcausse>	 no take the content from enwiki but only for articles present in simplewiki
[15:05:22] <ebernhardson>	 ahh, ok
[15:06:23] <pfischer>	 Trey314159: I asked Andreas to facilitate our retro to today and he accepted, so I would be in favour of our retro :-)
[15:06:25] <dcausse>	 also very tempted to use enterprise dumps as quick way to have section/paragraph boundaries
[15:06:41] <Trey314159>	 pfischer: cool
[15:06:46] <ebernhardson>	 if we have access to the data files, seems fine for moving forward with testing
[15:07:05] <ebernhardson>	 i guess i'm not clear on if that would work in later prod deployments or not
[15:07:13] <ebernhardson>	 (suspect not, but who nkows)
[15:08:09] <dcausse>	 using enterprise dumps is just an quick way to experiment with what could possibly be obtained if we had proper section boundaries in cirrus dumps
[15:12:19] <ebernhardson>	 i also wonder what they do with edge cases...found silly things like how you can put section markers in the middle of a table
[15:15:53] <dcausse>	 yes... it's still marked as beta and only works for content namespace as far as I can see, so most probably highly tuned towards the wikipedia way
[15:16:28] <dcausse>	 should be opensource tho so perhaps we can steal some ideas but suspecting that it might not generalize well
[15:17:57] <ebernhardson>	 i'm not doing anything fancy now, i guess i'm just wondering how specific i have to be.  I mean in theory i can just walk siblings and parents and serialize everything between two elements tree-wise, but i was hoping to just find a common ancestor
[15:18:21] <ebernhardson>	 i suppose i'm also assuming (without being sure) that calling getOuterHTML on dozens/hundreds of elements will be much slower
[15:18:41] <dcausse>	 :/
[15:19:16] <ebernhardson>	 (curiously it has to get getOuterHTML, or we would have to check tags, because things like <style> tags)
[15:20:00] <ebernhardson>	 dcausse: oh that reminds me...i didn't find a nice way to keep headers in the sections but not the text.  I could of course make it work...but pondering maybe stop removing the headers from main text?  
[15:20:45] <ebernhardson>	 the thing is we strip those early in the $doc, having sections with headers and text without headers probably means parsing and processing the $doc twice
[15:23:46] <dcausse>	 oh you mean because the current text field does not have section titles it's hard to adapt to retain the section titles with re-parsing?
[15:24:05] <dcausse>	 if yes I don't have objections to put the section titles back in the current text field
[15:24:29] <dcausse>	 *without reparsing
[15:25:14] <dcausse>	 or I misunderstood what you said probably?
[15:25:14] <ebernhardson>	 it's certainly possible, but would be a bit awkward.  It would mean stripping the headers as a specific step between extracting sections and extracting the full text, instead of as part of the generic document preparation. Seemed odd
[15:25:44] <dcausse>	 sure
[15:26:19] <dcausse>	 I'm not too worried about keeping the text field exactly as it is tbh, imo it's not that great currently
[15:26:21] <ebernhardson>	 and i guess the re-parse would just be because right now i'm not parsing out the sections during the normal processing (so it doesn't happen during cirrus update requests)
[15:26:30] <ebernhardson>	 but i keep the $doc around, so right now i always have the post-text $doc
[15:27:11] <ebernhardson>	 makes sense
[15:28:09] <dcausse>	 for instance if there were an easy way to detect the Reference section I'd be to move it to auxiliary_text
[15:29:09] <dcausse>	 it's very noisy packed with named entities and hardly readable
[15:29:44] <ebernhardson>	 hmm, yea that would make sense
[15:29:55] <ebernhardson>	 i've seen highlights in references before, and rarely is it a good result
[15:30:05] <dcausse>	 yes...
[15:33:15] <ebernhardson>	 hmm, at least on enwiki references are wrapped in <div class="reflist">, or also a nested <ol class="references">.  Should maybe check with parsing how consistent those are
[15:34:07] <dcausse>	 sure
[15:35:56] <pfischer>	 ebernhardson: dcausse: I may have missed it, but do you have full access to the enterprise dumps? Other teams already asked for access, bypassing the paywall. According to T403298, its possible to get unrestricted access through some proxies. Does that work for us?
[15:35:57] <stashbot>	 T403298: Provide auth-less access to Enterprise APIs from WMF Analytics cluster - https://phabricator.wikimedia.org/T403298
[15:37:17] <dcausse>	 pfischer: somehow my browser had remembered a valid account names search-team, was about to test if it's enough to download the structured data dumps
[15:37:26] <dcausse>	 s/names/named
[15:37:48] <dcausse>	 probably guillaume had requested such access already
[15:53:28] <ebernhardson>	 huh, i guess i should have realized, but there is a very specific method for copying text from DOM. The Document Object Model (DOM) Level 2 Traversal and Range Specification at https://www.w3.org/TR/DOM-Level-2-Traversal-Range/
[15:54:06] <ebernhardson>	 and php's DOMDocument doesn't seem to have the range impl :( 
[15:58:34] <gehel>	 pfischer: I'll be 2' late to the retro. I need a quick break between meetings
[16:01:52] <pfischer>	 ebernhardson: are you around for our retro?
[17:01:54] <dcausse>	 Trey314159:
[17:01:56] <dcausse>	 https://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%96%D7%A0%D7%95%D7%9F#%D7%94%D7%93%D7%A3_%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%97%D7%93%D7%A9%D7%95%D7%AA_%D7%9E%D7%A6%D7%99%D7%92:_%D7%A4%D7%A2%D7%9D_%D7%A9%D7%9C%D7%99%D7%A9%D7%99%D7%AA_%D7%92%D7%9C%D7%99%D7%93%D7%94,_%D7%90%D7%95_%D7%91%D7%97%D7%96%D7%A8%D7%94_%D7%9C%D7%97%D7%99%D7%A4
[17:01:58] <dcausse>	 %D7%95%D7%A9_%D7%95%D7%99%D7%A7%D7%99
[17:02:00] <dcausse>	 damn too long
[17:02:12] <Trey314159>	 I can make it work.. thanks!
[17:02:22] <dcausse>	 https://w.wiki/GVg6 :P
[17:02:47] <dcausse>	 dinner
[17:03:48] <pfischer>	 dinner
[17:31:21] * ebernhardson kinda wished the browser auto-translate would also left justify.  It's surprisingly hard to read right-justified talk pages :P
[17:31:47] <ebernhardson>	 i guess thats probably all css and other bits though
[18:05:31] <pfischer>	 ebernhardson: are you around for our 1:1?
[18:28:33] <ebernhardson>	 pfischer: doh! sorry yes
[18:28:40] <ebernhardson>	 pfischer: still have time?
[18:30:19] <pfischer>	 ebernhardson: sorry I have to put my daughter to sleep now, I’ll ping you if I can find a slot later tonight.
[18:30:39] <ebernhardson>	 pfischer: kk, my appologies
[18:30:51] <pfischer>	 ebernhardson: no worries
[19:15:01] <ebernhardson>	 hmm, `ps auxf | grep -c php` returns 92 after running `composer fix` in mediawiki core.  I suspect it's not supposde to make so many processes
[22:03:31] <ryankemper>	 inflatador: back in 2’ and then we can start those stat reboot:
[22:03:35] <ryankemper>	 reboots*
[22:05:41] <inflatador>	 ryankemper ACK