Peadar Coyle

I think we are witnessing a new role arising in the data space, and I have seen people in the know talking about it. Now that LLMs have brought data science to all technical functions, the lines are staring to really blur between specializations. There's a new creature forming- mostly in the SAAS startup world for now but bound to spread- and that is a person that both writes software, uses the latest data science toolkits, and is moving beyond insights to action in the form of building products. Are you seeing this too, and what should it be called? Let's give it a Kripkean baptism! I propose a "foreword deployed data science engineer" FDDSE! Clumsy, I know. Have a better name?

1

13 Comments

🚀 Everyone’s talking about TOON this week… But here’s the thing: I’ve been using “List of Lists” LLM outputs for 1.5 years in production client projects — long before TOON dropped — and it’s been cutting output token size by 40–60%, reliably. Thinking like a data engineer — not just a prompt engineer. I stopped asking LLMs to return full JSON years ago in high-volume agent workflows. Why? Because { "user_id":1001,"userName":"Alex Rivera","action":"login" } is expensive — especially when you’re generating 10K rows. 🔁 Instead, I prompt for structured list-of-lists, parse it in Python, and convert to DataFrames, CSV, DB rows — zero loss, massive gain. ✅ Key insight: TOON isn’t revolutionary — it’s validation. It formalizes what many of us were already doing: drop the syntactic sugar, keep the signal. 💡 Bonus: We use lightweight Python tooling (e.g., pandas.DataFrame(loL, columns=header)) to convert LoL → tables, CSV, JSON — on demand. No new spec, no new parser — just smarter prompting. So yes — try TOON! It’s great. But don’t act like structured minimalism is new. 😉 The real win? Thinking like a data engineer — not just a prompt engineer. 👇 Are you optimizing input and output formats — or just the model? #LLM #AIEngineering #PromptEngineering #DataEfficiency #Agents #TOON #NLP #MLOps #DataEngineering

8

This was one of my first projects after joining GeoDS, and my first paper in the world of Geography/Geographic Data Science! We needed census data at small area geographies across the whole of the UK for another project (which will follow soonish...). Putting it together from the different national sources into a unified dataset, and validating that we were combining like-for-like variables, turned out to be pretty time consuming. So we've published it as an open dataset. If you have a project which requires census data across UK national boundaries, this will hopefully save you some time.

25

🎉 New blog alert: Quarto templates to reduce copy-paste headaches I published a new blog that uses #openScience #dataRetrieval streamgage data to demonstrate the process for using "child" templates to make duplicating Quarto chunks much easier and less error-prone than copy-paste methods. The long story of it is that a couple years ago, I needed to create a #PowerPoint that had an analytics slide for each of a series of websites. I wanted to be able to use #Quarto and #R to automate this process, but had a hard time finding a concise guide to doing this on the wider web/stack exchanges, etc. Finally, I figured out how to combine an R-loop with a Quarto child template to make this type of automated slide deck work. From there, it's so much easier to customize the slide layout, data visualization themes and style with #ggplot, and add data-embedded speaker's notes, etc. This blog provides a flexible and simplified #reprex to help others wishing to make duplicative Quarto chunks much, much easier. Let me know what you think! https://lnkd.in/gf_hitwx

16

1 Comment

The Valyu API is the leading search API for scientific research. Why? We were the only ones crazy enough to process and index 100% of ArXiv for full-text, multimodal, and chunk-level search (not just abstracts.) Here’s what that means: - 🔍 Full-text retrieval: Full content of papers is searchable not just abstracts. - 🖼️ Multimodal context: Retrieve not just text, but figures, tables, and equations - 🧾 Complete metadata: APA citations, authors, references, citation counts. - ♻️ Fresh search: Updated as new papers are released. A must-have for any AI agents doing real research 👇

24

7 Comments

This time of year I catch up on research papers I’ve been meaning to read — and since we’re developing a context-engineering benchmark at STAC Research, I’ve been digging into multi-turn AI. One paper that stood out comes from the NatWest AI Research team: Evaluating the sensitivity of LLMs to prior context. They systematically vary both the amount and type of prior context, then test multiple frontier and mid-sized models across these setups. Some of the things I learned: 1. Prior context influences outputs —Unrelated earlier conversation turns can hurt model performance, showing how sensitive LLMs are to what came before. 2. Interaction length matters — Longer multi-turn interactions accelerate performance drops, although most of the decline happens within the first few thousand tokens. 3. Bigger isn’t always better — Increasing model size doesn’t guarantee robustness across multi-turns; smaller models can outperform larger ones under complex context. 4. Task placement counts — Where you position the task description in the context sequence can significantly change performance, highlighting the importance of input structure. 5. Domain alignment is critical — Accuracy suffers when prior QA context comes from a different knowledge domain than the target query. What I like most is that this work highlights the limitations of single-turn benchmarks — they can be misleading if we assume they generalize to real-world, sustained interactions. Link to the paper in the comments.  cc: Greig Cowan

36

3 Comments

Following up on my earlier post about building a Python tool for analysing company balance sheets from Yahoo Finance data — I’ve made some solid progress over the past week. My focus this round was on making the code more modular and maintainable: Replaced long if/elif chains with a dictionary-based structure, where user input now serves as keys and the corresponding values for input in other actions. Added a master script to run the extraction module — the project now works through imports rather than isolated scripts. Moved the internal mapping of balance sheet line items into an external JSON file, which now acts as a small, editable “library” for category assignments. Added a README to document structure, logic, and future steps. These changes make the program cleaner, easier to modify, and closer to something others could eventually extend. Next up, I’ll be looking into filtering redundant line items — Yahoo Finance sometimes returns duplicate data under slightly different names, so I’m exploring a systematic way to reconcile those. GitHub: https://lnkd.in/eCbgUhyx It’s been a great exercise in balancing code architecture and financial logic — small steps, but each one makes the system more coherent. Thanks to [Vansh Trivedi] for the earlier comment about modular structure — that’s exactly what inspired this refactor. #Python #Finance #DataAnalysis #FinancialModeling #GitHub #SoftwareDesign #FundamentalAnalysis

2

1 Comment

You don't need a semantic layer. Every vendor in the "modern data stack" keeps saying you do... but they're just wrong. The more you interact with AI agents and data, the more you realize semantic layers don't make sense. This is one of the best write-ups I've seen on the subject. Very few people actually understand this. It's abundantly clear that Ramp, Jay, Ian, and team are way ahead of the curve. https://lnkd.in/gQ_SQfiF

25

7 Comments

New blog post: https://lnkd.in/e4MX9EcX. Almost all data scientists and data engineers have to work with flat files (CSV files) from time to time. Despite their many problems, CSVs are too ubiquitous, too universal, and (whisper it) have too many strengths for them to be likely to disappear. Even if they did, they would quickly be reinvented. The problems with them are widely known and discussed, and will be familar to almost everyone who works with them. They include issues with encodings, types, quoting, nulls, headers, and with dates and times. My favourite summary of them remains Jesse Donat's Falsehoods Programmers Believe about CSVs (https://lnkd.in/eR6mfegW). I wrote about them on the blog nearly four years ago (https://lnkd.in/emiW3QVH). Over the last year or so I've been writing a book on test-driven data analysis (TDDA). The only remaining chapter without a full draft discusses the same topics as this post—metadata for CSV files and new parts of the TDDA software that assist with its creation and use. The post documents my current thinking, plans and ambitions in this area, and shows some of what is already implemented (bold in the image).  • Describe Flat File Formats.  • Read Flat Files.  • Convert metadata currently stored as tdda.serial to dictionaries of arguments for other libraries that work with CSVs.  • Provide an API to get such libraries to read flat-file data correctly, guided by the metadata  • Interoperate with and, where possible, support other metadata formats like CSVW and Frictionless.  • Generate tdda.serial Metadata Files.  • Write Flat Files.  • Assist/Support other Software Reading, Writing, and otherwise handling Flat Files (writing tdda.serial files and writing CSVs to formats specified by tdda.serial metadata.)  • Support Library-specific Read/Write Metadata.  • Assist with Format Choice.  • SERDE Verification.  • CLI Tools.  • Provide Metadata Format Conversions.  • Generate Validation Statistics and Validate using them. Expanded version at https://lnkd.in/e4MX9EcX. #TDDA #csv #flatfile #data #metadata #formats #serialization #serialdata

13

Collate, the creator of the leading open-source data intelligence project OpenMetadata, has raised $10M in a Series A funding round. Collate is solving the last-mile data challenges for modern data teams by providing an agentic data intelligence platform. The platform automates tasks and drives collaboration, completing the virtuous cycle with AI to enable data teams to deliver the data needed for AI-readiness. Its orchestrated suite of agentic workflows helps customers like Mango and Decisiv easily find, understand, and govern their data, increasing productivity and accelerating innovation. The funding was led by Venrock, with additional investment from Unusual Ventures and Karman Ventures. The funding will be used to accelerate Collate's AI-first mission for enterprises and support the continued growth of the OpenMetadata open-source community. Congratulations to co-founders Suresh Srinivas, Sriharsha Chintalapani, and the Collate team. Yahoo Finance: https://lnkd.in/ddtq3_jU. #DataIntelligence #OpenSource #AI #DataManagement #SeriesA #Funding #DataGovernance

22

1 Comment

📊 Research Drop → Can LLMs actually know what they know? Back in 2022, Anthropic released a paper investigating whether LLMs had some degree of understanding and awareness of their internal knowledge They asked the model if it could answer given questions correctly or not The model was largely able to predict its own performance But here's the interesting part: They gave the model multiple-choice questions and looked at the internal probability scores They found that the scores were calibrated to reality When the internal probabilities showed 80% confidence → the answers were correct 80% of the time Yes, 80% confidence means there's still a 20% chance it's wrong 🤯 Even more interesting: They generated multiple answers and showed them back to the model The model was clearly able to distinguish its own correct answers from its own incorrect ones That means the model has some degree of understanding of its internal knowledge. It can look at what it generated and go "yeah, that one's wrong." So the obvious solution: Next time you need a high-fidelity answer, just ask the model to give a confidence score, right? Well... not quite. What do you do to verify AI outputs? #AI #LLM #MachineLearning #AIResearch #Anthropic

6

Prompt caching saves 66% on average where it is available. The challenge: only 18.8% of tracked models offer cached input pricing. That means 81% of the inference market still charges full price every time you send the same system prompt. If your workloads have repetitive context, you should be filtering for vendors and models that support caching. a7om.com #AI #AIpricing #Inference #LLM #GenAI #A7OM

1

1 Comment

Great to be on Snap Crackle Pod with David Rice! A Turing Test for production ready AI systems? Most of us have seen businesses running AI proof of concepts. Now, the pressure is on to bring some of these AI concepts into production. To do that safely, it helps to borrow the idea behind the Turing Test, but shift the question from 'does it sound human?' to 'does it behave reliably in real world use?'. A simple production readiness checklist looks like this: 1. Build an evaluation set of real questions with the answers or actions you expect. 2. Stress test it with reworded questions, messy input, and edge cases, and make sure outputs stay consistent. 3. After go live, store and review interactions so you can spot drift early and keep performance where it needs to be. Tip: Always add guardrails and access controls to the tools your AI uses. What’s your approach? Comment below..

67

2 Comments

Very well written view and educational article on semantic layers and creating a universal standard. I agree with a lot of what was said and this aligns with my argument of dbt core becoming a standard for data transformation which I touched on in my fivetran merger article.

15

1 Comment

Recently, there has been a growing number of LinkedIn posts suggesting that autonomous AI can generate production-ready data pipelines without close human review. It may work in some environments, but I would tread very carefully before shipping AI-generated data pipelines without careful and thorough human review - at least in my domain of real estate data. I've been building real estate data systems since 2019 and using LLMs for data analysis since the early ChatGPT days. Long before the current agent wave, I even wrote about AI-assisted tabular data analysis back in 2023 when experimenting with tools that injected dataframe context directly into prompts. Since 2023, the progress on agentic AI for data analysis has been huge, but even the latest systems tend to quietly derail the analytical code by misinterpreting abbreviations. In real estate datasets alone you will see hundreds of abbreviations across deed types, vacancy identifiers, property classifications, ownership events. When this data hits an LLM context window, the model assigns the most statistically likely meaning and continues to "reason" with unshakeable confidence. As a result of this agentic work, the pipelines run, charts look perfectly convincing, the narrative makes sense at first glance. Meanwhile, a single misinterpreted abbreviation can quietly derail an entire analytical pipeline. There are workarounds: iterate, provide more context, get the subdivision dictionaries, build more scaffolding. But even with the strongest guardrails, autonomous agents struggle with domain semantics and edge cases. A transaction labeled "Vacant" might not actually be vacant at all depending on how a county encodes a transaction. Detecting this always requires domain judgment - not pattern completion. My current working belief is simple - in real estate data AI does not remove the need for data expertise, it does allow for a domain expert to produce more work, but also increases the amount of critical thinking required. To be clear, I let agents run the analysis every day now, and the productivity lift is measurable for me, I would not want to go back. But the idea that serious production analytics can operate safely without deep understanding of the underlying data... at least today, feels more aspirational than real. Fluent output is easy. Correct interpretation is the hard part.

8

2 Comments

"Your PDFs are smarter than you think — you just need the right pipeline to unlock them." I just built a fully local RAG (Retrieval-Augmented Generation) system from scratch — and it doesn't send a single byte to the cloud. Here's what it does in 3 steps: Step 1 — Ingest It reads any PDF — digital or scanned. For scanned pages, it auto-triggers OCR via Tesseract so nothing is missed. The text is then chunked with overlap so context never gets lost at boundaries. Step 2 — Embed Chunks are vectorized using Ollama embeddings (locally — no API key needed) and stored in ChromaDB with full persistence on disk. Each document gets its own sanitized collection. Step 3 — Retrieve + Answer Ask a question. The system retrieves the top-k most relevant chunks and passes them to a local LLM (TinyLlama / LLaMA 3.2) via LangChain's RetrievalQA chain — giving you a grounded answer with source citations. What makes this different? Most tutorials stop at the basics. This doesn’t. 1)Handles scanned PDFs seamlessly 2) Cleans messy collection names 3) Optimized for cold-start latency 4)Tuned context windows for better answers 5) Persistent storage — no reprocessing needed Tech Stack (100% Local. Zero Cloud.) Ollama ChromaDB LangChain Tesseract OCR pypdf This is the architecture I’d bet on for privacy-first enterprise AI. Imagine the possibilities: 1)Internal knowledge assistants 2)Legal/medical document Q&A 3)Offline AI for secure environments 4)Personal second brain (no data leaks) What would you build with the a offline RAG pipeline? Drop your ideas below 👇🏻 #RAG #LLM #GenerativeAI #MachineLearning #Python #LangChain #DocumentAnalysis #Ollama #AIEngineering #PrivacyFirst #OpenSource

14

1 Comment

Why do analytics agents all end up in the graveyard? 🪦 ✍️ Julien Hurault just joined our blog - and his first post explains exactly why. It starts the same way every time: a demo that works perfectly. You plug an LLM to your warehouse, it writes SQL, returns numbers. Magic. Then it falls apart. One edge case at a time. Until your "system prompt" is a 10,000 token document and your agent is slow, wrong, and expensive. 🐎 The fix is the harness, not more instructions. Go read it 👇 https://lnkd.in/ejrkig7n

58

5 Comments

A selection my top reads and listens from the last few weeks: ✸ 'Why I don't think AI is a bubble' by Matthew Honnibal. I appreciate the honesty and the very personal way of processing thoughts around reasoning models [https://lnkd.in/etVmJJw5] ✸ 'Building AI Products In The Probabilistic Era' by Gian Segato. A small function (F: X → Y) walks us through different components of a product, plus ideas on downstream data [https://lnkd.in/evZNQxEg] ✸ 'Labor market impacts of AI: A new measure and early evidence' by Anthropic. A classic of last week and perhaps already over-discussed on linkedin, nevertheless a must for my field (especially having spent years working on taxonomies, including O*NET) [https://lnkd.in/ewu39vs4] ✸ Anna Veronika Dorogush's talk at OpenTalks.AI on building models for creative professionals. It made me pause a sec to actually think about some differences between generating an image and generating a 'creative' image, but on the tech side of things (similar to when I heard for the first time the term ‘haute couture’ for fashion) Also, I haven't quite found the right place for this kind of post - X feels off, Bluesky perhaps not there yet for many tech people. Recommendations welcome :)

13

2 Comments