viksit

6 ms·

1.
by viksit 5mo ago
> heavily-customized and terminal-heavy setup this exactly. most people can’t set it up that well.
2.
by viksit 6mo ago
underrated comment haha. made my day
3.
by viksit 8mo ago
I think the point here is the bot didn’t come up with the idea on its own, but was seeded by a human with an entrenched interest / experience in that space. The PR around Moltbook has been that Agents are coming up with these ideas thr
4.
by viksit 11mo ago
this is a great question. what are the main use cases that you have for this? i’ve been working on a library for something similar and exposing it via an mcp interface. would love to pick your brain on this (@viksit on twitter)
5.
by viksit 11mo ago
Yes! thanks for the memory haha.
6.
by viksit 1y ago
you definitely succeeded in your humorous endeavors ;) i snorted haha
7.
Replacing Agent Prompt Templates with Trainable Control Modules in DSPy(viksit.substack.com)
2 points by viksit 1y ago|1 comments
8.
by viksit 1y ago
In my fourth post in the series, I tackle how to make multi-step agent workflows learn behavior from data. Most agents today rely on vibes: prompt tuning, hand-written templates, and hope(!). This post is about replacing that with metrics a
9.
by viksit 1y ago
mostly aligned on this. couple of thoughts: - raw accuracy is now a "vanity" metric. so the benchmarks need to get more sophisticated, and i think they're going to have to be far more task specific than hotpot or hover. they&
10.
by viksit 1y ago
vJEPA models, lecun's approach towards world models that have been derided by a lot of naysayers. (personally I think thats the way to go)
11.
by viksit 1y ago
they’ve already written one! see omar’s x account for details!
12.
Optimizing Tool Selection in LLM Workflows(Part 2): A DSPy and PyTorch Benchmark(viksit.substack.com)
1 points by viksit 1y ago|1 comments
13.
by viksit 1y ago
Based on the feedback from my last HN post on differentiable routing, I ran a follow-up benchmark: local RNN vs GPT-4o for tool selection in LLM workflows. Same accuracy, 40% lower cost. Appreciate all the suggestions, this post builds on t
14.
Differentiable Programming for Learnable Graphs: Optimizing LLM Workflows W DSPy(viksit.substack.com)
2 points by viksit 1y ago|1 comments
15.
by viksit 1y ago
Following up on my last post about optimizing tool selection with differentiable programming, I’ve been thinking about how to extend those ideas to full agent workflows. This post shares some early experiments using DSPy to optimize routing
16.
by viksit 1y ago
would you have a link?
17.
by viksit 1y ago
there's a world where the model could infer that as well!
18.
by viksit 1y ago
yes, AFAIK right now, there are no easy ways of "slimming" context because no one knows what it should be or how.
19.
by viksit 1y ago
great q. thats coming up as a future post in the series.
20.
by viksit 1y ago
this is really interesting! yes, its my substack. also, if you're down, love to connect and talk more about what use cases / techniques you're using. I'm @viksit on X dms if that works.
21.
by viksit 1y ago
for sure, there's a way here where I think we ought to be able to learn multiple tool calls and prompts together with real world data. investigating that next.
22.
by viksit 1y ago
(author here, put the code in a gist here for reference) https://gist.github.com/viksit/c67d1d960c4cec89488290496defb...
23.
by viksit 1y ago
+1 thanks for mentioning MCP! re: different tools (apis vs mcps). in my mind, there should be no real difference at what kind of tools is called at this moment since I model this as a softmax over a label set of tools. that said, an idea I
24.
by viksit 1y ago
+1 - you can propagate the loss for a workflow across prompts + tools, which would make it much better to do resilient workflows. or "agents" as everyone calls them now ;)
25.
by viksit 1y ago
this is my goal :) appreciate the feedback.
26.
by viksit 1y ago
+1 - the biggest issue is not being able to fine tune the llm to learn the specifics of how to make a tool call better over time, which an approach like this can bring to the table.
27.
by viksit 1y ago
+1 on the control flow point. I think of an llm as a differentiable interpreter of a program. it should do decision making (tool selection, argument routing), branching logic via weights + gates etc. so as a differentiable state machine: -
28.
by viksit 1y ago
this is a great point, ty. in my mind the biggest difference is llms that are invoked during a workflow, and llms that are invoked when _creating_ code (codegen). for the former, tools could be well defined till they are small in number, bu
29.
by viksit 1y ago
it’s not just about selection. say you’ve got 100k tool calls — in the current hosted llm setup, you don’t actually learn anything new about your data to improve future tool accuracy. this gets worse when you’re chaining 3–4+ tools. context
30.
by viksit 1y ago
ty for the feedback, yes, balancing bad code blocks on substack vs making it look pretty lol. I'll post code next time.

More ›