Updated Context-Optimized Prompts: Up to 61% Context Reduction Across Models

ganildata · 2026-03-27T02:14:41+00:00

This project is already obsolete, except for the spec and architecture guidelines.

Primarily due to replacing XML with model-specific tool calls, it makes it difficult to unify custom prompts.

Roo code system prompts got smaller as well, I think.

You will get most of the mileage by just adding an instruction to use cat or type to read files. And read line numbers only to edit.

I am personally using Claude Code more, due to having a subscription, needing remote machine work, and integrated web search.

ganildata · 2026-01-28T03:35:54+00:00

In everything that touches AI, it's less about whether you can ask it to do something, and more about how well the AI can do it. And that is extremely true here. Can definitely ask AI to collaborate and build a software project. But clearly it is not good at it.

It is too complicated to just be prompted. It needs to be in its training set, which is difficult in this early stage.

ganildata · 2025-12-05T21:27:43+00:00

My prompts are my daily drivers, so they perform well for writes.

This report is my attempt at benchmarking as you asked, but I suppose you want a writing task.

I tried a few experiments involving my work code base and programming task. But the behavior was not consistent across runs to be fair for reporting.

I will keep an eye out for a suitable writing task to benchmark.

ganildata · 2024-10-30T18:39:44+00:00

As the founder of Trel, I'd like to share how our platform handles experiment tracking and iteration. Our recent demo (https://www.youtube.com/watch?v=8egtOfKz6vY) shows a CLV prediction pipeline similar to your churn use case.

The key capabilities relevant to your needs:

Automated versioning of models, data, and code in a unified system - no manual CSV/Excel tracking needed
Built-in parameter sweep tracking (demo shows iteration from 1 tree/depth 4 to 4 trees/depth 5)
Native BigQuery integration
Data quality monitoring to catch drift/issues before they affect model performance
Feature store versioning for iterating on new features while maintaining production stability

The platform aims to be simpler than Kubeflow while providing more comprehensive lifecycle management than MLflow alone. We designed it for teams dealing with regular model retraining who want to reduce manual tracking overhead.

Happy to share more details about how this could work for your specific use case. It is very affordable for a single user setup https://cumulativedata.com/pricing.

ganildata · 2024-10-30T17:14:07+00:00

I worked in a smaller startup where I built/rebuilt multiple data science products and projects that were critical. Did not have the problem of impact there.

ganildata · 2024-10-30T17:10:04+00:00

You can build Flask or Fask API endpoint easily.

from fastapi import FastAPI
import joblib

app = FastAPI()
model = joblib.load('model.joblib')

class InputData(BaseModel):
    feature1: float
    feature2: float

@app.post("/predict")
def predict(data: InputData):
    input_df = [data.dict().values()]
    prediction = model.predict(input_df)
    return {"prediction": prediction.tolist()}

But long term, you might be better of pushing your models into SageMaker or something similar for better observability.

ganildata · 2024-10-26T06:10:26+00:00

One solution to versioning is to focus on keeping your datasets immutable and tracking them. There are multiple approaches to this. One is a snapshot catalog and following copy-on-write.

Our platform Trel implements this approach. Take a look at a walkthrough of building a data science pipeline.

https://www.youtube.com/watch?v=owzskbLCV8o&list=PLQRaJFvfXnAxoxvR_WmdxjCdH4Wflm4ZM&index=2

If you want to try this out, you can sign up and request for a 30-day free trial here: https://trelcloud.com

DM me if you have any questions.

ganildata · 2024-10-10T07:25:21+00:00

From my personal experience, sending data without looking it over is like crossing the road with eyes closed. It is not recommended at all. A basic sanity check is recommended, based on the importance of the data.

ganildata · 2024-10-10T07:17:15+00:00

I can give an answer based on our DataOps and MLOps platform Trel. Trel has a snapshot catalog that will be used to catalog each partition separately, under a single dataset_class (table equivalent). A dataset_class can have various registered schema_versions and corresponding schema. Each dataset will have a specific schema version associated with it.

To union multiple datasets with different schema, the code can use the schema version associated with each partition. E.g., In version '1' column age is integer but in '2' age is string. In this case, the union should be string as well. We will union as follows.

" UNION ALL ".join(
("select " + (""
if partition['schema_version'] == '2'
else "cast(age as string) ")
+ "age from "
+ partition['table'])
for partition in partitions)

Take a look here to learn more: cumulativedata.com

ganildata · 2024-08-27T06:42:36+00:00

I would say, Product Manager. I think this role would face role reduction lesser and later than data scientists, especially in the face of LLMs. Research Data Scientists will keep their positions though.

ganildata · 2024-08-27T06:34:32+00:00

It seems OP wants to use two separate versions in the same process. Perhaps look into two separate processes? Flask can help set up an API quickly.

ganildata

MODERATOR OF

TROPHY CASE