🤝 Open to Collab

Dipankar Sarkar PRO

dipankarsarkar

7 2270 451

https://www.dipankar.cc

AI & ML interests

Building the AI-native stack. Agents as infrastructure, safety as architecture, performance as plumbing. I publish the receipts: papers, datasets, demos.

Recent Activity

upvoted a paper less than a minute ago

EvoTeam: Multi-Agent Collaboration via Evolving Teams

repliedto tardellirs's post about 1 hour ago

Model cards say what a model is: a fine-tune of X, a quantization of Y. I built Weightprint to check that against the weights. App: https://huggingface.co/spaces/tardellirs/weightprint Data (every pair, and the copy groups): https://huggingface.co/datasets/tardellirs/weightprint It reads the header and a few bytes of every tensor (no downloads) and compares a model with the parent its card declares. 120,976 models so far. Some of what came out: - 7% of the declared fine-tunes we could compare (1,630 of 22,847) hold their parent's weights unchanged. (Corrected from 12%: quants whose values the engine doesn't decode, like bitsandbytes and FP8, had been counted as unchanged. Thanks @dipankarsarkar for the question that caught it.) - 27% of the fine-tunes we could compare are LoRA-style: only the attention and MLP matrices moved, norms and embeddings untouched. That share went from 10% in 2023 to 28% in 2026. - Of 1,668 fine-tunes named abliterated, uncensored or heretic, 53% edit only the matrices that write to the residual stream, the signature of an abliteration. The rest were trained further, merged, or are the parent's weights. - 51% of the weight bytes on the Hub are byte-for-byte repeats of another repo's files. Search any Hub id to see which layers and parts changed against its parent, or compare any two models. A sample per tensor can miss things, and some formats can't be compared yet. If a verdict on a model you know looks wrong, tell me here and I'll check it against the engine. That's what this post is for, before a longer write-up.

repliedto vladimirbesk's post about 1 hour ago

Ru-Jev v1.3: label augmentation helps with unfamiliar words, not with abbreviations or codes. Ru-Jev is an open typed-decision model, a pointwise cross-encoder on mmBERT-base (307M, MIT). You pass a context and candidate options, it returns a probability per option. It runs on CPU and is trained and tested on Russian-language data. v1.3 trains each label in several surface forms. I renamed 18 routing labels with 10 vocabularies, scored each with 5 candidates per question and eight of them also with 18, and checked every label against the training data. On held-out word vocabularies the new version is better in both settings. Jargon labels with no exact or prefix match to training: 0.550 to 0.786 with 5 candidates, 0.328 to 0.470 with 18. Department names: 0.632 to 0.733 with 18. Office slang: 0.595 to 0.761 with 5, and a small gain with 18 that does not survive Holm correction. On abbreviations it is not better, and opaque codes defeat both versions. With 18 candidates confident errors rise on jargon and slang, so refit the temperature on your own labels. Per-row predictions and all evaluation scripts are in the repo. The write-up also covers four evaluation bugs and the numbers they forced me to withdraw. Preprint: arxiv.org/abs/2611.08439 Model: besktech/ru-jev Code: github.com/beskvladimir-create/ru-jev

View all activity

Organizations

Posts 4

Post

637

Privacy is moving ad decisions onto the device. The auction runs locally, next to the context it scores.

The budget still lives on a server.

So every device bids against the balance it saw at its last sync. Between syncs, campaigns spend money they no longer have.

I simulated how much that costs: 50 devices, 36 campaigns, about 300,000 auctions per run, 30 seeds per cell, budgets frozen before evaluation. Even pacing, second-score payment:

- Sync every tick: spend lands 18% over budget (32% with iPinYou-calibrated values).
- Sync every 10 ticks: 5.8 times the budget.
- Sync every 50 ticks: 17.7 times the budget (10.1 times with iPinYou-calibrated values).

Zero-lag sync stays within about 1%. The lag alone does the damage.

The incentive side runs the other way. With second-score payment and zero lag, 98% of auctions are manipulable (92% with iPinYou values). Switch the payment rule to critical-bid and that drops to 0 at every sync interval, in both setups.

Sync fixes the budget. The payment rule, not the sync interval, is what removes manipulability.

All 12 result sets are on the Hub, plus the 50,808 context labels every run samples from.

Paper: When Privacy Moves ML-Mediated Decisions On Device: Information and Incentive Misalignment in Auctions (2609.33312)
Dataset: skelfresearch/on-device-auction-audit
Code: https://github.com/sarkar-dipankar/on-device-auction-audit

If your ads stack moves on device, how often does the device learn its budget?