darkhanakh

so the 100% LongMemEval score is a bit misleading if you actually look at whats going on. they took the 3 questions that were failing and applied targeted fixes for those specifically, plus LLM reranking on top. if you hold out those fixes the actual score is 98.4%. still good but not "100%" good yknow

same story with LoCoMo, the 100% score uses top-k=50 which literally exceeds the session count lol, with reranking on top. honest top-10 no rerank gets you 88.9%

this is giving openclaw energy where you engineer your benchmark results to look perfect and then market it as some breakthrough. the underlying tech might be interesting but leading with "highest score ever published" when the methodology has these kinds of asterisks is not great

cool that milla jovovich is vibe coding tho i guess

hey, so postgres has zero support for kazakh full-text search. no dictionary, no stemmer, nothing. if you try searching kazakh text today you basically get trigram matching which is useless for this language

kazakh is agglutinative — one word can have like 5-6 suffixes stacked on it so the surface form between query and document almost never matches. i tested on 3000 real news articles and trigram gives you 1 result where pg_kazsearch gives 61 for the same query. overall recall improvement is around 23%

the core stemmer is written in rust, and it plugs into standard postgres FTS stuff — gin indexes, ts_rank, phrase search etc. you can install via deb package or docker, no need to compile anything

as far as i know this is the first FTS implementation for kazakh in any major database. the stemming approach should be pretty transferable to other turkic languages (uyghur, uzbek, kyrgyz) since they have similar morphology

this is kind of a hobby project so theres probably rough edges i havent caught yet. would really appreciate feedback especially from anyone whos worked on postgres extensions or text search for non-english languages. also open to ideas on what to improve next

fair points. i was probably overstating the subsidy argument as if its some trap that snaps shut. compute costs do trend down and if moores law dynamics still roughly apply to accelerators then even a 10x gap closes in a few years. the analog/ASIC weight-baking point is interesting too, hadnt considered that as a near term efficiency path but makes sense given how low the precision floor is

where id still push back is that "inference becomes cheap" and "ai replaces good engineers" are two different claims. inference getting cheap means the floor tier of ai-assisted work becomes very accessible. but the gap between what claude can do as a fresh graduate (generous but i see what you mean) and what a senior with deep system context can do isnt a cost problem its a capability problem. 100x cheaper inference doesnt close that gap, it just means more cheap output faster

on interest rates yeah thats basically my argument stated more precisely. rates went up, cheap capital disappeared, companies that hired assuming perpetual growth had to correct. "ai efficiency" just plays better on an earnings call than "we overexpanded during ZIRP"

your last point about individuals vs big teams is actually a stronger version of the articles argument than the article itself makes. if most valuable work is done by individuals or small groups then the real loss from layoffs isnt headcount, its losing the specific 5-10 people who actually understood the system. the bloat was arguably already dead weight. but the cut doesnt discriminate, it takes both

the part thats missing from this whole discussion is that the cost of running frontier models is heavily subsidized right now. companies are making "ai efficiency" decisions based on pricing that doesnt reflect actual compute costs. when inference and r&d prices normalize (and they will) the roi math that justified cutting your engineering team just stops working. but the people are already gone

also the nber finding is wild - 80% of firms report zero productivity impact from ai. zero. but layoffs attributed to ai are 12x what they were two years ago. its not ai displacement, its a market correction using ai as cause. the resume.org survey where 60% of hiring managers admitted they played up the ai angle because it sounds better than "we need to cut costs" pretty much says it out loud

the other thing nobody talks about is what happens to the junior-to-senior pipeline and tacit knowledge transfer. its not just that fewer juniors get hired. the ones who do get hired learn in an environment where the hard cognitive work is outsourced to a model. they never build the mental models you need to actually understand systems deeply. shen & tamkin literally measured this - ai assistance impairs conceptual understanding. so you end up with a generation that can prompt but cant debug from first principles and the seniors who couldve mentored them are already out the door

the article is right that reversals wont happen. id just add that even if they tried, the knowledge of what "bringing people back" means will have left with the people they cut

eh i'd push back on "just RAG". like yes the retrieval-generation loop is RAG shaped, no ones arguing that. but the interesting bit here is the write loop - the LLM is authoring and maintaining the wiki itself, building backlinks, filing its own outputs back in. thats not retrieval thats knowledge synthesis. in vanilla RAG your corpus is static, here it isnt

also the linting pass is doing something genuinely different - auditing inconsistencies, imputing missing data, suggesting connections. thats closer to assistant maintaining a zettelkasten than a search engine returning top-k chunks

cool project btw will check it out