How to Apply Optimization Techniques in Practice

I've been building and deploying RAG systems for 2+ years. And it's taught me optimizing them requires focusing on 3 core stages: 1. Pre-Retrieval 2. Retrieval 3. Post-Retrieval Let me explain - Most people focus on the generation side of things. But optimizing retrieval is what really makes the difference. Here's how to do it: 𝟭/ 𝗣𝗿𝗲-𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 This is where we optimize the data before the retrieval process even begins. The goal? Structure your data for efficient indexing and ensure the query is as precise as possible before it's embedded and sent to your vector DB. Here’s how: - 𝗦𝗹𝗶𝗱𝗶𝗻𝗴 𝘄𝗶𝗻𝗱𝗼𝘄: 𝘐𝘯𝘵𝘳𝘰𝘥𝘶𝘤𝘦 𝘤𝘩𝘶𝘯𝘬 𝘰𝘷𝘦𝘳𝘭𝘢𝘱 𝘵𝘰 𝘳𝘦𝘵𝘢𝘪𝘯 𝘤𝘰𝘯𝘵𝘦𝘹𝘵 𝘢𝘯𝘥 𝘪𝘮𝘱𝘳𝘰𝘷𝘦 𝘳𝘦𝘵𝘳𝘪𝘦𝘷𝘢𝘭 𝘢𝘤𝘤𝘶𝘳𝘢𝘤𝘺. - 𝗘𝗻𝗵𝗮𝗻𝗰𝗶𝗻𝗴 𝗱𝗮𝘁𝗮 𝗴𝗿𝗮𝗻𝘂𝗹𝗮𝗿𝗶𝘁𝘆: 𝘊𝘭𝘦𝘢𝘯, 𝘷𝘦𝘳𝘪𝘧𝘺, 𝘢𝘯𝘥 𝘶𝘱𝘥𝘢𝘵𝘦 𝘥𝘢𝘵𝘢 𝘧𝘰𝘳 𝘴𝘩𝘢𝘳𝘱𝘦𝘳 𝘳𝘦𝘵𝘳𝘪𝘦𝘷𝘢𝘭. - 𝗠𝗲𝘁𝗮𝗱𝗮𝘁𝗮: 𝘜𝘴𝘦 𝘵𝘢𝘨𝘴 (𝘭𝘪𝘬𝘦 𝘥𝘢𝘵𝘦𝘴 𝘰𝘳 𝘦𝘹𝘵𝘦𝘳𝘯𝘢𝘭 𝘐𝘋𝘴) 𝘵𝘰 𝘪𝘮𝘱𝘳𝘰𝘷𝘦 𝘧𝘪𝘭𝘵𝘦𝘳𝘪𝘯𝘨. - 𝗦𝗺𝗮𝗹𝗹-𝘁𝗼-𝗯𝗶𝗴 (or parent) 𝗶𝗻𝗱𝗲𝘅𝗶𝗻𝗴: 𝘜𝘴𝘦 𝘴𝘮𝘢𝘭𝘭𝘦𝘳 𝘤𝘩𝘶𝘯𝘬𝘴 𝘧𝘰𝘳 𝘦𝘮𝘣𝘦𝘥𝘥𝘪𝘯𝘨 𝘢𝘯𝘥 𝘭𝘢𝘳𝘨𝘦𝘳 𝘤𝘰𝘯𝘵𝘦𝘹𝘵𝘴 𝘧𝘰𝘳 𝘵𝘩𝘦 𝘧𝘪𝘯𝘢𝘭 𝘢𝘯𝘴𝘸𝘦𝘳. - 𝗤𝘂𝗲𝗿𝘆 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻: 𝘛𝘦𝘤𝘩𝘯𝘪𝘲𝘶𝘦𝘴 𝘭𝘪𝘬𝘦 𝘲𝘶𝘦𝘳𝘺 𝘳𝘰𝘶𝘵𝘪𝘯𝘨, 𝘲𝘶𝘦𝘳𝘺 𝘳𝘦𝘸𝘳𝘪𝘵𝘪𝘯𝘨, 𝘢𝘯𝘥 𝘏𝘺𝘋𝘌 𝘤𝘢𝘯 𝘳𝘦𝘧𝘪𝘯𝘦 𝘵𝘩𝘦 𝘳𝘦𝘴𝘶𝘭𝘵𝘴. 𝟮/ 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 The magic happens here. Your goal is to improve the embedding models and leverage DB filters to retrieve the most relevant data based on semantic similarity. - Fine-tune your embedding models or use instructor models like instructor-xl for domain-specific terms. - Use hybrid search to blend vector and keyword search for more precise results. - Use GraphDBs or multi-hop techniques to capture relationships within your data. 𝟯. 𝗣𝗼𝘀𝘁-𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 At this stage, your task is to filter out noise and compress the final context before sending it to the LLM. - Use prompt compression techniques. - Filter out irrelevant chunks to avoid adding noise to the augmented prompt (e.g., using reranking) 𝗥𝗲𝗺𝗲𝗺𝗯𝗲𝗿: RAG optimization is an iterative process. Experiment with various techniques, measure their effectiveness, compare them and refine them. Ready to step up your RAG game? Check out the link in the comments.

One of the most fascinating projects I have worked on eventually became US Patent… a system for multi-modal journey optimization. At first glance, it sounds straightforward: get a traveler from point A to point B as quickly as possible. But in reality, this is not a “shortest path” problem. It is a problem of navigating combinatorial explosion under uncertainty while still producing results that humans will actually use. The lesson was simple, but profound: a single “optimal” route is often the wrong answer. In practice, commuters do not blindly follow whatever the algorithm declares “fastest.” They balance hidden costs (number of transfers, reliability, waiting time) against raw travel time. A route that is one minute slower but has one fewer transfer will often be preferred. We approached this by abandoning the idea of returning just one solution. Instead, we designed an iterative search that keeps a fixed-length priority queue of candidate paths, pruning aggressively to keep the search tractable, but always preserving multiple high-quality alternatives. The output is a set of Pareto-efficient options: fast, but also different enough that a user can choose the one that fits their risk tolerance, comfort level, or schedule flexibility. This project shifted how I think about optimization. The real challenge isn’t mathematical purity, it is making decisions robust to the messiness of the real world. If the solution space is reduced to a single “optimal” point, you risk oversimplifying reality and delivering something no one wants to use. When we expose the trade-offs explicitly, we help people make better decisions.

With a background in data engineering and business analysis, I’ve consistently seen the immense impact of optimized SQL code on improving the performance and efficiency of database operations. It indirectly contributes to cost savings by reducing resource consumption. Here are some techniques that have proven invaluable in my experience: 1. Index Large Tables: Indexing tables with large datasets (>1,000,000 rows) greatly speeds up searches and enhances query performance. However, be cautious of over-indexing, as excessive indexes can degrade write operations. 2. Select Specific Fields: Choosing specific fields instead of using SELECT * reduces the amount of data transferred and processed, which improves speed and efficiency. 3. Replace Subqueries with Joins: Using joins instead of subqueries in the WHERE clause can improve performance. 4. Use UNION ALL Instead of UNION: UNION ALL is preferable over UNION because it does not involve the overhead of sorting and removing duplicates. 5. Optimize with WHERE Instead of HAVING: Filtering data with WHERE clauses before aggregation operations reduces the workload and speeds up query processing. 6. Utilize INNER JOIN Instead of WHERE for Joins: INNER JOINs help the query optimizer make better execution decisions than complex WHERE conditions. 7. Minimize Use of OR in Joins: Avoiding the OR operator in joins enhances performance by simplifying the conditions and potentially reducing the dataset earlier in the execution process. 8. Use Views: Creating views instead of results that can be accessed faster than recalculating the views each time they are needed. 9. Minimize the Number of Subqueries: Reducing the number of subqueries in your SQL statements can significantly enhance performance by decreasing the complexity of the query execution plan and reducing overhead. 10. Implement Partitioning: Partitioning large tables can improve query performance and manageability by logically dividing them into discrete segments. This allows SQL queries to process only the relevant portions of data. #SQL #DataOptimization #DatabaseManagement #PerformanceTuning #DataEngineering

Design of Experiments (DOE) is deeply entrenched in some R&D labs, and dismissed as overkill in others. A new paper shows you can use it both flexibly and frugally. DOE is widely used in ingredient screening, formulation development, process optimization, and beyond. The toolkit ranges from screening designs that separate active factors from noise, to factorial designs that quantify interactions, to response surface methods that model nonlinear behavior near an optimum. Each flavor makes a mathematically explicit tradeoff between resolution and experimental cost, suited to a different stage of development. In practice, I have seen teams pick a design without matching it to the question: full factorial "just to be safe" when a screening design would suffice. Further, even when the design type is right, it can often be further adjusted based on domain knowledge, for example weighting factors unequally or pooling dimensions known to matter less. The result is wasted effort and sometimes less clarity rather than more. A recent paper captures several practical DOE examples in catalyst screening and cross-coupling optimization that showcase flexible, frugal design shaped by both chemistry and instrumentation constraints. The authors reduced experiments by 75% compared to full factorial and still identified the most promising catalytic systems and conditions. Four lessons reinforced by this work: 🔹Start by ranking your variables: which factors drive outcomes, which interact, and which are secondary. That ranking is a bet. Making it explicit lets you invest experimental budget where it matters most and accept reduced coverage where a directional trend is sufficient. 🔹Match the design to that ranking. Some designs provide uniform coverage across all dimensions, ideal when factors are equally unknown. Others let you cut runs selectively on lower-impact dimensions. The right choice depends on what you must know precisely versus where a general trend is enough. 🔹Think in stages, not one big design. A preliminary screen does not need to find the optimum. It needs to eliminate dead ends and surface promising directions. Save the higher-resolution designs for the follow-up. It is being strategic to match the resolution and objective to each stage. 🔹Look beyond classical DOE when the problem calls for it. Approaches like Bayesian Optimization (BO) operate under different assumptions and yield different information. Understanding when each fits, and when to combine them, can unlock insights that no single method delivers alone. Check out the detailed use cases in the paper (including the integration of DOE and BO for cost-aware discovery), and see how you might adapt them to your own designs. 📄 Frugal Sampling Strategies for Navigating Complex Reaction Spaces, Organic Process Research & Development, April 10, 2026 🔗 https://lnkd.in/eQZjvzvc

Most CPU bottlenecks I’ve solved can be boiled down to 4 strategies. Learn in (more than) one minute: We execute code using functions, each taking time to run. Functions may be called multiple times per frame and on many threads. There is also a GPU - ideal for massively parallel work, yet it communicates less efficiently with the CPU. With this overview in mind, I divide the optimization into four different strategies: 1. Optimize the function itself ✔️ use faster algorithm, better data structures, lower complexity ✔️ improve cache hit rate, ✔️ lower memory bandwidth use (RAM, PCI-e, SSD, Internet) ✔️ look up pre-baked data 2. Don't execute it so many times. Even a fast function is slow when called thousands of times. ✔️ Cache the results, ✔️ Schedule over multiple frames, ✔️ Update only what's needed (ex., Use distance for culling game logic) 3. Use other threads ✔️ Delegate some workload to the worker threads ✔️ Start to execute as soon as input data is ready, wait to finish just before output is used ✔️ Design a solution that avoids synchronization stalls 4. Delegate to GPU ✔️ Highly parallel problems can be solved in a compute shader ✔️ Use GPU to prepare data that stays on the GPU (ex., Culling, instancing, particle simulation, mesh deformation) ✔️ Avoid GPU readbacks, or at least, hide the latency Could any of that be useful in your project? Share it with your team! 🫵

In the world of Data Engineering & Analytics, SQL is everywhere — from pipelines to dashboards to ad-hoc analysis. But here’s the truth: a poorly optimized SQL query can kill performance, inflate costs, and delay insights. Over the years, I’ve seen teams struggle with queries that take minutes instead of seconds (sometimes hours instead of minutes). The difference usually comes down to query optimization. Here are some proven SQL Optimization strategies every engineer should know ⬇️ 1. Select Only What You Need ❌ SELECT * → Loads unnecessary data, increases I/O. ✅ Select only required columns to minimize processing. 2. Use Proper Indexing ↳ Index frequently filtered columns (WHERE, JOIN, GROUP BY). ↳ Avoid over-indexing (it slows down INSERT/UPDATE). ↳ Leverage covering indexes for heavy queries. 3. Optimize Joins ↳ Ensure JOIN keys are indexed. ↳ Prefer INNER JOINs when possible over OUTER JOINs. ↳ Push filters down before joins to reduce data scanned. 4. Reduce Data Scans ↳ Use PARTITIONING on large tables (date, region, etc.). ↳ Use CBO (Cost-Based Optimizer) hints when available. ↳ Apply filter conditions early. 5. Avoid Complex Subqueries ↳ Replace correlated subqueries with JOINs or CTEs. ↳ Use window functions efficiently instead of multiple nested queries. 6. Monitor & Tune ↳ Always check execution plans. ↳ Look for table scans, sort operations, and large shuffles. ↳ Track query runtime and cost metrics, especially in cloud warehouses like Snowflake, BigQuery, Synapse. ✅ Impact of Optimization: I’ve seen query runtimes drop from 45 minutes to 2 minutes just by applying indexing and partition pruning. That’s not just performance — it’s cost savings, better SLAs, and happier stakeholders. 📌 𝗙𝗼𝗿 𝗠𝗲𝗻𝘁𝗼𝗿𝘀𝗵𝗶𝗽 - https://lnkd.in/gYn8Q39u 📌 𝗙𝗼𝗿 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗣𝗿𝗲𝗽𝗮𝗿𝗮𝘁𝗶𝗼𝗻 - https://lnkd.in/g26SjZV2 📌 𝗙𝗼𝗿 𝗖𝗮𝗿𝗲𝗲𝗿 𝗚𝘂𝗶𝗱𝗮𝗻𝗰𝗲 - https://lnkd.in/gfrPMQSj 📌𝐅𝐨𝐥𝐥𝐨𝐰 𝐦𝐲 𝐌𝐞𝐝𝐢𝐮𝐦 𝐇𝐚𝐧𝐝𝐥𝐞 𝐭𝐨 𝐬𝐭𝐚𝐲 𝐮𝐩𝐝𝐚𝐭𝐞𝐝 - https://lnkd.in/dHhPyud2 📌 𝗝𝗼𝗶𝗻 𝗠𝘆 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆 - https://lnkd.in/d3F93Y5u Riya Khandelwal

You hear the term “hyperparameter” all the time in machine learning. But do you really know what it means—and why it matters? Let’s break it down. 1/ What is a hyperparameter? It’s a setting you define before training a model. Not learned from the data—set by you. It controls how the model learns. 2/ Examples: k in k-NN (number of neighbors) k in k-means (number of clusters) Depth of a decision tree min_impurity_decrease (minimum improvement for a split) mtry in random forests (number of features to consider at each split) 3/ Why are they called hyperparameters? Because they control the learning process—not the outcome. They’re “meta” to the model. You don’t learn them within the model. You set them around the model. 4/ The model is a bike. Parameters = how you balance & steer (learned as you ride). like weights in a neural network. Hyperparameters = seat height (set before). 5/ So how do you pick good hyperparameters? You don’t just guess. You tune them. Try a few combinations. Evaluate performance. Choose the best one. That’s called hyperparameter optimization. 6/ Two popular strategies: Grid Search: Try every combo from a predefined list Random Search: Try random combos from the hyperparameter space You need to evaluate each combo on performance. But beware... 7/ Overfitting alert: The more combos you try, the more likely you’ll get a false “best.” It’s like p-hacking for your model. You might find the best combo for this dataset... But it fails on new data. 8/ To avoid this, we use cross-validation. Use k-fold cross-validation: split the data into k parts, train on k-1, validate on the rest, and repeat. Then pick the hyperparameters that perform best on average. Still not perfect—but it helps. 9/ Let’s go deeper on mtry in random forests. Say you have 100 features. mtry = number of features considered at each split. Smaller mtry → more randomness → decorrelated trees Larger mtry → less randomness → trees may look similar Balance is key. 10/ And k in k-means? People use the elbow plot to find the “ideal” number of clusters. But it’s often subjective. Sometimes the “elbow” is barely an elbow. This is where science meets art. 11/ Action steps: Learn what hyperparameters your model uses Don’t rely on defaults blindly Use cross-validation to tune Be cautious of overfitting when doing grid search You’re not just training a model. You’re tuning its personality. 12/ In bioinformatics, machine learning is powerful. But don’t just throw models at data. Understand the knobs. Understand the data. And never trust performance on training data alone. Remember: they don’t know your biology or your question. You do. I hope you've found this post helpful. Follow me for more. Subscribe to my FREE newsletter chatomics to learn bioinformatics https://lnkd.in/erw83Svn

Mastering Spark Optimization: A Data Engineer’s Edge Working with Apache Spark is powerful — but without the right optimizations, even the best clusters can struggle. Over the years, I’ve realized that Spark optimization is not just about cutting costs, but about unlocking real performance and scalability. Here are some key Spark optimization techniques every data engineer should keep in their toolkit: 🔹 1. Optimize Data Formats Use columnar formats like Parquet or ORC instead of CSV/JSON. They reduce storage size and speed up queries significantly. 🔹 2. Partitioning & Bucketing Partition data wisely on frequently used keys. Use bucketing for joins on large datasets to avoid costly shuffles. 🔹 3. Caching & Persistence Cache intermediate results when reused across stages, but be mindful of memory overhead. 🔹 4. Broadcast Joins For small lookup tables, use broadcast joins to avoid shuffle-heavy operations. 🔹 5. Shuffle Optimization Minimize wide transformations. Use reduceByKey instead of groupByKey to cut down on shuffle size. 🔹 6. Adaptive Query Execution (AQE) Enable AQE in Spark 3+ to dynamically optimize joins and shuffle partitions at runtime. 🔹 7. Resource Tuning Right-size executors, cores, and memory. More is not always better — balance matters. 🔹 8. Avoid UDF Overuse Use Spark SQL functions where possible. Built-in functions are optimized at the Catalyst level, while UDFs can be a performance bottleneck. ✨ The real game-changer: Optimization is not one-size-fits-all. Profiling your jobs and understanding data characteristics is the key. 👉 What’s your go-to Spark optimization technique that saved you the most time (or cost)? #ApacheSpark #DataEngineering #BigData #Optimization #PerformanceTuning

𝗛𝗼𝘄 𝘁𝗼 𝗔𝗽𝗽𝗹𝘆 𝗤𝘂𝗮𝗻𝘁𝘂𝗺-𝗜𝗻𝘀𝗽𝗶𝗿𝗲𝗱 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺𝘀 𝘁𝗼 𝗗𝗮𝘁𝗮 𝗖𝗲𝗻𝘁𝗲𝗿 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 (𝗔𝗜𝗢𝗽𝘀 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗮 𝗤𝘂𝗮𝗻𝘁𝘂𝗺 𝗖𝗼𝗺𝗽𝘂𝘁𝗲𝗿) Most leaders hear “quantum” and think of it as experimental, expensive, and years away. That’s a mistake. Quantum-inspired algorithms run on classical infrastructure today and solve the hardest problem you actually have: large-scale optimization under constraints. If you run data centers, this is immediately actionable. What they actually do They convert your environment into an energy minimization problem. Instead of brute forcing every possibility, they rapidly converge on high-quality solutions across massive decision spaces. Think: • Placement • Scheduling • Routing • Thermal balancing • Power allocation Where to apply first (high ROI use cases) 1. Rack and cluster placement Model racks, power domains, cooling zones, and network topology as constraints. Objective: minimize latency + cable length + thermal hotspots. 2. GPU scheduling and utilization: Encode job priority, SLA windows, GPU affinity, and network contention. Objective: maximize utilization while reducing idle burn and queue latency. 3. Thermal + power balancing: Integrate cooling capacity, airflow constraints, and power density. Objective: flatten hotspots without over-provisioning. 4. Network traffic shaping Model east-west traffic flows and oversubscription ratios. Objective: Reduce congestion and packet loss under peak load. How to implement (practical workflow) Step 1: Define variables • Binary: placement decisions, routing paths • Continuous: load, temperature, power draw Step 2: Define constraints • Power caps per rack and row • Cooling limits by zone • Network bandwidth ceilings • SLA requirements Step 3: Build the objective function. Combine into a weighted cost function: • Latency • Energy consumption • Thermal deviation • Resource fragmentation Step 4: Select a solver. Use simulated annealing or related heuristics to explore the solution space efficiently. Step 5: Iterate with real telemetry. Feed in live data: • DCIM • BMS • Scheduler metrics: Continuously refine the model. What “good” looks like • 10–25% improvement in GPU utilization • Lower east-west congestion without network upgrades • Reduced thermal excursions • Faster schedule generation cycles Where most teams fail • Overfitting the model before validating its impact • Ignoring real-time telemetry • Treating this as a one-time optimization instead of a continuous system Bottom line: You don’t need quantum hardware to get quantum-level thinking. You need a structured optimization model and the discipline to iterate it against real operating data. If you’re running >10MW environments and not doing this, you’re leaving efficiency and margin on the table. #DataCenters #AIInfrastructure #GPU #Optimization #HighPerformanceComputing #Cloud #Infrastructure #DigitalTransformation

📊 𝗧𝗼𝗽 𝗣𝗼𝗿𝘁𝗳𝗼𝗹𝗶𝗼 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗧𝗲𝗰𝗵𝗻𝗶𝗾𝘂𝗲𝘀 𝗘𝘃𝗲𝗿𝘆 𝗤𝘂𝗮𝗻𝘁 𝗦𝗵𝗼𝘂𝗹𝗱 𝗞𝗻𝗼𝘄  When I first stepped into quant finance, I realised: 👉 Picking assets is important. 👉 But constructing a portfolio that balances risk & return? It is equally important. Portfolio optimisation is where math meets markets, turning uncertainty into structured allocations. 𝗛𝗲𝗿𝗲 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹𝘀 𝘆𝗼𝘂 𝗺𝘂𝘀𝘁 𝗸𝗻𝗼𝘄 (𝗮𝗻𝗱 𝗵𝗼𝘄 𝘁𝗵𝗲𝘆 𝗮𝗿𝗿𝗶𝘃𝗲 𝗮𝘁 𝗳𝗶𝗻𝗮𝗹 𝘄𝗲𝗶𝗴𝗵𝘁𝘀) 👇 𝟭. 𝗠𝗲𝗮𝗻-𝗩𝗮𝗿𝗶𝗮𝗻𝗰𝗲 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 (𝗠𝗮𝗿𝗸𝗼𝘄𝗶𝘁𝘇)  • Classical Modern Portfolio Theory.  • Balances expected return vs variance.  • Weights chosen to maximise return for a given level of risk. 𝟮. 𝗕𝗹𝗮𝗰𝗸-𝗟𝗶𝘁𝘁𝗲𝗿𝗺𝗮𝗻 𝗠𝗼𝗱𝗲𝗹  • Blends equilibrium market portfolio with investor views.  • Avoids extreme/unrealistic weights from MVO.  • Final weights = equilibrium + adjusted views. 𝟯. 𝗠𝗶𝗻𝗶𝗺𝘂𝗺 𝗩𝗮𝗿𝗶𝗮𝗻𝗰𝗲 𝗣𝗼𝗿𝘁𝗳𝗼𝗹𝗶𝗼 (𝗠𝗩𝗣)  • Ignores return forecasts, minimizes volatility only.  • Popular in risk-sensitive mandates.  • Weights tilt toward low-volatility assets. 𝟰. 𝗥𝗶𝘀𝗸 𝗣𝗮𝗿𝗶𝘁𝘆 & 𝗘𝗾𝘂𝗮𝗹 𝗥𝗶𝘀𝗸 𝗖𝗼𝗻𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻 (𝗘𝗥𝗖)  • Allocates based on risk contribution, not dollar amounts.  • Risk Parity → equalizes volatility contributions.  • ERC → ensures balanced marginal risk. 𝟱. 𝗙𝗮𝗰𝘁𝗼𝗿-𝗕𝗮𝘀𝗲𝗱 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻  • Allocates across style factors: value, momentum, quality, low-vol.  • Weights optimized for factor exposure rather than securities.  • Core of smart beta ETFs. 𝟲. 𝗠𝗮𝗰𝗵𝗶𝗻𝗲 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 / 𝗔𝗜 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵𝗲𝘀  • Genetic algorithms, reinforcement learning, Bayesian optimization.  • Learn optimal weights dynamically.  • Increasingly common in systematic hedge funds. 𝟳. 𝗖𝗩𝗮𝗥 (𝗖𝗼𝗻𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 𝗩𝗮𝗹𝘂𝗲-𝗮𝘁-𝗥𝗶𝘀𝗸) 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻  • Minimises extreme tail losses.  • Looks beyond VaR → focuses on worst-case scenarios.  • Final weights skew conservative under fat tails. 𝟴. 𝗥𝗼𝗯𝘂𝘀𝘁 & 𝗥𝗲𝘀𝗮𝗺𝗽𝗹𝗲𝗱 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆  • Handles input uncertainty in returns/covariances.  • Michaud’s resampling → Monte Carlo to stabilise weights.  • Prevents fragile allocations. 💡 𝗞𝗲𝘆 𝗜𝗻𝘀𝗶𝗴𝗵𝘁: There is no “one best” model. Each optimisation method reflects your 𝗽𝗵𝗶𝗹𝗼𝘀𝗼𝗽𝗵𝘆 𝗼𝗳 𝗿𝗶𝘀𝗸 & 𝗿𝗲𝘁𝘂𝗿𝗻. As a quant, you’re not just investing, you’re engineering a risk engine. 🔁 Save this for your quant prep. 💬 Comment: Which optimisation technique do you rely on (or struggle with)? 📌 Follow Puneet Khandelwal for more insights on Quant, ML, and Finance. #QuantFinance #PortfolioOptimization #Investing #RiskManagement #MachineLearning #FinanceCareers #Quant