thoughtlede

Investor funds have been subsidizing the inference costs so far.

Investors might move from funding the model providers to funding the enterprises that use those models. That is, they might move from funding the cost of the experiment to funding the value of the result. No funding if there are no demonstrable AI gains.

This is a reasonable shift if this happens. If enough gains have been demonstrated, then investors might go back to funding the model providers. Investors always move towards the highest leverage point.

As long as AI delivers, this would be the rhythm.

Strictly speaking, I don't think it is the generation or creation that diminishes their value. it is the consumption.

You said it too:

If I see a million fake Tom Cruise videos, then it oversaturates my desire for desire for all Tom Cruise movies.

The trick of course is to keep yourself from seeing that content.

The other nuance is that as long as real performance remains unique, which so far it is, we can appreciate more what flesh and blood brings to the table. For example, I can appreciate the reality of the people in a picture or a video that is captured by a regular camera; it's AI version lacks that spunk (for now).

Note that iPhone in its default settings is already altering the reality, so AI generation is far right on that slippery axis.

Perhaps, AI and VR would be the reason why our real hangouts would be more appreciated even if they become rare events in the future.

I think we can simplify the answer to this question for most audience and say "the air is blue".

If they say, the air appears to be clear when I stare at something other than sky, the answer is you need more of air to be able to see its blue-ness, in much the same way that a small amount of murky water in your palm appears clear, but a lot of it does not.

If they ask, why don't I see that blue-ness at dawn or dusk, the answer is that the light source is at a different angle. The color of most objects changes when the light source is at a flat angle. And sun lights hits at a flat angle at dawn and dusk.

If they ask, what exactly is the inside phenomenon to see the sky color to be blue, then explanations like this blog are relevant.

If they ask, what exactly is a color, the answer is that it is a fiction made up by our brain.

For me there are two things about collaboration.

Decision making is one, which you emphasized.

The other is knowing what the collaboration brings to the table and shaping the rules of engagement to fit that expectation. Sometimes you collaborate with SMEs; they bring the domain knowledge - you don't, but you understand the goal better than them. Sometimes you are creating or refining the corporate strategy based on the actions from individual projects or partners; you are learning ground realities from them. Sometimes you need help from others to improve your take on a subject.

In each of these cases, you have to be clear about what you expect from the collaborators (and motivate them to contribute). Without being clear on what the collaboration is about and what they get in return is the number one killer of collaborative projects even though there is no ill-intent anywhere.

It boils down to whether your LLMs can speak graph queries better than SQL, for your use cases and data. As your data posture changes and your use cases change, you routinely reevaluate which DB query language suits best for LLMs.

I'd also design the system architecture in such a way that your non-agentic workloads don't suffer if you have to move between query models for serving agentic workloads better.

memorization + application = comprehension. Rinse and repeat.

Whether leet code or anything else.

It feels to me that the hypothesis of this research was somewhat "begging the question". Reasoning models are trained to spit some tokens out that increase the chance of the models spitting the right answer at the end. That is, the training process is singularly optimizing for the right answer, not the reasoning tokens.

Why would you then assume the reasoning tokens will include hints supplied in the prompt "faithfully"? The model may or may not include the hints - depending on whether the model activations believe those hints are necessary to arrive at the answer. In their experiments, they found between 20% and 40% of the time, the models included those hints. Naively, that sounds unsurprising to me.

Even in the second experiment when they trained the model to use hints, the optimization was around the answer, not the tokens. I am not surprised the models did not include the hints because they are not trained to include the hints.

That said, and in spite of me potentially coming across as an unsurprised-by-the-result reader, it is a good experiment because "now we have some experimental results" to lean into.

Kudos to Anthropic for continuing to study these models.

tadkar did a good job at explaining ColBERT. I understood ColBERT well in the context of where it lies on the spectrum of choices.

On one side of the spectrum, you reduce each of the documents as well as the query to a lower-dimensional space (aka embeddings) and perform similarity. This has the advantage that the document embeddings could be precomputed. At query time, you only compute the query embedding and compare its similarity with document embeddings. The problem is that the lower-dimensional embedding acts as a decent, but not great, proxy for the documents as well as for the query. Your query-document similarity is only as good as the semantics that could be captured in those lower-dimensional embeddings.

On the other side of the spectrum, you consider the query with each document (as a pair) and see how much the query "attends" to each of the documents. The power of trained attention weights means that you get a much reliable similarity score. The problem is that this approach requires you to run attention-forward-pass as many times as there are documents -- for each query. In other words, this has a performance issue.

ColBERT sits in the middle of the spectrum. It "attends" to each of the documents separately and captures the lower-dimensional embedding for each token in each document. This we precompute. Once we have done that, we captured the essence of how tokens within a given document attend to each other, and is captured in the token embeddings.

Then, at query time, we do the same for each token in the query. And we see which query-token embedding is greatly similar to which document-token embedding. If we find that there is a document which has more tokens that are found to be greatly similar to the query tokens, then we consider that to the best document match. (The degree of similarity between each query-document token is used to score the ranking - it is called Sum of MaxSim).

Obviously, attention based similarity, like in the second approach, is better than reducing to token embeddings and scoring similarity. But ColBERT avoids the performance hit compared to the second approach. ColBERT also avoids the lower fidelity of "reducing the entire document to a lower-dimensional space issue" because it reduces each token in the document separately.

By the way, the first approach is what bi-encoders do. The second approach is cross-encoding.

When thinking about AI agents, there is still conflation between how to decide the next step to take vs what information is needed to decide the next step.

If runtime information is insufficient, we can use AI/ML models to fill that information. But deciding the next step could be done ahead of time assuming complete information.

Most AI agent examples short circuit these two steps. When faced with unstructured or insufficient information, the program asks the LLM/AI model to decide the next step. Instead, we could ask the LLM/AI model to structure/predict necessary information and use pre-defined rules to drive the process.

This approach will translate most [1] "Agent" examples into "Workflow" examples. The quotes here are meant to imply Anthropic's definition of these terms.

[1] I said "most" because there might be continuous world systems (such as real world simulacrum) that will require a very large number of rules and is probably impractical to define each of them. I believe those systems are an exception, not a rule.

Beyond this, if you want to determine causality, e.g. whether events are "causally related" (happened before or after each other) or are "concurrent" (entirely independent of), you can look at Vector Clocks—I won't go down that rabbit-hole here, though.

If anyone want to go down that rabbit hole: https://www.exhypothesi.com/clocks-and-causality/

Perhaps these findings might be indicating that we need more NN layers/attention blocks for performing reasoning. This project circumvented the lack of more trained layers by looping the input through currently trained layers more than once.

Also we may have to look for better loss functions than ones that help us predict the next token to train the models if the objective is reasoning.

If function calling is sync, is MCP its async counterpart? Is that the gist of what MCP is?

Open API (aka swagger) based function calling is standard already for sync calls, and it solves the NxM problem. I'm wondering if the proposed value is that MCP is async.

I think the mention of 'spaghetti code' is a red herring from the author. If the output from an algorithm cannot be defined precisely as a function of the input, but you have some examples to show, that's where machine learning (ML) is useful.

In the end, ML provides one more option to choose from. Whether it works or not for you depends on evaluations and how deterministic and explainability you need from the chosen algorithm/option.

The thing that struck me is if RNN is the right choice given that it would need to be trained and we need a lot of examples than what we might have. That said, maybe based on known 'rules', we can produce synthetic data for both +ve and -ve cases.

Interesting. I didn’t know this body of work. I haven’t read the documentation other than the abstract.

If the protocol is about knowing what information to inject at what node in the network to achieve consensus, the protocol can (and will) be used to inject whatever truths the parties with knowledge on the protocol believe in. If there are enough parties with opposing beliefs, then the network cannot be gamed beyond the status quo.

How does this protocol “choose” the truth to propagate in the face of opposing truths?

What power does the protocol give to parties who know how to work the system?

Or rather what resilience does the protocol have against “inside traders”?

That's interesting.

In keyword-based indexing solutions, a document vector is created using "term frequency inverse document frequency" scores. The idea is to pump up the document on the dimension where the document is unique compared to the other documents in the corpus. So when a query is issued with emphasis on a certain dimension, only documents that has higher scores in that dimension are returned.

But the uniqueness in those solutions is based on keywords being used in the document, not concepts.

What we need here to eliminate "blandness" is conceptual uniqueness. Maybe TF-IDF is still relevant to get there. Something to think about.

LLMs are both language processing engines and knowledge bases. This article explores the knowledge base aspect of LLM and sheds light on the potential danger. The authors are well-justified in doing so because ChatGPT as a knowledge-bot is being used by many end users for its knowledge.

However, to my knowledge, many enterprise applications that are being built using LLMs feed task-specific curated knowledge to LLMs. This mode of LLM use is encouraging. I do not think this article acknowledged this aspect of LLM use.

Yes, the camera sees everything. But we could avoid teaching the model certain things. For instance, an undressed body and a dressed body could both be taught as a body. Likewise, medicine pills as well as regular mints could just be taught as mints.

While this approach doesn’t address privacy completely, it avoids certain elements of our life that are considered really private.

I think half of the point of using the simulated dataset to train the model was to safeguard the above mentioned kind of privacy (with the other half being lack of real-world dataset).

Yeah. Rollbacks or reruns are hard when dealing with external systems. Actions need to be idempotent for reruns to work.

One thing you may focus on is making workflows more durable: Checkpointing and sending to users summaries of last checkpoints when things fail.

The last thing you want a non-tech user (your target customer) is to figure out what’s the state of a failed workflow.

Thanks.

What happens right now when the workflow fails mid-way? Do you ensure atomicity or durable execution?

Cool stuff.

1. For dynamic injection of arguments in your data plane, do you use LLMs?

2. What did you find you cannot do yet because of LLM limitations (and not because of lack of third-party integrations)?

3. I haven’t looked closely into your product, but is every “effect” of a workflow something that only the requesting user can see? Is this how you ensure bad or wrong things are not hurting other people or systems that are outside of user’s control?

Answering to your second part of the question about hidden challenges:

If you are using AI agents to automate a workflow [1] execution, then the question to ask is where is non-determinism in the workflow. As in, where do humans scratch their head as opposed to rely on deterministic computations.

It turns out, a lot of times, as humans, we scratch our head just once for a given kind of objectives to come with a plan. Once we devise a plan, we execute the same plan over and over again without much difficulty.

This inherent pattern in how humans solve problems sort of diminishes the value of AI agents because even in the best case scenario the agents would only be solving a one-time, front-loaded pain. The value add would have been immense if the pain has been recurrent for a given objective.

That is not to say there is no role for AI agents. We are trying to infuse AI agents into an environment where we as humans adapted pretty well. AI agents will have to create newer objectives and goals that we humans have not realized. Finding that uncharted territory, or blue ocean, is where the opportunity is.

[1] By 'workflow' I mean a series of steps to take in order to achieve an overall objective.

Evolution of technology makes things unstable, not specifically servers. A decentralized application is not more stable than a centralized one. It depends on what's prioritized about the product. For example, you can still use SMTP servers developed several decades ago to send email to others.

Also, it is hard to buy the argument that docs based on Google Docs will live less longer than docs served by some CRDT-based collaborative application. It is easy to argue the opposite. My Google doc history shows docs I have even forgotten ever existed, and Google docs play nice with Microsoft Word - making it interoperable with the largest ecosystem around structured documents. Again, this is about product features and prioritization, not underlying building blocks.

CRDTs hold a very special place in my heart. But I also believe they don't offer a differentiated solution - on the user facing side.

I have studied CRDTs at a deeper level for a few weeks and implemented several small prototypes. They are fascinating. As an eventual consistency model for data management, CRDT inspired techniques (op-based or state-based) are useful.

However, for building user-facing applications with CRDTs, their importance is unclear.

The question with CRDTs and local-first paradigms has always been the pressing need (or the lack thereof). The only one plausible 'need' that CRDTs serve is real-time collaboration and that too with a squinting eye.

Real-time collaboration support translates, in practice, to text-editing and picture-editing collaboration. Google docs and the ilk have solved that problem (using central solutions). A CRDT-inspired central-solution like Figma is inspiring, and maybe that's the only place CRDTs fit in their survival quest when combating against central-solutions.

The rest of the claimed advantages seem to not withstand the test of times. This articles talks about 7 features of CRDTs [1].

Fast: Things are already fast with central solutions.

Multi-device: There is multi-device support with almost all solutions (if you decouple the real-time collaboration aspect).

Offline: It's rare, at least in first world countries, to be in a need for offline access (except maybe in airplanes).

Longevity: As can be seen from another comment here, longevity is actually a problem with CRDTs because data model updates are not easy.

Privacy: With BYOK encryption pattern, privacy is not as much an issue.

User control: Even with CRDTs, user is not in control of their data - other peers can mess with your data.

[1] https://www.inkandswitch.com/local-first/

In a multi-replica system, where, say, we cannot tolerate any failures or lags, is 2PC used in practice to achieve consensus? Or are there other methods for achieving such strict consensus?

Two-phase locking is different from two-phase commit, in spite of an overlap in their naming. Two-phase commit is relevant to be compared against Paxos - both of which fall under the category of consensus protocols.

Two-phase locking is a concurrency control mechanism.

I would characterize an LLM Agent to be "a software application of LLM" that is typically used to solve a problem that requires multiple steps.

The application uses an LLM to breakdown the problem into pieces and asks the LLM to choose a tool that is suited to handle each piece. The application then invokes the tool to solve that piece of the problem. This is iteratively done until the original problem is solved or determined to be unsolvable.

There are many agent variations, depending on whether you breakdown the problem once at the beginning, or understand what to do next based on the outcome of the previous step, or constantly evaluate and reprioritize which piece of the problem to solve next.

Because you rely on an LLM to understand the problem, if you chose an LLM that exhibits good world understanding, and designed the LLM Agent well enough, then you can use it to solve problems that traditionally required deterministic code.

Part 1: https://www.computer.org/csdl/magazine/so/2023/01/09994260/1... (10.1109/MS.2022.3212165)

Part 2: https://www.computer.org/csdl/magazine/so/2023/02/10043615/1... (10.1109/MS.2022.3229418)

Part 3: https://www.computer.org/csdl/magazine/so/2023/03/10109339/1... (10.1109/MS.2023.3242137)

Having been responsible for running the DOI system for several years, I decided to include DOIs in the parenthesis.

I have implemented a JSON-like CRDT using this nice tutorial [1], which is a tree, but never an append-only DAG.

I'm curious how two edges meeting the same vertex will make it difficult to resolve the conflict automatically? Is it that two users will create the same vertex (concurrently) with slightly different attributes, and attribute-merging requires human-in-the-loop?

Of course if the DAG is not append-only, but supports, say, "moving" of edges/branches, it is a totally different problem. Martin has something to say about this [2].

[1] https://www.bartoszsypytkowski.com/operation-based-crdts-jso... [2] https://martin.kleppmann.com/papers/move-op.pdf

CRDTs don't _ensure_ ops are commutative (and associative, and idempotent) but rather they _require_ that ops are commutative (and associative, and idempotent)

I disagree. You can create a CRDT flavor of data structure whose ops are not commutative. For example, a Set's add and delete operations. These are not commutative. You cannot switch the order of the ops for meaningfully processing them. However, you can create a CRDT Set. You do that by adding metadata to the ops, and having the instances always process them in the only order that makes sense even if such instances receive the ops in a different order. In that sense, you are "ensuring" ops are behaving like they are commutative and not "requiring" them to be so.

it's definitely not the case that any data structure is a CRDT

I could have worded my statement better. I meant any data structure that has the aforementioned duality property is a CRDT. Not that any data structure unconditionally can be translated into a CRDT.

an important "eureka" observation about CRDTs is that the op-based model is theoretical,

I do not understand your statement. Perhaps you could elaborate. My understanding is that a CRDT is op-based or state-based depending on what is "communicated" between the instances. If ops are communicated, then it is op-based CRDT, whereas if states (or delta-states) are communicated, then it is state-based.

At least in that sense, op-based model is NOT theoretical. Perhaps you have a different point in mind that I fail to observe.

Indeed, certain properties of CRDT are invariable to network state. However, it is worth pointing out that in ops-based CRDT “implementations”, you deal with local ops case differently from remote ops case. That is, while the properties are invariant, how you produce them are different.

So I was on a my quest to understand the “essence” of CRDTs, not just understand them to be able to practically use them. Atomic broadcast and Raft were easy enough for me to wrap my head around (although quite challenging to implement). But not CRDTs.

I found common statements about CRDTs that they ensure ops to be commutative to be superficial. A slightly deeper characteristic was that ops-based CRDTs are just causally-linked ops (aka causal tree). But what about state-based? Finally, when I realized CRDTs are dual-consistent and that’s what makes any data structure a CRDT, that was a moment of epiphany for me.