So I've been messinga round with embedding models for a bit, and I think they are interesting enough to experiment with. They are useful for rag, especially in a localllm sense because you can ground your answers in truth.

But what happens if you have a billion documents, and you decide to upgrade your model to a "better" one? on an h100, that would take about 108 days, just to upgrade the vectors so u can start serving again (tested qwen embed 8b on h100). Even if you aren't doing 1b vectors, and are doing just 50 million, upgrading can still take a considerable time.

Me and my research lab decided to tackle this problem, and we came up with embedflow.

The method is really simple; from the old index made with the source model, take K documents and rerank them with the new model. We see that when K is sufficient, the retrieval quality is the same as target model. (determining k is the hard part). I've tested 63 migrations on upto 1 million documents.

The best result I got was upgrading qwen4b -> to 8b, and at 50 documents, it was the same as native retrieval.

This method forgos the expensive backfill that comes with upgrading, as you can directly take documents from the old index.

embedflow works with qdrant, and can be easily downloaded with pypi

pip install embedflow

the github is public: https://github.com/arnsri33/embedflow

I want you guys to try it out, and see if you guys can use it in your own workflow.

Our research team has been exploring an alternative approach to achieving interactivity and better responsiveness with LLM systems.

One of the team members wrote up a post about it:
https://research.yandex.com/blog/the-kv-cache-as-an-agent-runtime

The post sums up the overall idea of modifying models inference state (KV-cache) for achieving a more interactive LLMs. This idea was used in our lab's previous papers Hogwild! Inference, and AsyncReasoning, the post also contains a preview of the future work in this direction, where a Qwen3.8-27B agent is playing a DOOM env interactively using similar techniques.

We think that its interesting whether model inference/runtime design is itself an under-explored axis of agent capabilities, alongside models and the harness (e.g. harness is too abstract, changing model is too costly, do we need something in between?)

I'm testing a new approach for reducing the cost of image-based LLM inference.

I evaluated it on the MOMA Graph benchmark, using 1,315 questions. Compared with using GPT-4o to process the original images directly, I observed approximately:

• ~95% lower token usage
• roughly the same accuracy as the GPT-4o direct-image baseline

I'm intentionally not sharing implementation details yet because the method is still under development.

I'm mainly trying to understand how strong the result itself is.

If these numbers hold across larger and more diverse benchmarks, would you consider this a meaningful result in multimodal AI efficiency?

What evidence would you want to see before taking the claim seriously?

For example:

• more datasets
• stronger baselines
• statistical significance
• latency measurements
• API cost comparison
• performance across different models
• failure-case analysis

I'm especially interested in feedback from people working on multimodal models, VLM efficiency, or inference optimization.

A few weeks ago, I saw this post where the author trained a SIREN MLP to implicitly memorize Bad Apple as a coordinate function: (t, y, x) to pixel.

That got me curious about a slightly different formulation: instead of handing the network a timestamp t, could a small recurrent dynamical system (RNN-ish) learn the continuous temporal flow in latent space and generate the entire ~6,500-frame full resolution video autonomously from a single initial condition (h_0, c_0)?

The code, weights, and analysis tools with rollout scripts, plots, and standalone models are shared here: GitHub: SEBADA321/BadAppleRNN.

Architecture & Inference Footprint

At inference time, the system receives no timestamp inputs and evaluates in a closed loop:

(h_t, c_t) -> Recurrent Transition (CTF) -> (h_{t+1}, c_{t+1})
                   |
                  h_t -> Frame Decoder -> 384x512 Grayscale Frame

• Latent Dimension: 64-D for h_t (decoded) and 64-D for c_t (internal memory manifold to separate visually similar frames at different timestamps).
• Recurrent Transition (ctf): 4-gate LSTM-style recurrence with orthogonal initialization (16,640 parameters, 65 KB).
• Frame Decoder (fd): 4-stage bilinear upsampling with depthwise-separable convolutions (400,361 parameters, 1.56 MB).
• Initial State: A single pair of 64-dim vectors (h_0, c_0) (128 floats, 0.5 KB).
• Total Inference Model: 417,129 parameters (~1.60 MB in FP32).
• Runtime Performance: >200 FPS on an RTX 4080, with ~17.2 MB peak active VRAM during decoding.

Training an autonomous system across ~6,573 steps from t=0 directly was probably computationally unstable due to vanishing/exploding gradients and compounding error. The training setup I was circling around used several targeted techniques:

• Learned Latent Teacher Tables: During training, I optimize a pair of tables h_table[t] and c_table[t] alongside the model. This allows parallel segment training starting at arbitrary timestamps over a finite horizon K. These tables are scaffolding and are discarded entirely at inference.
• Rollout Horizon Curriculum: I started training with K = 2 and progressively doubled the rollout length (K = 2 -> 4 -> 8 -> 16 -> 32 -> 64 -> 128 -> 256 -> 512). Each horizon doubling produced a characteristic jump in loss before the transition function adapted to the longer trajectory.
• State Perturbation Noise (sigma = 0.005): To prevent the model from learning a brittle 1D line that diverges under small numerical errors, Gaussian noise was added to the state before passing it into the transition function (z_hat_{t+1} = F(z_t + epsilon)), while evaluating the loss against the clean target. This encourages the recurrent map to contract small deviations back toward the trajectory.
• Second-Difference Acceleration Regularization: Penalizing velocity (||h_{t+1} - h_t||) risks collapsing the trajectory. Instead, I penalized discrete acceleration (jitter) via second differences: ||h_{t+2} - 2h_{t+1} + h_t||_2^2. This enforces smooth trajectories without penalizing motion.
• Optimizer & Momentum Management: I used AdamW (1x10^-5) for the decoder/tables and Muon (0.005, momentum 0.95) for the recurrent weights. To prevent accumulated momentum from acting as stale inertia when K doubled, momentum buffers were scaled by 0.2 every 10 epochs starting from the epoch 500.
• Chunked Decoding: To handle long horizons at K = 512 without overflowing VRAM during training, the decoder was evaluated in temporal chunks of 32 frames.

Some interesting things

1. The model could unroll the full 6.5k sequence even if it was, technically, trained on up to 512 frames. So that was a success.
2. Training loss vs. autonomous rollout: The checkpoint with the lowest numerical training loss was not necessarily the best at autonomous generation. Because K changes across the curriculum, raw training losses are not directly comparable across stages, and short-horizon teacher-forced agreement does not guarantee long-horizon stability.
3. Dynamical stability over parameter scale: The challenge was not increasing parameter count (the recurrent transition is only 16k params), but conditioning the dynamics through noise injection and acceleration penalties so error doesn't compound over thousands of recurrent steps.
4. I need to improve the decoder a lot, I was mostly focused in getting the recurrent part right, and training was slow. Now that I gave gotten a successful result I will focus more into optimizing the CNN decoder.
5. There are no skip connections nor normalization, which was interesting too. Obviously no attention either since I wanted to keep it simple.I also didn't want to use Truncated BPTT.

Not completely scientific, since I was doing some changes mid run or many at once, which makes it kinda not clear what contributed more. I used 'AI' to help with writting the post and README. Part of the code was also generated that way, but the architecture is what I came up with on my own and from a previous project too. There are probably many parts to improve too, so glad to get some feedback!

I used an LLM to iteratively evolve an optimization algorithm rather than solve the packing directly. Starting from a simple seed solver, the LLM proposes algorithmic changes guided by a scoreboard of results and a history of prior attempts, and each candidate is scored by an independent verifier so improvements are kept and failures discarded. On the Packomania csqv benchmark it improved the best-known sum-of-radii for 10 values of N from 101 to 114, by 2.4 to 5.4%, in 15 iterations. Total LLM cost was $27.72. Packomania accepted the results independently.

Paper: arxiv.org/abs/2609.05093

Code + solutions: github.com/ucsandman/discovery-loop

Benchmark: packomania.com/csqv/csqv.html

Happy to discuss the plateau-detection stopping rule, that's the piece I'd most want critique on.

Background : Our T-PAMI submission was rejected despite receiving three highly favorable reviews. The AE inadvertently revealed that the decision relied on negative comments attributed to a “fourth reviewer.” However, the actual fourth reviewer had submitted a positive review, which subsequently disappeared from the review record under the AE’s handling. We have spent the past six months pursuing this matter with IEEE. (Original post: [How to get rejected by IEEE T-PAMI with 'Excellent' scores?[D])

Latest update : A few days ago, following an investigation by the IEEE Computer Society Committee on Integrity, the T-PAMI Editor-in-Chief formally acknowledged that four reviews had in fact been received, thereby confirming the existence of the missing fourth review.

I was wondering why dynamic competitive games like Rocket League don't have a decision-quality engine like chess has with Stockfish. Something that doesn't just measure your boost usage or speed, but actually evaluates whether your positioning or challenge was the mathematically optimal play.

I initially drafted a naive proposal based on slicing replays into 5-second physical rollouts in the cloud to test decision trees. However, after using AI models to strictly critique the physics and compute feasibility, Machine Learning seems to offer a much more viable path:

Decision Quality: Evaluates plays using Offline RL (Trajectory Transformers & Implicit Q-Learning) over a Sequential POMDP. Instead of chaotic physics simulations, it calculates decision probability based on pro dataset distributions.

Anti-Cheat & Smurf Detection: Uses frequency spectrum analysis (FFT) on input signals and kinematic limits (4th derivative/Snap) to catch bot scripts, along with NLL divergence to mathematically flag smurfs.

Disclaimer: I want to be 100% clear that I am not looking for any personal credit or clout for this. As a 1st-semester student, I don't even have the technical background to understand or build the advanced machine learning model proposed by the AI. I just thought this could be fascinating and wanted to share it with the community in case it sparks interesting discussions or research for the future.

You can read the full breakdown here: https://github.com/Pnlw/esports-performance-evaluation

Hi everyone! We just released Rustuna (GitHub: https://github.com/optuna/rustuna/ ), a high-speed, memory-efficient implementation of Optuna built in Rust.

• Optuna-Compatible Design: Keeps the familiar API and concept of Optuna.
• Zero Python Dependencies: Mitigating the risk of supply chain attacks.
• Lower Memory Footprint: Optimized memory management natively in Rust.

For details, please check out the following blog post.

https://medium.com/optuna/announcing-rustuna-cc82a6815bf7

this is the kinda debugging case i find rlly annoying/

everything says success.

no exceptions no failed tool calls. no obvious timeout the workflow completes but the final result is still wrong

when that happens, what’s your first move?

do you guys usually:

• start from the final output and work backward
• compare against a previous good run
• inspect state transitions
• check retrieval/tool behavior
• look at model inputs
• replay it
• check business state outside the trace
• just read the whole thing until something looks off

interested in what people actually do in production not the idealized version but thats fine too. and if you have anything you've built to help with this process I'd love to see it :)