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)

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.
Automatic checks. Word-count band, presence of headings, a readability score (e.g. Flesch), topic-keyword coverage, and near-duplicate detection across posts.
Groundedness check. Where source material exists, verify that the blog's claims are supported by it.
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).