Abhisingh-18/Prognos

All four questions have been completed. The top three scores will be considered.

Files in this submission

File	Question	Description
Q1_Q2_conceptual_answers.md	Q1, Q2	Appointment-scheduling chatbot (challenges, evaluations, hallucination handling) and the full RAG FAQ-chatbot design with RAG / Advanced RAG / GraphRAG comparison.
Q3_langgraph_blog_agent.py	Q3	LangGraph agent that reads topics from Excel, writes a blog per topic, saves each to a Google Doc, and writes the link back to the sheet. Runs as a self-contained simulation; the real LangGraph, Google Docs, and Sheets calls are provided as commented implementations behind clean function boundaries.
Q4_surge_prediction.py	Q4	End-to-end demand-surge predictor. Generates synthetic data matching all five input schemas, builds the leakage-safe surge_flag label, engineers features (sales trend, stock pressure, disaster proximity, store/SKU metadata), trains a gradient-boosted classifier, and reports the appropriate metrics.

How to run the code

python Q3_langgraph_blog_agent.py     # prints the per-topic processing loop
python Q4_surge_prediction.py         # trains the model and prints metrics

Q4 requires pandas, numpy, and scikit-learn.

Q3 — evaluating blog quality at scale (without reading each one manually)

1. LLM-as-judge with a fixed rubric. Each blog is scored (1–5) on topic relevance, structure, factual grounding, and readability via a separate model call. Anything below a set threshold is flagged for human review.
2. Automatic checks. Word-count band, presence of headings, a readability score (e.g. Flesch), topic-keyword coverage, and near-duplicate detection across posts.
3. Groundedness check. Where source material exists, verify that the blog's claims are supported by it.
4. Sampled human audit. A random 5–10% is read by a person to calibrate and validate the automated judge.

Q4 — key modelling decisions

• Time-based split, not random, because this is a forecasting problem — the model trains on earlier dates and is tested on later ones.
• PR-AUC is reported alongside ROC-AUC, because surges are rare (around 4% of rows) and plain accuracy would be misleading.
• No data leakage: all features use information available up to the prediction date, while the label is computed from the following seven days. The final incomplete window per series is dropped.
• Threshold tuning is left to the retailer's cost trade-off: a missed surge (a stockout during a disaster) is far more costly than over-stocking, so the operating point should favour recall on the positive class.

Assumptions

Each code file documents its own assumptions in a header comment. The main ones: the Excel sheet uses the columns shown in the prompt and rows already containing a blog link are skipped (Q3); the seven-day surge horizon is made explicit as demand_next_7_days > 1.5 × 7 × daily_baseline (Q4); and the disaster feed is joined to stores by haversine distance and alert recency (Q4).