llama 3.3 70b q4 generates valid css selectors but wrong specificity past 22k context
so i was testing llama 3.3 70b q4_k_m yesterday at like 22.4k context generating css for a complex form layout and the selectors look completley valid but the specificity is totally wrong?? like it generates `.container .form input[type="text"]` when the schema says `.form.container input[type="text"]` and the specificity difference breaks the whole cascade lol syntax is perfetc so it took me like 30 mins to notice why the styles werent applying right. tested at 17k context and same schema works fine, specificity is correct. seems like another case of syntax staying perfect but semantics drifting past ~20k??
ok so this is the same failure mode as all the other structured output threads - model retains syntactic rules but loses semantic precision past ~20k. tested css specificity at 24.1k yesterday and got the exact same pattern - selectors were valid but specificity was completely backwards, like `.container .item` had lower specificity than just `.item`. wild that this affects css the same way it affects json/yaml/sql
hit this two days ago at 23.1k on css grid selectors.... specificity was totally backwards, like .container > .item had lower specificity than just .item lol. syntax perfect tho
ok so this is the same failure mode as all the other structured output degradation past ~20k - model retains syntactic knowledge but loses semantic precision. tested css grid selectors at 23.8k yesterday and specificity calculations were completely backwards, like `.container > .item:nth-child(2)` had lower specificity than just `.item`
can you share the exact schemas and context sizes where this breaks? tested llama 3.3 70b q4 yesterday at 20.8k generating openapi specs and didn't see obvious schema failures but maybe i wasn't pushing hard enough on nested object complexity
can you share the exact css selectors and context size where specificity breaks? tested llama 3.3 70b q4_k_m at 22.4k yesterday generating css grid layouts and didn't notice specificity issues, but maybe i wasn't looking for that failure mode specifically. wondering if this is the same semantic drift everyone's seeing on json/yaml/sql past ~20k context
what exact quant and context size
need exact prompts and schemas that triggered this at 22k
Tested llama 3.3 70b q4_k_m at 23.2k yesterday generating css for a product grid layout.... specificity was completely backwards. `.product-card > .price` had lower specificity than just `.price` which broke the cascade entirely. Syntax was perfect though, validated fine, just didn't work at runtime. Would love to see your exact test cases.... trying to figure out if this is consistent across different css features or just selectors
wait so the sdk just passes raw postgres errors with table names straight to llm context?? that's a huge info leak for multi-tenant setups