RAG

A user asks to be forgotten. The recommender team opens the dashboard, sighs quietly, and faces the usual menu of unpleasant options. Retrain the model from scratch, which is clean in theory and expensive in practice. Partition the data so only part of the system needs rebuilding, which sounds elegant until collaborative signals leak across groups like gossip at a small wedding. Or approximate the user’s influence with gradients and influence functions, which is efficient until similar users get nudged around because the model learned their tastes together. ...

A job portal is not supposed to feel like a maze. Yet that is exactly what many public employment systems become: a stack of modules, PDFs, notices, eligibility rules, language barriers, and search boxes that assume the user already knows what to ask. Convenient, provided the user has already done half the civil servant’s work. ...

Ask an enterprise chatbot the wrong question on the wrong day and the problem is rarely that the language model has forgotten how to write English. The problem is that it has been handed the wrong pile of evidence. That is the expensive little defect inside many retrieval-augmented generation systems. The model may be fluent. The corpus may be current. The vector database may be humming along like a well-funded filing cabinet. Yet the answer still disappoints because the system chose the wrong snippets, placed a useful document too low, missed a newly relevant runbook, or treated yesterday’s user intent as if it were carved into basalt. ...

Procurement is where compliance anxiety goes to acquire a purchase order. A laboratory wants to buy an item. Perhaps it is ordinary. Perhaps it is dual-use. Perhaps it belongs under the U.S. Munitions List, Nuclear Regulatory Commission controls, the Commerce Control List, or the broad residual category of EAR99. The practical question is not just “what is this?” It is “what is this under the rules, according to which rule text, with enough evidence that someone can defend the decision later?” ...

A citizen-facing AI assistant is where the PLLuM story becomes interesting. Not because a chatbot in a government app is a dazzling concept. It is not. Most public-sector chatbots have the charisma of a PDF with a search bar and the legal confidence of a nervous intern. The interesting part is what Poland had to build before such an assistant could be considered remotely serious: a rights-managed national corpus, Polish-native instruction data, preference alignment, safety filters, RAG evaluation, retrieval tooling, and a family of public models with different licence regimes. ...

Memory is useful until nobody can find where it lives. That, in miniature, is the operational problem with today’s language models. They can answer questions, imitate expertise, retrieve fragments of the past, and produce very confident nonsense with the composure of a senior consultant who has just discovered bullet points. But when a model gives a wrong factual answer, the organisation deploying it faces an awkward question: where, exactly, is that wrong fact stored? ...

Legal teams do not usually ask for AI that sounds clever. They ask for AI that does not accidentally invent a statute, misread a precedent, or confidently advise someone into a procedural ditch. That makes legal AI an awkward domain for large language models. The model may be fluent. The law, inconveniently, is not graded on fluency. It is graded on source, jurisdiction, timing, interpretation, and traceability. A beautiful answer with the wrong legal basis is not “almost useful”. It is professionally radioactive. ...

Ask a product manager in a financial technology company a simple question — “How does this feature behave under that framework?” — and the answer may live in five places, three teams, two stale wikis, and one acronym that means different things depending on who had coffee with whom. This is the everyday enemy of enterprise AI. Not lack of models. Not lack of dashboards. Not even lack of documents. The problem is that internal knowledge rarely behaves like a neat public benchmark. It is fragmented, duplicated, partially obsolete, acronym-heavy, and governed by access rules that make the usual “just send it to a cloud assistant” suggestion both naïve and professionally adventurous. ...

A good employee does not only finish the task. A good employee leaves behind a better way to do it next time. Most enterprise AI agents do not. They solve a ticket, answer a question, call a tool, browse a page, generate a report, and then politely forget the operational trick that made the task work. The transcript may be logged. The result may be saved. But the capability itself usually evaporates into the great corporate compost heap of “learnings”. Very nourishing. Not especially executable. ...

Logs are where teams go after the dashboard has already failed. A pipeline stalls. A model run produces nonsense. A compute job quietly burns budget on the wrong node. Someone opens three dashboards, two notebooks, and one ancient SQL snippet named final_debug_v3_really_final.sql. Then the archaeology begins. The paper LLM Agents for Interactive Workflow Provenance: Reference Architecture and Evaluation Methodology proposes a more interesting answer: do not ask an LLM to “understand the workflow” in the abstract. Give it live provenance metadata, a compact schema, query guidelines, and tools that execute structured queries on its behalf.1 In other words, stop treating the model as a psychic dashboard. Treat it as a controlled interface to workflow exhaust. ...