From 8792ea068f0d79897682516ae74713176af8e33b Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:13:06 -0500 Subject: [PATCH 01/16] supporting blog content local-rag-with-lightweight-elasticsearch --- .../Dataset/meeting_QA-team_wednesday.txt | 3 + .../meeting_development-team_monday.txt | 3 + .../meeting_management-sync_friday.txt | 4 + .../Dataset/report_QA-team.txt | 0 .../Dataset/report_development-team.txt | 1 + .../script.py | 100 ++++++++++++++++++ 6 files changed, 111 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt new file mode 100644 index 000000000..1550401d0 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt @@ -0,0 +1,3 @@ +• Maria: “Data imports are failing when addresses contain special characters.” +• Tom: “That matches what we saw last week. We need a parser fix.” +• Maria: “Agreed, let’s log this as a blocker.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt new file mode 100644 index 000000000..86aa66d0c --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt @@ -0,0 +1,3 @@ +• Alice: “The API is working, but response times are too slow with more than 1,000 queries.” +• John: “We may need to add caching or optimize indexes.” +• Alice: “Let’s prioritize this for the next sprint.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt new file mode 100644 index 000000000..810e76af2 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt @@ -0,0 +1,4 @@ +• Manager: “Are we on track for the migration deadline next month?” +• Alice: “Development is slightly behind due to performance issues.” +• Maria: “QA also found blockers with data imports.” +• Manager: “Okay, let’s adjust the timeline by two weeks to ensure quality.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt new file mode 100644 index 000000000..e69de29bb diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt new file mode 100644 index 000000000..5670f6d65 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt @@ -0,0 +1 @@ +The migration to the new CRM is progressing. We finished setting up the database schema and implemented the first batch of API integrations. The main issue is performance under heavy load, especially with customer search. We estimate two more sprints to stabilize. \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py new file mode 100644 index 000000000..044ec4eba --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -0,0 +1,100 @@ +import os +import time + +import requests +from elasticsearch import Elasticsearch + +ES_URL = "http://localhost:9200" +ES_API_KEY = "your-api-key-here" +INDEX_NAME = "team-data" +OLLAMA_URL = "http://localhost:11434/api/generate" +DATASET_FOLDER = "./Dataset" + + +es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) + + +def index_documents(): + docs_count = 0 + for filename in os.listdir(DATASET_FOLDER): + if filename.endswith(".txt"): + filepath = os.path.join(DATASET_FOLDER, filename) + + with open(filepath, "r", encoding="utf-8") as file: + content = file.read() + + doc = { + "file_title": filename, + "file_content": content, + "semantic_field": f"{filename} {content}", + } + + start_time = time.time() + es_client.index(index=INDEX_NAME, document=doc) + index_latency = (time.time() - start_time) * 1000 # ms + + docs_count += 1 + print(f"✓ {filename} | Latency: {index_latency:.0f}ms") + + return docs_count + + +def semantic_search(query, size=3): + start_time = time.time() + search_body = { + "query": {"semantic": {"field": "semantic_field", "query": query}}, + "size": size, + } + + response = es_client.search(index=INDEX_NAME, body=search_body) + + search_latency = (time.time() - start_time) * 1000 # ms + print( + f"🔍 Search completed in {search_latency:.0f}ms" + ) # Print for monitoring purposes + + return response["hits"]["hits"], search_latency + + +def query_ollama(prompt, model="qwen3:4b"): + start_time = time.time() + data = {"model": model, "prompt": prompt, "stream": False} + + response = requests.post(OLLAMA_URL, json=data) + + ollama_latency = (time.time() - start_time) * 1000 # ms + + if response.status_code == 200: + print( + f"🤖 Ollama answered in {ollama_latency:.0f}ms" + ) # Print for monitoring purposes + return response.json()["response"], ollama_latency + else: + return f"Error: {response.status_code}", ollama_latency + + +if __name__ == "__main__": + print("📥 Indexing documents...") + docs_count = index_documents() + + query = "performance issues in the API" + + print(f"\n🔍 Search: '{query}'") + search_results, search_latency = semantic_search(query) + + context = "Information found:\n" + for hit in search_results: + source = hit["_source"] + context += f"File: {source['file_title']}\n" + context += f"Content: {source['file_content']}\n\n" + + prompt = f"{context}\nQuestion: {query}\nAnswer:" + + print("🤖 Asking to model...") + response, ollama_latency = query_ollama(prompt) + + print(f"\n💡 Question: {query}\n📝 Answer: {response}") + + print(f"\n🔍 Search Latency: {search_latency:.0f}ms") + print(f"🤖 Ollama Latency: {ollama_latency:.0f}ms") + print(f"📄 Documents Indexed: {docs_count}") From 3b152381a75d68c24a481cf043d1944e387dcada Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:20:48 -0500 Subject: [PATCH 02/16] app logs --- .../app-logs/results.md | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md new file mode 100644 index 000000000..fdcad0dc0 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -0,0 +1,82 @@ +## 📥 Indexing documents... + +✓ meeting_management-sync_friday.txt | Latency: 64ms + +✓ report_development-team.txt | Latency: 17ms + +✓ meeting_development-team_monday.txt | Latency: 10ms + +✓ report_QA-team.txt | Latency: 9ms + +✓ meeting_QA-team_wednesday.txt | Latency: 9ms + +🔍 Search: 'performance issues in the API' + +🔍 Búsqueda completada en 5ms + +🤖 Asking to model... + +🤖 Ollama answered in 29432ms + +## 💡 Question: performance issues in the API + +### 📝 Answer: + + +Okay, the user is asking about performance issues in an API. Let me start by understanding what they need. They might be a developer or a tech lead dealing with slow API responses. First, I should figure out the common causes of API performance problems. + +Hmm, the user didn't provide specific details about their API. So I need to cover the main areas without assuming too much. Let me list out the typical issues: database queries, network latency, code inefficiencies, caching, rate limiting, external dependencies, etc. + +Wait, the user mentioned "performance issues in the API" but didn't specify if it's their own API or a third-party one. I should clarify that. But since the answer section is empty, maybe they want a general guide. + +I recall that common causes include slow database queries, especially if they're not optimized. Maybe they have N+1 queries? Or improper indexing. Also, heavy processing in the backend could be a problem. Like, if the API is doing a lot of computations per request. + +Network issues might be another angle. If the API is hosted on a different server, latency could be high. Or maybe the user is facing timeouts. + +Caching is important too. If the API isn't caching responses, every request goes to the backend. But if they have caching in place and it's not working right, that could cause slowness. + +External dependencies—like calling another API that's slow. That's a common pitfall. Also, rate limiting might be causing delays if the API is hit too hard. + +Wait, the user might need actionable steps. So I should structure the answer into sections: common causes, diagnostic steps, solutions. But the answer is supposed to be short since it's a fill-in. The user's instruction says "Answer:" so they want a concise answer. + +Looking back at the information provided, there's no specific data. So the answer should be a general response. Maybe the user expects a list of possible causes? Like in the answer field. + +Wait, the problem says "Information found:" followed by the question and answer. But the answer is empty. So the task is to generate the answer based on typical knowledge. + +I think the best approach is to list the main causes without being too technical. Let me check standard API performance issues. + +Top causes: +1. Slow database queries (e.g., missing indexes, complex joins) +2. Inefficient code (e.g., unnecessary loops, heavy computations) +3. Lack of caching +4. High network latency +5. External service dependencies +6. Rate limiting or too many requests +7. Inadequate server resources (CPU, memory) + +Also, maybe the API is not using asynchronous processing for long tasks. Or the response size is too big, causing slow transfers. + +The user might be looking for a quick reference. So I'll structure the answer as a bullet list of key points. But since it's an answer field, maybe a concise paragraph. + +Wait, the user's instruction says "Answer:" so I need to fill that part. Let me draft a response. + +"Common causes include slow database queries, inefficient code logic, lack of caching, high network latency, external dependencies, and insufficient server resources. Diagnose using tools like API monitoring, profiling, and logs." + +But maybe they want more specific. Alternatively, if this is for a specific scenario, but the user didn't specify. Hmm. + +Another angle: sometimes performance issues are due to the API design itself, like REST vs. GraphQL, but that's probably too specific. + +I think the safest answer is to list the main points briefly. Let me check similar problems online. For example, common API performance issues are often related to database, code, caching. + +Okay, I'll go with that. + + +## Final Answer: + +Common causes include slow database queries (e.g., missing indexes, N+1 queries), inefficient code logic (e.g., excessive computations, redundant operations), lack of caching, high network latency, external dependency delays, rate limiting, and insufficient server resources (CPU/memory). Diagnose using profiling tools, API monitoring, and log analysis to identify bottlenecks. + +## App performance metrics: + +🔍 Search Latency: 5ms +🤖 Ollama Latency: 29432ms +📄 Documents Indexed: 5 \ No newline at end of file From 40d7e6a7335694f84568f9d84c1656a674d10434 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:24:46 -0500 Subject: [PATCH 03/16] app-logs --- .../app-logs/why-elasticsearch-is-so-cool.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md new file mode 100644 index 000000000..d1582b294 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md @@ -0,0 +1,62 @@ +>>> Why Elastic is so cool? + +That's a **great question**, but there's a **critical clarification first**: **"Elastic" alone isn't a product** — it's almost always a shorthand for **Elasticsearch** (the core search +engine) and the **Elastic Stack** (Elasticsearch + Kibana + Logstash + Beats). + +**Why people say "Elastic is so cool" (and why it's actually *Elasticsearch* that's the star):** + +1. **Real-Time Search & Analytics (The "Cool" Part!)** + Elasticsearch doesn't just *search* — it **indexes, searches, and analyzes data in real time** (millions of events/sec). Unlike traditional databases (which need slow queries or +batch processing), it gives you instant answers. + *Example:* Netflix uses it to show personalized movie recommendations *as you browse* — not after you click "Next" or "Save." + +2. **Handles "Wild" Data (Unstructured + Structured)** + Most data today is messy (text, logs, images, JSON, CSV). Elasticsearch **natively understands** this. + *Example:* A company can search *both* "user feedback in Slack messages" *and* "product prices from a spreadsheet" in one query. + +3. **Scalability That Doesn’t Break** + It’s built to scale **horizontally** (add more servers) without downtime. Handles **petabytes** of data. + *Example:* Airbnb uses it to power their 10M+ listing search across 200+ countries — *without* slowing down. + +4. **The Elastic Stack = Full Power** + Elasticsearch isn’t alone — it’s part of a **complete suite**: + - **Logstash**: Ingests data from anywhere (websites, apps, logs). + - **Kibana**: Visualize data (dashboards, maps, charts). + - **Beats**: Lightweight data shippers (for apps). + *This lets you build end-to-end data pipelines:* **Collect → Process → Search → Visualize** in one flow. + +5. **No More "Slow Queries" (The Real Pain Point)** + Traditional SQL databases struggle with: + - Full-text search (e.g., "show me products with 'sneakers' AND 'black'") + - Real-time analytics (e.g., "how many users clicked 'checkout' in the last 5 mins?") + Elasticsearch solves both **with one query**. + +6. **Open Source (with Enterprise Support)** + Free to use — but Elastic also offers enterprise features (security, ML, etc.) for large teams. *This is why it’s so widely adopted.* + +### Why It’s "So Cool" in Practice: +| **Problem** | **Traditional Tool** | **Elasticsearch** | +|----------------------------|----------------------------|---------------------------------------| +| Real-time product search | Slow (seconds) | Instant (milliseconds) | +| Analyze user behavior | Requires complex SQL | Simple queries + real-time dashboards| +| Handle messy logs | Needs ETL pipelines | Ingests logs *directly* | +| Scale to 10M+ users | Databases become slow | Scales horizontally effortlessly | + +### Real-World Examples: +- **Netflix**: Uses Elasticsearch for 1B+ users to personalize content. +- **GitHub**: Uses it to search code repositories (text + code structure). +- **Healthcare**: Analyzes patient data for real-time alerts (e.g., "risk of sepsis"). +- **Security**: Real-time threat detection (e.g., "suspicious login from Brazil"). + +### Why People Get Confused: +- **"Elastic" = Elasticsearch** (the product) → Not a standalone tool. +- **"The Elastic Stack"** = The full suite (Elasticsearch + Kibana + Logstash + Beats). +- **Not "Elastic" as in rubber bands** (that’s physics, not tech!). + +### The Bottom Line: +**Elasticsearch is "so cool" because it turns messy, real-time data into instant insights — without slowing down.** It’s the reason companies can build **search, analytics, and +monitoring** at scale *without* writing complex code or waiting for results. + +If you meant **"Elastic"** as in the rubber band (physics), that’s **not cool** 😄 — but in tech? **100% cool**. 😎 + +*So next time someone says "Elastic is so cool," you know exactly what they mean!* 🔥 From 89f9988209036ba7298829257848ddf0ada111d7 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 20:53:07 -0500 Subject: [PATCH 04/16] script changes and docker image --- .../app-logs/results.md | 28 +++------ .../docker-compose.yml | 20 +++++++ .../script.py | 57 ++++++++++--------- 3 files changed, 58 insertions(+), 47 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index fdcad0dc0..853101ac4 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -1,24 +1,9 @@ -## 📥 Indexing documents... - -✓ meeting_management-sync_friday.txt | Latency: 64ms - -✓ report_development-team.txt | Latency: 17ms - -✓ meeting_development-team_monday.txt | Latency: 10ms - -✓ report_QA-team.txt | Latency: 9ms - -✓ meeting_QA-team_wednesday.txt | Latency: 9ms - -🔍 Search: 'performance issues in the API' - -🔍 Búsqueda completada en 5ms +📥 Indexing documents... +🔍 Search: 'Can you summarize the performance issues in the API?' 🤖 Asking to model... -🤖 Ollama answered in 29432ms - -## 💡 Question: performance issues in the API +## 💡 Question: Can you summarize the performance issues in the API? ### 📝 Answer: @@ -77,6 +62,7 @@ Common causes include slow database queries (e.g., missing indexes, N+1 queries) ## App performance metrics: -🔍 Search Latency: 5ms -🤖 Ollama Latency: 29432ms -📄 Documents Indexed: 5 \ No newline at end of file +📄 Documents Indexed: 5 | Bulk Latency: 37ms + +🔍 Search Latency: 32ms +🤖 Ollama Latency: 29411ms | 29.5 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml new file mode 100644 index 000000000..c6e2d1889 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml @@ -0,0 +1,20 @@ +services: + ollama: + image: ollama/ollama:latest + container_name: ollama + ports: + - "11434:11434" + volumes: + - ollama_data:/root/.ollama + entrypoint: > + sh -c " + /bin/ollama serve & + sleep 5 && + /bin/ollama run qwen3:4b && + wait + " + restart: unless-stopped + +volumes: + ollama_data: + driver: local \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 044ec4eba..c4216d259 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -10,12 +10,12 @@ OLLAMA_URL = "http://localhost:11434/api/generate" DATASET_FOLDER = "./Dataset" - es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) def index_documents(): - docs_count = 0 + docs = [] + for filename in os.listdir(DATASET_FOLDER): if filename.endswith(".txt"): filepath = os.path.join(DATASET_FOLDER, filename) @@ -23,20 +23,18 @@ def index_documents(): with open(filepath, "r", encoding="utf-8") as file: content = file.read() - doc = { - "file_title": filename, - "file_content": content, - "semantic_field": f"{filename} {content}", - } + docs.append({"index": {"_index": INDEX_NAME}}) + docs.append({"file_title": filename, "file_content": content}) - start_time = time.time() - es_client.index(index=INDEX_NAME, document=doc) - index_latency = (time.time() - start_time) * 1000 # ms + indexed_docs_count = 0 - docs_count += 1 - print(f"✓ {filename} | Latency: {index_latency:.0f}ms") + if docs: + start_time = time.time() + response = es_client.bulk(body=docs) + bulk_latency = (time.time() - start_time) * 1000 # ms + indexed_docs_count = len(response["items"]) - return docs_count + return indexed_docs_count, bulk_latency def semantic_search(query, size=3): @@ -49,9 +47,6 @@ def semantic_search(query, size=3): response = es_client.search(index=INDEX_NAME, body=search_body) search_latency = (time.time() - start_time) * 1000 # ms - print( - f"🔍 Search completed in {search_latency:.0f}ms" - ) # Print for monitoring purposes return response["hits"]["hits"], search_latency @@ -65,19 +60,27 @@ def query_ollama(prompt, model="qwen3:4b"): ollama_latency = (time.time() - start_time) * 1000 # ms if response.status_code == 200: - print( - f"🤖 Ollama answered in {ollama_latency:.0f}ms" - ) # Print for monitoring purposes - return response.json()["response"], ollama_latency + response_data = response.json() + + eval_count = response_data.get("eval_count", 0) + eval_duration = response_data.get("eval_duration", 0) + tokens_per_second = 0 + + if eval_count > 0 and eval_duration > 0: + tokens_per_second = ( + eval_count / eval_duration * 1_000_000_000 + ) # nanoseconds to seconds (eval_count / eval_duration * 10^9) + + return response_data["response"], ollama_latency, tokens_per_second else: - return f"Error: {response.status_code}", ollama_latency + return f"Error: {response.status_code}", ollama_latency, 0 if __name__ == "__main__": print("📥 Indexing documents...") - docs_count = index_documents() + docs_count, bulk_latency = index_documents() - query = "performance issues in the API" + query = "Can you summarize the performance issues in the API?" print(f"\n🔍 Search: '{query}'") search_results, search_latency = semantic_search(query) @@ -91,10 +94,12 @@ def query_ollama(prompt, model="qwen3:4b"): prompt = f"{context}\nQuestion: {query}\nAnswer:" print("🤖 Asking to model...") - response, ollama_latency = query_ollama(prompt) + response, ollama_latency, tokens_per_second = query_ollama(prompt) print(f"\n💡 Question: {query}\n📝 Answer: {response}") + print(f"📄 Documents Indexed: {docs_count} | Bulk Latency: {bulk_latency:.0f}ms") print(f"\n🔍 Search Latency: {search_latency:.0f}ms") - print(f"🤖 Ollama Latency: {ollama_latency:.0f}ms") - print(f"📄 Documents Indexed: {docs_count}") + print( + f"🤖 Ollama Latency: {ollama_latency:.0f}ms | {tokens_per_second:.1f} tokens/s" + ) From 505ad49a0feff63b7162964ec3a16302196dbad5 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Fri, 19 Sep 2025 17:20:30 -0500 Subject: [PATCH 05/16] Deleting docker-compose, adding tinyllama results, code changes and dataset changes --- .../Dataset/meeting_QA-team_wednesday.txt | 41 ++++++++++- .../meeting_development-team_monday.txt | 35 +++++++++- .../meeting_management-sync_friday.txt | 40 +++++++++-- .../Dataset/report_QA-team.txt | 31 +++++++++ .../Dataset/report_development-team.txt | 31 ++++++++- .../app-logs/results.md | 69 ++++--------------- .../app-logs/tinyLlama-results.md | 15 ++++ .../docker-compose.yml | 20 ------ .../script.py | 57 ++++++++------- 9 files changed, 227 insertions(+), 112 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md delete mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt index 1550401d0..78204cb6c 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt @@ -1,3 +1,38 @@ -• Maria: “Data imports are failing when addresses contain special characters.” -• Tom: “That matches what we saw last week. We need a parser fix.” -• Maria: “Agreed, let’s log this as a blocker.” \ No newline at end of file +MEETING TRANSCRIPT - QA TEAM +Date: Wednesday, September 18, 2025 +Time: 10:00 AM - 11:30 AM +Participants: Maria (QA Lead), Tom (Senior QA Engineer), Lisa (QA Automation Engineer), Roberto (Manual Testing Specialist) + +[10:02] Maria: Let's review CRM migration testing progress. Tom, report on data import tests? + +[10:03] Tom: Found critical issues. Import failures with special characters in addresses and names. + +[10:06] Tom: UTF-8 parsing problems with accents, currency symbols, and Asian characters. + +[10:08] Tom: 12% of records affected - about 15,000 out of 125,000 total records. + +[10:09] Roberto: Confirmed. Also, failed imports corrupt entire batches. + +[10:12] Lisa: No atomic transactions for batches? + +[10:13] Tom: Correct. Each record processed independently without rollback. + +[10:15] Roberto: Found referential integrity issues - orphaned references between contacts and companies. + +[10:19] Maria: Need three validation types: pre-import, during import, and post-import. + +[10:25] Tom: Recommend smaller migration batches to reduce risk? + +[10:26] Maria: Excellent. Batches of 5,000 records with validation between each. + +[10:30] Maria: Four recommendations: UTF-8 parser fix, atomic transactions, handle orphaned references, small batch migration. + +[10:33] Roberto: Also need concurrency testing during migration. + +[10:40] Maria: Complete additional testing in one week. Feasible? + +[10:42] Tom: Will share test cases today. + +[10:44] Maria: Friday 2 PM meeting before management review. + +[10:45] Lisa: Will prepare testing metrics dashboard. \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt index 86aa66d0c..aa6deb247 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt @@ -1,3 +1,32 @@ -• Alice: “The API is working, but response times are too slow with more than 1,000 queries.” -• John: “We may need to add caching or optimize indexes.” -• Alice: “Let’s prioritize this for the next sprint.” \ No newline at end of file +MEETING TRANSCRIPT - DEVELOPMENT TEAM +Date: Monday, September 16, 2025 +Time: 09:00 AM - 10:15 AM +Participants: Alice (Tech Lead), John (Senior Developer), Sarah (Backend Developer), Mike (DevOps Engineer) + +[09:02] Alice: Let's review the search API deployed last week. Any issues? + +[09:03] Sarah: API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds. + +[09:05] John: Elasticsearch queries and no caching layer? + +[09:06] Sarah: Exactly. Complex queries are slow, and we need Redis caching. + +[09:07] Mike: Also hitting CPU limits during spikes. Need auto-scaling. + +[09:08] Alice: Three priorities: query optimization, Redis cache, and infrastructure scaling. + +[09:11] Sarah: Propose 15-minute TTL cache with event-based invalidation. + +[09:13] John: I'll optimize bool queries and add calculated index fields. + +[09:17] Mike: Can set up auto-scaling by tomorrow - scale to 6 instances at 70% CPU. + +[09:18] Sarah: Starting Redis today, basic version by Wednesday. + +[09:19] John: New indexes and query optimization ready for testing Wednesday. + +[09:24] Alice: Clear plan. Mike handles scaling, Sarah implements cache, John optimizes queries. + +[09:26] Alice: I'll coordinate with product team on deployment impacts and QA for load testing. + +[09:30] Alice: Meeting Wednesday 3 PM to review progress. Thanks team! \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt index 810e76af2..7d516d082 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt @@ -1,4 +1,36 @@ -• Manager: “Are we on track for the migration deadline next month?” -• Alice: “Development is slightly behind due to performance issues.” -• Maria: “QA also found blockers with data imports.” -• Manager: “Okay, let’s adjust the timeline by two weeks to ensure quality.” \ No newline at end of file +MEETING TRANSCRIPT - MANAGEMENT SYNC +Date: Friday, September 20, 2025 +Time: 02:00 PM - 03:00 PM +Participants: David (Project Manager), Alice (Tech Lead), Maria (QA Lead), Emma (Product Manager), Carlos (DevOps Manager) + +[14:03] Emma: Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues. + +[14:05] Alice: We've identified bottlenecks. Working on Redis caching and Elasticsearch query optimization. + +[14:06] David: Can we resolve issues without impacting October migration date? + +[14:09] Alice: Recommend two-week extension for complete migration due to performance issues. + +[14:10] Maria: QA agrees. Found data import blockers with special characters and integrity issues. + +[14:12] Maria: Need one week to fix issues, another for complete re-testing. + +[14:14] Carlos: Infrastructure supports extension for proper rollback and disaster recovery testing. + +[14:15] Emma: Could we do partial migration on original date? + +[14:17] Alice: Yes. Contact management module first, reports and analytics in phase two. + +[14:21] Maria: Phased migration ideal for QA - validate each module independently. + +[14:22] David: Proposal: Phase 1 - Contact management October 15th. Phase 2 - Complete migration October 30th. + +[14:23] Alice: Reasonable timeline for performance fixes. + +[14:24] Emma: Works from product perspective. Will update stakeholder communications. + +[14:25] Maria: QA commits to these timelines. + +[14:26] Carlos: Will prepare deployment strategies for both phases. + +[14:32] David: Carlos, send deployment calendar by Monday. Thanks team! \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt index e69de29bb..c5730a849 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt @@ -0,0 +1,31 @@ +WEEKLY REPORT - QA TEAM +Week of September 16-20, 2025 +Prepared by: Maria Gonzalez, QA Lead + +=== EXECUTIVE SUMMARY === +QA team identified critical issues in CRM migration testing. Significant problems in legacy data import and referential integrity require immediate attention. + +=== TESTING COMPLETED === +- Functional: Contact management (100%), Authentication (100%), Search (75%), Analytics (60%) +- Data import: 125,000 legacy records tested, 12 critical issues found +- Performance: Core modules complete, identified issues with 500+ concurrent users + +=== CRITICAL ISSUES === +**QA-2025-001 - Data Import Failures** +- UTF-8 parsing problems with special characters +- 15,000 records affected (12% of total) +- Escalated to development + +**QA-2025-002 - Transaction Integrity** +- Failed imports leave batches in inconsistent state +- No atomic transactions for batches +- Requires architecture redesign + +**QA-2025-003 - Orphaned References** +- 2,300 records with invalid company/contact references +- Pending business logic decision + +=== METRICS === +- Test cases executed: 847 of 1,200 (70.6%) +- Pass rate: 79.3%, Automation coverage: 36% +- Bugs: 28 total (4 critical, 8 high, 12 medium, 4 low) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt index 5670f6d65..932c920b0 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt @@ -1 +1,30 @@ -The migration to the new CRM is progressing. We finished setting up the database schema and implemented the first batch of API integrations. The main issue is performance under heavy load, especially with customer search. We estimate two more sprints to stabilize. \ No newline at end of file +WEEKLY REPORT - DEVELOPMENT TEAM +Week of September 16-20, 2025 +Prepared by: Alice Thompson, Tech Lead + +=== EXECUTIVE SUMMARY === +Development team completed critical infrastructure components but identified performance bottlenecks requiring attention before production deployment. + +=== KEY ACCOMPLISHMENTS === +- Database schema and indexes completed for CRM +- 12 of 18 API endpoints integrated with authentication +- Contact management: 95% complete, Search: 80%, Analytics: 70% + +=== TECHNICAL CHALLENGES === +- Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) +- Root cause: Complex Elasticsearch queries without caching layer +- Multi-filter searches average 1.2 seconds execution time + +=== ACTION PLAN NEXT WEEK === +1. Redis cache implementation (Sarah) - Basic by Wednesday, complete by Friday +2. Elasticsearch query optimization (John) - Testing ready Wednesday +3. Auto-scaling setup (Mike) - Scale to 6 instances at 70% CPU + +=== METRICS === +- Story points: 43 of 50 completed (86%) +- Bugs: 7 reported, 12 resolved +- Code coverage: 78% (target: 80%) + +=== TIMELINE === +- October 15 Contact Management: 85% confidence, 2 sprints remaining +- October 30 Complete Migration: 90% confidence, 4 sprints remaining \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index 853101ac4..2626190df 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -1,68 +1,23 @@ 📥 Indexing documents... -🔍 Search: 'Can you summarize the performance issues in the API?' -🤖 Asking to model... +🔍 Search: 'Can you summarize the performance issues in the API?' -## 💡 Question: Can you summarize the performance issues in the API? +## 🤖 Asking to model: llama3.2 +### 💡 Question: +Can you summarize the performance issues in the API? ### 📝 Answer: +According to the transcript, the performance issues in the API are: - -Okay, the user is asking about performance issues in an API. Let me start by understanding what they need. They might be a developer or a tech lead dealing with slow API responses. First, I should figure out the common causes of API performance problems. +1. Response times increase from 200ms to 3 seconds when handling 1,000+ queries per minute. +2. Complex Elasticsearch queries are slow, with an average execution time of 1.2 seconds. +3. Performance degrades during spikes. -Hmm, the user didn't provide specific details about their API. So I need to cover the main areas without assuming too much. Let me list out the typical issues: database queries, network latency, code inefficiencies, caching, rate limiting, external dependencies, etc. - -Wait, the user mentioned "performance issues in the API" but didn't specify if it's their own API or a third-party one. I should clarify that. But since the answer section is empty, maybe they want a general guide. - -I recall that common causes include slow database queries, especially if they're not optimized. Maybe they have N+1 queries? Or improper indexing. Also, heavy processing in the backend could be a problem. Like, if the API is doing a lot of computations per request. - -Network issues might be another angle. If the API is hosted on a different server, latency could be high. Or maybe the user is facing timeouts. - -Caching is important too. If the API isn't caching responses, every request goes to the backend. But if they have caching in place and it's not working right, that could cause slowness. - -External dependencies—like calling another API that's slow. That's a common pitfall. Also, rate limiting might be causing delays if the API is hit too hard. - -Wait, the user might need actionable steps. So I should structure the answer into sections: common causes, diagnostic steps, solutions. But the answer is supposed to be short since it's a fill-in. The user's instruction says "Answer:" so they want a concise answer. - -Looking back at the information provided, there's no specific data. So the answer should be a general response. Maybe the user expects a list of possible causes? Like in the answer field. - -Wait, the problem says "Information found:" followed by the question and answer. But the answer is empty. So the task is to generate the answer based on typical knowledge. - -I think the best approach is to list the main causes without being too technical. Let me check standard API performance issues. - -Top causes: -1. Slow database queries (e.g., missing indexes, complex joins) -2. Inefficient code (e.g., unnecessary loops, heavy computations) -3. Lack of caching -4. High network latency -5. External service dependencies -6. Rate limiting or too many requests -7. Inadequate server resources (CPU, memory) - -Also, maybe the API is not using asynchronous processing for long tasks. Or the response size is too big, causing slow transfers. - -The user might be looking for a quick reference. So I'll structure the answer as a bullet list of key points. But since it's an answer field, maybe a concise paragraph. - -Wait, the user's instruction says "Answer:" so I need to fill that part. Let me draft a response. - -"Common causes include slow database queries, inefficient code logic, lack of caching, high network latency, external dependencies, and insufficient server resources. Diagnose using tools like API monitoring, profiling, and logs." - -But maybe they want more specific. Alternatively, if this is for a specific scenario, but the user didn't specify. Hmm. - -Another angle: sometimes performance issues are due to the API design itself, like REST vs. GraphQL, but that's probably too specific. - -I think the safest answer is to list the main points briefly. Let me check similar problems online. For example, common API performance issues are often related to database, code, caching. - -Okay, I'll go with that. - - -## Final Answer: - -Common causes include slow database queries (e.g., missing indexes, N+1 queries), inefficient code logic (e.g., excessive computations, redundant operations), lack of caching, high network latency, external dependency delays, rate limiting, and insufficient server resources (CPU/memory). Diagnose using profiling tools, API monitoring, and log analysis to identify bottlenecks. +These issues are attributed to the lack of caching and a complex Elasticsearch query setup. ## App performance metrics: +✅ Indexed 5 documents in 96ms -📄 Documents Indexed: 5 | Bulk Latency: 37ms +🔍 Search Latency: 20ms -🔍 Search Latency: 32ms -🤖 Ollama Latency: 29411ms | 29.5 tokens/s \ No newline at end of file +🤖 Ollama Latency: 36772ms | 24.7 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md new file mode 100644 index 000000000..8c500d140 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md @@ -0,0 +1,15 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +## 🤖 Asking to model: TinyLlama + +### 💡 Question: Can you summarize the performance issues in the API? +#### 📝 Answer: +InfoRama has identified some issues with the seaRCSearch API, which was deployed last week. The performance of the API is causing delays and bottlenecks for key components such as query optimization, Redis cache, and infrastructure scaling. The team is working on a Redis cache implementation and Elasticsearch query optimization, but they need to get the SeaRCSearch API to scale efficiently by 6 instances at 70% CPU. The DeveloPMent Team has set three priorities: query optimization, Redis cache, and infrastructure scaling. The team is working on testing their progress and setting up automated scaling for load testing. In addition to these issues, the team identified complex Elasticsearch queries without a cchinig layer, which led to time-consuming and inefficient execution times. + +✅ Indexed 5 documents in 152ms + +🔍 Search Latency: 29ms + +🤖 Ollama Latency: 19178ms | 38.9 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml deleted file mode 100644 index c6e2d1889..000000000 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml +++ /dev/null @@ -1,20 +0,0 @@ -services: - ollama: - image: ollama/ollama:latest - container_name: ollama - ports: - - "11434:11434" - volumes: - - ollama_data:/root/.ollama - entrypoint: > - sh -c " - /bin/ollama serve & - sleep 5 && - /bin/ollama run qwen3:4b && - wait - " - restart: unless-stopped - -volumes: - ollama_data: - driver: local \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index c4216d259..91ef339f8 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -2,7 +2,7 @@ import time import requests -from elasticsearch import Elasticsearch +from elasticsearch import Elasticsearch, helpers ES_URL = "http://localhost:9200" ES_API_KEY = "your-api-key-here" @@ -10,31 +10,38 @@ OLLAMA_URL = "http://localhost:11434/api/generate" DATASET_FOLDER = "./Dataset" -es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) +es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) -def index_documents(): - docs = [] - for filename in os.listdir(DATASET_FOLDER): +def build_documents(dataset_folder, index_name): + for filename in os.listdir(dataset_folder): if filename.endswith(".txt"): - filepath = os.path.join(DATASET_FOLDER, filename) + filepath = os.path.join(dataset_folder, filename) with open(filepath, "r", encoding="utf-8") as file: content = file.read() - docs.append({"index": {"_index": INDEX_NAME}}) - docs.append({"file_title": filename, "file_content": content}) + yield { + "_index": index_name, + "_source": {"file_title": filename, "file_content": content}, + } - indexed_docs_count = 0 - if docs: +def index_documents(): + try: start_time = time.time() - response = es_client.bulk(body=docs) - bulk_latency = (time.time() - start_time) * 1000 # ms - indexed_docs_count = len(response["items"]) - return indexed_docs_count, bulk_latency + success, _ = helpers.bulk( + es_client, build_documents(DATASET_FOLDER, INDEX_NAME) + ) + + end_time = time.time() + bulk_latency = (end_time - start_time) * 1000 # ms + + return success, bulk_latency + except Exception as e: + print(f"❌ Error: {str(e)}") def semantic_search(query, size=3): @@ -45,15 +52,14 @@ def semantic_search(query, size=3): } response = es_client.search(index=INDEX_NAME, body=search_body) - search_latency = (time.time() - start_time) * 1000 # ms return response["hits"]["hits"], search_latency -def query_ollama(prompt, model="qwen3:4b"): +def query_ollama(prompt, model): start_time = time.time() - data = {"model": model, "prompt": prompt, "stream": False} + data = {"model": model, "prompt": prompt, "stream": False, "think": False} response = requests.post(OLLAMA_URL, json=data) @@ -78,11 +84,13 @@ def query_ollama(prompt, model="qwen3:4b"): if __name__ == "__main__": print("📥 Indexing documents...") - docs_count, bulk_latency = index_documents() + success, bulk_latency = index_documents() + + time.sleep(2) # Wait for indexing to complete - query = "Can you summarize the performance issues in the API?" + query = "Can you summarize the performance issues in the API?" - print(f"\n🔍 Search: '{query}'") + print(f"🔍 Search: '{query}'") search_results, search_latency = semantic_search(query) context = "Information found:\n" @@ -93,13 +101,14 @@ def query_ollama(prompt, model="qwen3:4b"): prompt = f"{context}\nQuestion: {query}\nAnswer:" - print("🤖 Asking to model...") - response, ollama_latency, tokens_per_second = query_ollama(prompt) + ollama_model = "llama3.2" + print(f"🤖 Asking to model: {ollama_model}") + response, ollama_latency, tokens_per_second = query_ollama(prompt, ollama_model) print(f"\n💡 Question: {query}\n📝 Answer: {response}") - print(f"📄 Documents Indexed: {docs_count} | Bulk Latency: {bulk_latency:.0f}ms") - print(f"\n🔍 Search Latency: {search_latency:.0f}ms") + print(f"✅ Indexed {success} documents in {bulk_latency:.0f}ms") + print(f"🔍 Search Latency: {search_latency:.0f}ms") print( f"🤖 Ollama Latency: {ollama_latency:.0f}ms | {tokens_per_second:.1f} tokens/s" ) From b8e502a4fad36b15981afa26c5105c2de01d013b Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Sat, 20 Sep 2025 13:54:39 -0500 Subject: [PATCH 06/16] tinyLlama results --- .../app-logs/tinyLlama-results.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md index 8c500d140..69ed311f3 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md @@ -6,7 +6,7 @@ ### 💡 Question: Can you summarize the performance issues in the API? #### 📝 Answer: -InfoRama has identified some issues with the seaRCSearch API, which was deployed last week. The performance of the API is causing delays and bottlenecks for key components such as query optimization, Redis cache, and infrastructure scaling. The team is working on a Redis cache implementation and Elasticsearch query optimization, but they need to get the SeaRCSearch API to scale efficiently by 6 instances at 70% CPU. The DeveloPMent Team has set three priorities: query optimization, Redis cache, and infrastructure scaling. The team is working on testing their progress and setting up automated scaling for load testing. In addition to these issues, the team identified complex Elasticsearch queries without a cchinig layer, which led to time-consuming and inefficient execution times. +During the week of September 16-20, 2025, the Development Team identified complex Elasticsearch queries and no automatic cachining layer. They completed SeaRChe search optimization but encountered performance bottlenecks requiring attention before production deployment. The team worked on implementing critical infrastructure components such as database schema and indexes, but also identified performance issues with seaRChe searches, and 95% of the remaining queries were considered critical. Despite these challenges, critical components completed by the end of the week for the upcoming migration on October 15th. The team worked on Elasticsearch query optimization and Redis cache implementation, as well as automated testing to ensure proper rollback and disaster recovery, while preparing deployment strategies for both phases of the project. ✅ Indexed 5 documents in 152ms From 401d76c7dc91ddd0e08061601407b0ccb32d0882 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Sun, 21 Sep 2025 07:30:42 -0500 Subject: [PATCH 07/16] qwen3:4b model results --- .../app-logs/qwen3:4b-results.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md new file mode 100644 index 000000000..1048cbdfc --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md @@ -0,0 +1,106 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +## 🤖 Asking to model: qwen3:4b + +### 💡 Question: Can you summarize the performance issues in the API? +#### 📝 Answer: + +`` + +We are given three files: + 1. meeting_development-team_monday.txt (transcript from Monday, Sept 16, 2025) + 2. report_development-team.txt (weekly report for week of Sept 16-20, 2025) + 3. meeting_management-sync_friday.txt (transcript from Friday, Sept 20, 2025) + +The question asks: "Can you summarize the performance issues in the API?" + +We need to look for information about API performance issues in these files. + +From the first file (meeting_development-team_monday.txt): + - At [09:03] Sarah: "API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds." + - At [09:05] John: "Elasticsearch queries and no caching layer?" + - At [09:06] Sarah: "Exactly. Complex queries are slow, and we need Redis caching." + - At [09:13] John: "I'll optimize bool queries and add calculated index fields." + - Also, in the same meeting: [09:17] Mike: "Also hitting CPU limits during spikes. Need auto-scaling." + +From the second file (report_development-team.txt): + - In "TECHNICAL CHALLENGES": + - Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) + - Root cause: Complex Elasticsearch queries without caching layer + - Multi-filter searches average 1.2 seconds execution time + +From the third file (meeting_management-sync_friday.txt): + - [14:03] Emma: "Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues." + +So, the key performance issues in the API (specifically the search API) are: + +1. The search API degrades significantly when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds (or more). +2. The root cause is complex Elasticsearch queries without a caching layer. +3. Multi-filter searches take an average of 1.2 seconds to execute. +4. The team has been working on: + - Implementing Redis caching (with a proposed 15-minute TTL and event-based invalidation) + - Optimizing Elasticsearch queries (specifically bool queries and adding calculated index fields) + - Setting up auto-scaling to handle CPU spikes (to 6 instances at 70% CPU) + +Additionally, the meeting on Friday (Sept 20) notes that users have seen a 40% improvement in search speed but there are still peak hour performance issues (as reported in support tickets). + +Therefore, the summary of performance issues in the API (focusing on the search API) is: + +- The search API experiences a critical performance degradation when the query rate exceeds 1,000 queries per minute, causing response times to jump from 200ms to 3 seconds or more. +- The root cause is complex Elasticsearch queries without a caching layer, leading to slow response times for multi-filter searches (averaging 1.2 seconds). +- The team is addressing this with Redis caching, Elasticsearch query optimization, and infrastructure scaling. + +We are to write a concise summary. + +Let me structure the answer: + +The API (specifically the search API) has the following performance issues: +1. Under heavy load (1,000+ queries per minute), response times degrade from 200ms to 3+ seconds. +2. Root cause: Complex Elasticsearch queries without a caching layer. +3. Multi-filter searches average 1.2 seconds execution time. + +The team is working on fixing these by implementing Redis caching, optimizing Elasticsearch queries, and setting up auto-scaling. + +We don't need to include the Friday meeting's 40% improvement because the question is about the issues that were identified (the current state). The meeting on Friday mentions that users report 40% improvement (so that's a positive note) but the issues (peak hour performance) are still present. + +So, the summary should focus on the issues as they were identified in the Monday meeting and the report. + +Answer: + +The search API experiences significant performance degradation when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds or more. The root cause is complex Elasticsearch queries without a caching layer, which also results in multi-filter searches taking an average of 1.2 seconds to execute. The development team is addressing these issues through Redis caching implementation, Elasticsearch query optimization, and infrastructure scaling. + +`` + +Based on the meeting transcripts and weekly report provided, here's a concise summary of the API performance issues: + +### Key Performance Issues in the Search API: +1. **Critical Degradation Under Load**: + - Response times jump from **200ms to 3+ seconds** when handling **1,000+ queries per minute** (identified in Monday meeting and weekly report). + - Multi-filter searches average **1.2 seconds** execution time. + +2. **Root Cause**: + - **Complex Elasticsearch queries** without a caching layer (confirmed by Sarah in Monday meeting). + - No Redis caching implementation (directly cited as the bottleneck). + +3. **Secondary Impact**: + - Infrastructure is hitting **CPU limits during traffic spikes** (reported by Mike in Monday meeting), requiring auto-scaling. + +4. **Current Progress**: + - Users have seen a **40% speed improvement** (per Friday meeting), but peak-hour performance issues persist in support tickets. + - The team is addressing this through: + - Redis caching (15-min TTL with event-based invalidation) + - Elasticsearch query optimization (bool queries + calculated index fields) + - Auto-scaling (target: 6 instances at 70% CPU) + +### Why This Matters for Deployment: +The issues are critical enough that the migration timeline was adjusted to **phase the deployment** (Contact management first on Oct 15, full migration on Oct 30) to ensure stability before production. Without these fixes, the API would risk significant slowdowns during high-traffic periods. + +*Summary derived from all three files, with focus on API performance specifics (search API) as per the question.* + +✅ Indexed 5 documents in 151ms + +🔍 Search Latency: 39ms + +🤖 Ollama Latency: 137790ms | 14.3 tokens/s \ No newline at end of file From f2d67f325598c72305d922d85021397661e76c8a Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Tue, 11 Nov 2025 20:11:09 -0500 Subject: [PATCH 08/16] local-rag-with-lightweight-elasticsearch --- .../llama-smoltalk-3.2-1b-instruct_results.md | 19 ++ .../app-logs/qwen3:4b-results.md | 106 -------- .../app-logs/results.md | 26 +- .../app-logs/smollm2-1.7b-instruct_results.md | 28 +++ .../app-logs/tinyLlama-results.md | 15 -- .../app-logs/why-elasticsearch-is-so-cool.md | 63 +---- .../requirements.txt | 230 ++++++++++++++++++ .../script.py | 50 ++-- 8 files changed, 324 insertions(+), 213 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md delete mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md delete mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/requirements.txt diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md new file mode 100644 index 000000000..333025cc3 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md @@ -0,0 +1,19 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +🤖 Asking to model: llama-smoltalk-3.2-1b-instruct + +## 💡 Question: +Can you summarize the performance issues in the API? + +## 📝 Answer: +The primary performance issue in the API is the slow response times of 3 seconds or more from the 1,000+ queries per minute. The search API, in particular, is experiencing performance degradations, with complex Elasticsearch queries causing the issues. A proposed solution is to implement a 15-minute TTL cache with event-based invalidation to improve response times. Additionally, a three-tiered approach involving optimization of bool queries and added calculated index fields is being implemented to improve query performance. Finally, auto-scaling for the infrastructure is set up to scale to 6 instances at 70% CPU. + + +## Stats +✅ Indexed 5 documents in 250ms + +🔍 Search Latency: 57ms + +🤖 AI Latency: 21019ms | 5.8 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md deleted file mode 100644 index 1048cbdfc..000000000 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md +++ /dev/null @@ -1,106 +0,0 @@ -📥 Indexing documents... - -🔍 Search: 'Can you summarize the performance issues in the API?' - -## 🤖 Asking to model: qwen3:4b - -### 💡 Question: Can you summarize the performance issues in the API? -#### 📝 Answer: - -`` - -We are given three files: - 1. meeting_development-team_monday.txt (transcript from Monday, Sept 16, 2025) - 2. report_development-team.txt (weekly report for week of Sept 16-20, 2025) - 3. meeting_management-sync_friday.txt (transcript from Friday, Sept 20, 2025) - -The question asks: "Can you summarize the performance issues in the API?" - -We need to look for information about API performance issues in these files. - -From the first file (meeting_development-team_monday.txt): - - At [09:03] Sarah: "API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds." - - At [09:05] John: "Elasticsearch queries and no caching layer?" - - At [09:06] Sarah: "Exactly. Complex queries are slow, and we need Redis caching." - - At [09:13] John: "I'll optimize bool queries and add calculated index fields." - - Also, in the same meeting: [09:17] Mike: "Also hitting CPU limits during spikes. Need auto-scaling." - -From the second file (report_development-team.txt): - - In "TECHNICAL CHALLENGES": - - Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) - - Root cause: Complex Elasticsearch queries without caching layer - - Multi-filter searches average 1.2 seconds execution time - -From the third file (meeting_management-sync_friday.txt): - - [14:03] Emma: "Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues." - -So, the key performance issues in the API (specifically the search API) are: - -1. The search API degrades significantly when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds (or more). -2. The root cause is complex Elasticsearch queries without a caching layer. -3. Multi-filter searches take an average of 1.2 seconds to execute. -4. The team has been working on: - - Implementing Redis caching (with a proposed 15-minute TTL and event-based invalidation) - - Optimizing Elasticsearch queries (specifically bool queries and adding calculated index fields) - - Setting up auto-scaling to handle CPU spikes (to 6 instances at 70% CPU) - -Additionally, the meeting on Friday (Sept 20) notes that users have seen a 40% improvement in search speed but there are still peak hour performance issues (as reported in support tickets). - -Therefore, the summary of performance issues in the API (focusing on the search API) is: - -- The search API experiences a critical performance degradation when the query rate exceeds 1,000 queries per minute, causing response times to jump from 200ms to 3 seconds or more. -- The root cause is complex Elasticsearch queries without a caching layer, leading to slow response times for multi-filter searches (averaging 1.2 seconds). -- The team is addressing this with Redis caching, Elasticsearch query optimization, and infrastructure scaling. - -We are to write a concise summary. - -Let me structure the answer: - -The API (specifically the search API) has the following performance issues: -1. Under heavy load (1,000+ queries per minute), response times degrade from 200ms to 3+ seconds. -2. Root cause: Complex Elasticsearch queries without a caching layer. -3. Multi-filter searches average 1.2 seconds execution time. - -The team is working on fixing these by implementing Redis caching, optimizing Elasticsearch queries, and setting up auto-scaling. - -We don't need to include the Friday meeting's 40% improvement because the question is about the issues that were identified (the current state). The meeting on Friday mentions that users report 40% improvement (so that's a positive note) but the issues (peak hour performance) are still present. - -So, the summary should focus on the issues as they were identified in the Monday meeting and the report. - -Answer: - -The search API experiences significant performance degradation when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds or more. The root cause is complex Elasticsearch queries without a caching layer, which also results in multi-filter searches taking an average of 1.2 seconds to execute. The development team is addressing these issues through Redis caching implementation, Elasticsearch query optimization, and infrastructure scaling. - -`` - -Based on the meeting transcripts and weekly report provided, here's a concise summary of the API performance issues: - -### Key Performance Issues in the Search API: -1. **Critical Degradation Under Load**: - - Response times jump from **200ms to 3+ seconds** when handling **1,000+ queries per minute** (identified in Monday meeting and weekly report). - - Multi-filter searches average **1.2 seconds** execution time. - -2. **Root Cause**: - - **Complex Elasticsearch queries** without a caching layer (confirmed by Sarah in Monday meeting). - - No Redis caching implementation (directly cited as the bottleneck). - -3. **Secondary Impact**: - - Infrastructure is hitting **CPU limits during traffic spikes** (reported by Mike in Monday meeting), requiring auto-scaling. - -4. **Current Progress**: - - Users have seen a **40% speed improvement** (per Friday meeting), but peak-hour performance issues persist in support tickets. - - The team is addressing this through: - - Redis caching (15-min TTL with event-based invalidation) - - Elasticsearch query optimization (bool queries + calculated index fields) - - Auto-scaling (target: 6 instances at 70% CPU) - -### Why This Matters for Deployment: -The issues are critical enough that the migration timeline was adjusted to **phase the deployment** (Contact management first on Oct 15, full migration on Oct 30) to ensure stability before production. Without these fixes, the API would risk significant slowdowns during high-traffic periods. - -*Summary derived from all three files, with focus on API performance specifics (search API) as per the question.* - -✅ Indexed 5 documents in 151ms - -🔍 Search Latency: 39ms - -🤖 Ollama Latency: 137790ms | 14.3 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index 2626190df..5463f5cea 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -2,22 +2,24 @@ 🔍 Search: 'Can you summarize the performance issues in the API?' -## 🤖 Asking to model: llama3.2 +🤖 Asking to model: dolphin3.0-qwen2.5-0.5b -### 💡 Question: +## 💡 Question: Can you summarize the performance issues in the API? -### 📝 Answer: -According to the transcript, the performance issues in the API are: +## 📝 Answer: -1. Response times increase from 200ms to 3 seconds when handling 1,000+ queries per minute. -2. Complex Elasticsearch queries are slow, with an average execution time of 1.2 seconds. -3. Performance degrades during spikes. +The performance issues in the Search API deployed on September 16, 2025, include: -These issues are attributed to the lack of caching and a complex Elasticsearch query setup. +- Degradation in performance at 1,000+ queries per minute, resulting in a 200ms to 3-second response time for complex queries. +- High response times for queries that do not utilize caching, causing them to take significantly longer than 2 seconds. +- Inability to scale to handle spikes in query traffic, leading to increased CPU limits. -## App performance metrics: -✅ Indexed 5 documents in 96ms +These issues are primarily attributed to the complexity and inefficiency of the Elasticsearch queries, as well as the lack of caching layer. This indicates a need for optimization and addressing these specific performance bottlenecks to ensure the API's scalability and effectiveness for the development team. -🔍 Search Latency: 20ms +## Stats -🤖 Ollama Latency: 36772ms | 24.7 tokens/s \ No newline at end of file +✅ Indexed 5 documents in 627ms + +🔍 Search Latency: 81ms + +🤖 AI Latency: 16044ms | 9.5 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md new file mode 100644 index 000000000..c3beb29e7 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md @@ -0,0 +1,28 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +🤖 Asking to model: smollm2-1.7b-instruct + +## 💡 Question: + +Can you summarize the performance issues in the API? +## 📝 Answer: + +The summary of the performance issues in the API can be summarized as follows: + +- The API works but performance degrades at 1,000+ queries per minute, resulting in response times jumping from 200ms to 3 seconds. +- The root cause of these issues is the lack of a caching layer in the Elasticsearch queries. +- The team proposed a few solutions, including a 15-minute TTL cache with event-based invalidation, which would be implemented by Sarah. +- They also proposed optimizing boolean queries and adding calculated index fields, which would be taken care of by John. +- To handle the performance spikes, they suggested auto-scaling the infrastructure, with Mike working on this and aiming to scale to 6 instances at 70% CPU by Wednesday. +- They also proposed implementing Redis cache, which would be done by Sarah. +- The team discussed the timeline and timeline of the changes and proposed a phased migration approach: complete migration on October 30th, followed by a partial migration on October 15th. + +## Stats + +✅ Indexed 5 documents in 141ms + +🔍 Search Latency: 26ms + +🤖 AI Latency: 47561ms | 4.8 tokens/s diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md deleted file mode 100644 index 69ed311f3..000000000 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md +++ /dev/null @@ -1,15 +0,0 @@ -📥 Indexing documents... - -🔍 Search: 'Can you summarize the performance issues in the API?' - -## 🤖 Asking to model: TinyLlama - -### 💡 Question: Can you summarize the performance issues in the API? -#### 📝 Answer: -During the week of September 16-20, 2025, the Development Team identified complex Elasticsearch queries and no automatic cachining layer. They completed SeaRChe search optimization but encountered performance bottlenecks requiring attention before production deployment. The team worked on implementing critical infrastructure components such as database schema and indexes, but also identified performance issues with seaRChe searches, and 95% of the remaining queries were considered critical. Despite these challenges, critical components completed by the end of the week for the upcoming migration on October 15th. The team worked on Elasticsearch query optimization and Redis cache implementation, as well as automated testing to ensure proper rollback and disaster recovery, while preparing deployment strategies for both phases of the project. - -✅ Indexed 5 documents in 152ms - -🔍 Search Latency: 29ms - -🤖 Ollama Latency: 19178ms | 38.9 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md index d1582b294..96a312e80 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md @@ -1,62 +1,11 @@ >>> Why Elastic is so cool? -That's a **great question**, but there's a **critical clarification first**: **"Elastic" alone isn't a product** — it's almost always a shorthand for **Elasticsearch** (the core search -engine) and the **Elastic Stack** (Elasticsearch + Kibana + Logstash + Beats). +## Raw Response -**Why people say "Elastic is so cool" (and why it's actually *Elasticsearch* that's the star):** +```json +{"created":1762881411,"object":"chat.completion","id":"0178b570-4e13-4c1b-9ff4-e2ca5bff1c67","model":"dolphin3.0-qwen2.5-0.5b","choices":[{"index":0,"finish_reason":"stop","message":{"role":"assistant","content":"Elastic is a versatile technology that supports a wide range of applications. Its coolness stems from its ability to manage complex environments and provide a seamless integration with other technologies."}}],"usage":{"prompt_tokens":14,"completion_tokens":35,"total_tokens":49}} +``` -1. **Real-Time Search & Analytics (The "Cool" Part!)** - Elasticsearch doesn't just *search* — it **indexes, searches, and analyzes data in real time** (millions of events/sec). Unlike traditional databases (which need slow queries or -batch processing), it gives you instant answers. - *Example:* Netflix uses it to show personalized movie recommendations *as you browse* — not after you click "Next" or "Save." +## Answer -2. **Handles "Wild" Data (Unstructured + Structured)** - Most data today is messy (text, logs, images, JSON, CSV). Elasticsearch **natively understands** this. - *Example:* A company can search *both* "user feedback in Slack messages" *and* "product prices from a spreadsheet" in one query. - -3. **Scalability That Doesn’t Break** - It’s built to scale **horizontally** (add more servers) without downtime. Handles **petabytes** of data. - *Example:* Airbnb uses it to power their 10M+ listing search across 200+ countries — *without* slowing down. - -4. **The Elastic Stack = Full Power** - Elasticsearch isn’t alone — it’s part of a **complete suite**: - - **Logstash**: Ingests data from anywhere (websites, apps, logs). - - **Kibana**: Visualize data (dashboards, maps, charts). - - **Beats**: Lightweight data shippers (for apps). - *This lets you build end-to-end data pipelines:* **Collect → Process → Search → Visualize** in one flow. - -5. **No More "Slow Queries" (The Real Pain Point)** - Traditional SQL databases struggle with: - - Full-text search (e.g., "show me products with 'sneakers' AND 'black'") - - Real-time analytics (e.g., "how many users clicked 'checkout' in the last 5 mins?") - Elasticsearch solves both **with one query**. - -6. **Open Source (with Enterprise Support)** - Free to use — but Elastic also offers enterprise features (security, ML, etc.) for large teams. *This is why it’s so widely adopted.* - -### Why It’s "So Cool" in Practice: -| **Problem** | **Traditional Tool** | **Elasticsearch** | -|----------------------------|----------------------------|---------------------------------------| -| Real-time product search | Slow (seconds) | Instant (milliseconds) | -| Analyze user behavior | Requires complex SQL | Simple queries + real-time dashboards| -| Handle messy logs | Needs ETL pipelines | Ingests logs *directly* | -| Scale to 10M+ users | Databases become slow | Scales horizontally effortlessly | - -### Real-World Examples: -- **Netflix**: Uses Elasticsearch for 1B+ users to personalize content. -- **GitHub**: Uses it to search code repositories (text + code structure). -- **Healthcare**: Analyzes patient data for real-time alerts (e.g., "risk of sepsis"). -- **Security**: Real-time threat detection (e.g., "suspicious login from Brazil"). - -### Why People Get Confused: -- **"Elastic" = Elasticsearch** (the product) → Not a standalone tool. -- **"The Elastic Stack"** = The full suite (Elasticsearch + Kibana + Logstash + Beats). -- **Not "Elastic" as in rubber bands** (that’s physics, not tech!). - -### The Bottom Line: -**Elasticsearch is "so cool" because it turns messy, real-time data into instant insights — without slowing down.** It’s the reason companies can build **search, analytics, and -monitoring** at scale *without* writing complex code or waiting for results. - -If you meant **"Elastic"** as in the rubber band (physics), that’s **not cool** 😄 — but in tech? **100% cool**. 😎 - -*So next time someone says "Elastic is so cool," you know exactly what they mean!* 🔥 +Elastic is a versatile technology that supports a wide range of applications. Its coolness stems from its ability to manage complex environments and provide a seamless integration with other technologies. diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/requirements.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/requirements.txt new file mode 100644 index 000000000..6ad807a9b --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/requirements.txt @@ -0,0 +1,230 @@ +absl-py==2.3.1 +aiohappyeyeballs==2.4.6 +aiohttp==3.11.13 +aiosignal==1.3.2 +alembic==1.14.1 +annotated-types==0.7.0 +anyio==4.10.0 +appdirs==1.4.4 +appnope==0.1.4 +asgiref==3.8.1 +asttokens==3.0.0 +async-timeout==5.0.1 +attrs==25.1.0 +auth0-python==4.8.1 +backoff==2.2.1 +bcrypt==4.3.0 +beautifulsoup4==4.13.3 +blinker==1.9.0 +build==1.2.2.post1 +cachetools==5.5.2 +certifi==2025.1.31 +cffi==1.17.1 +charset-normalizer==3.4.1 +chroma-hnswlib==0.7.6 +chromadb==0.5.23 +click==8.1.8 +cohere==5.14.0 +coloredlogs==15.0.1 +comm==0.2.2 +crewai==0.102.0 +crewai-tools==0.36.0 +cryptography==44.0.2 +dataclasses-json==0.6.7 +debugpy==1.8.12 +decorator==5.2.1 +Deprecated==1.2.18 +deprecation==2.1.0 +distro==1.9.0 +docker==7.1.0 +docstring_parser==0.16 +durationpy==0.9 +elastic-transport==8.17.0 +elasticsearch==8.17.0 +embedchain==0.1.127 +et_xmlfile==2.0.0 +exceptiongroup==1.3.0 +executing==2.2.0 +fastapi==0.104.1 +fastavro==1.10.0 +filelock==3.17.0 +flatbuffers==25.2.10 +frozenlist==1.5.0 +fsspec==2025.2.0 +google-api-core==2.24.1 +google-auth==2.38.0 +google-cloud-aiplatform==1.82.0 +google-cloud-bigquery==3.30.0 +google-cloud-core==2.4.2 +google-cloud-resource-manager==1.14.1 +google-cloud-storage==2.19.0 +google-crc32c==1.6.0 +google-genai==1.30.0 +google-resumable-media==2.7.2 +googleapis-common-protos==1.68.0 +gptcache==0.1.44 +grpc-google-iam-v1==0.14.0 +grpcio==1.70.0 +grpcio-status==1.70.0 +grpcio-tools==1.70.0 +h11==0.14.0 +h2==4.2.0 +hpack==4.1.0 +httpcore==1.0.7 +httptools==0.6.4 +httpx==0.28.1 +httpx-sse==0.4.0 +huggingface-hub==0.29.1 +humanfriendly==10.0 +hyperframe==6.1.0 +idna==3.10 +importlib_metadata==8.5.0 +importlib_resources==6.5.2 +instructor==1.7.2 +ipykernel==6.29.5 +ipython==9.0.1 +ipython_pygments_lexers==1.1.1 +jedi==0.19.2 +Jinja2==3.1.5 +jiter==0.8.2 +json5==0.10.0 +json_repair==0.39.1 +jsonpatch==1.33 +jsonpickle==4.0.2 +jsonpointer==3.0.0 +jsonref==1.1.0 +jsonschema==4.23.0 +jsonschema-specifications==2024.10.1 +jupyter_client==8.6.3 +jupyter_core==5.7.2 +kubernetes==32.0.1 +lancedb==0.20.0 +langchain==0.3.19 +langchain-cohere==0.3.5 +langchain-community==0.3.18 +langchain-core==0.3.40 +langchain-experimental==0.3.4 +langchain-openai==0.2.14 +langchain-text-splitters==0.3.6 +langextract==1.0.8 +langsmith==0.1.147 +litellm==1.60.2 +Mako==1.3.9 +markdown-it-py==3.0.0 +MarkupSafe==3.0.2 +marshmallow==3.26.1 +matplotlib-inline==0.1.7 +mdurl==0.1.2 +mem0ai==0.1.60 +ml_collections==1.1.0 +mmh3==5.1.0 +monotonic==1.6 +more-itertools==10.7.0 +mpmath==1.3.0 +multidict==6.1.0 +mypy-extensions==1.0.0 +nest-asyncio==1.6.0 +networkx==3.4.2 +nodeenv==1.9.1 +numpy==1.26.4 +oauthlib==3.2.2 +onnxruntime==1.20.1 +openai==1.65.2 +openpyxl==3.1.5 +opentelemetry-api==1.30.0 +opentelemetry-exporter-otlp-proto-common==1.30.0 +opentelemetry-exporter-otlp-proto-grpc==1.30.0 +opentelemetry-exporter-otlp-proto-http==1.30.0 +opentelemetry-instrumentation==0.51b0 +opentelemetry-instrumentation-asgi==0.51b0 +opentelemetry-instrumentation-fastapi==0.51b0 +opentelemetry-proto==1.30.0 +opentelemetry-sdk==1.30.0 +opentelemetry-semantic-conventions==0.51b0 +opentelemetry-util-http==0.51b0 +orjson==3.10.15 +overrides==7.7.0 +packaging==24.2 +pandas==2.2.3 +parso==0.8.4 +pdfminer.six==20231228 +pdfplumber==0.11.5 +pexpect==4.9.0 +pillow==11.1.0 +platformdirs==4.3.6 +portalocker==2.10.1 +posthog==3.18.0 +prompt_toolkit==3.0.50 +propcache==0.3.0 +proto-plus==1.26.0 +protobuf==5.29.3 +psutil==7.0.0 +ptyprocess==0.7.0 +pure_eval==0.2.3 +pyarrow==19.0.1 +pyasn1==0.6.1 +pyasn1_modules==0.4.1 +pycparser==2.22 +pydantic==2.5.0 +pydantic-settings==2.8.1 +pydantic_core==2.14.1 +Pygments==2.19.1 +PyJWT==2.10.1 +pylance==0.23.2 +pypdf==5.3.1 +pypdfium2==4.30.1 +PyPika==0.48.9 +pyproject_hooks==1.2.0 +pyright==1.1.396 +pysbd==0.3.4 +python-dateutil==2.9.0.post0 +python-dotenv==1.0.1 +pytube==15.0.0 +pytz==2024.2 +pyvis==0.3.2 +PyYAML==6.0.2 +pyzmq==26.2.1 +qdrant-client==1.13.2 +referencing==0.36.2 +regex==2024.11.6 +requests==2.32.3 +requests-oauthlib==2.0.0 +requests-toolbelt==1.0.0 +rich==13.9.4 +rpds-py==0.23.1 +rsa==4.9 +schema==0.7.7 +shapely==2.0.7 +shellingham==1.5.4 +six==1.17.0 +sniffio==1.3.1 +soupsieve==2.6 +SQLAlchemy==2.0.38 +stack-data==0.6.3 +starlette==0.27.0 +sympy==1.13.3 +tabulate==0.9.0 +tenacity==9.0.0 +tiktoken==0.7.0 +tokenizers==0.20.3 +tomli==2.2.1 +tomli_w==1.2.0 +tornado==6.4.2 +tqdm==4.67.1 +traitlets==5.14.3 +typer==0.15.2 +types-requests==2.32.0.20250301 +typing-inspect==0.9.0 +typing_extensions==4.12.2 +tzdata==2025.1 +urllib3==2.3.0 +uv==0.6.3 +uvicorn==0.24.0 +uvloop==0.21.0 +watchfiles==1.0.4 +wcwidth==0.2.13 +websocket-client==1.8.0 +websockets==15.0.1 +wrapt==1.17.2 +yarl==1.18.3 +zipp==3.21.0 diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 91ef339f8..66362c638 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -1,17 +1,18 @@ import os import time -import requests from elasticsearch import Elasticsearch, helpers +from openai import OpenAI ES_URL = "http://localhost:9200" ES_API_KEY = "your-api-key-here" INDEX_NAME = "team-data" -OLLAMA_URL = "http://localhost:11434/api/generate" +LOCAL_AI_URL = "http://localhost:8080/v1" # Local AI server URL DATASET_FOLDER = "./Dataset" es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) +ai_client = OpenAI(base_url=LOCAL_AI_URL, api_key="sk-x") def build_documents(dataset_folder, index_name): @@ -42,6 +43,7 @@ def index_documents(): return success, bulk_latency except Exception as e: print(f"❌ Error: {str(e)}") + return 0, 0 def semantic_search(query, size=3): @@ -57,29 +59,32 @@ def semantic_search(query, size=3): return response["hits"]["hits"], search_latency -def query_ollama(prompt, model): +def query_local_ai(prompt, model): start_time = time.time() - data = {"model": model, "prompt": prompt, "stream": False, "think": False} - response = requests.post(OLLAMA_URL, json=data) + try: + response = ai_client.chat.completions.create( + model=model, + messages=[{"role": "user", "content": prompt}], + ) - ollama_latency = (time.time() - start_time) * 1000 # ms + ai_latency = (time.time() - start_time) * 1000 # ms - if response.status_code == 200: - response_data = response.json() + # Extract response text + response_text = response.choices[0].message.content - eval_count = response_data.get("eval_count", 0) - eval_duration = response_data.get("eval_duration", 0) + # Calculate tokens per second if usage info is available tokens_per_second = 0 + if hasattr(response, "usage") and response.usage: + total_tokens = response.usage.completion_tokens + if ai_latency > 0: + tokens_per_second = (total_tokens / ai_latency) * 1000 # tokens/second - if eval_count > 0 and eval_duration > 0: - tokens_per_second = ( - eval_count / eval_duration * 1_000_000_000 - ) # nanoseconds to seconds (eval_count / eval_duration * 10^9) + return response_text, ai_latency, tokens_per_second + except Exception as e: + ai_latency = (time.time() - start_time) * 1000 - return response_data["response"], ollama_latency, tokens_per_second - else: - return f"Error: {response.status_code}", ollama_latency, 0 + return f"Error: {str(e)}", ai_latency, 0 if __name__ == "__main__": @@ -101,14 +106,13 @@ def query_ollama(prompt, model): prompt = f"{context}\nQuestion: {query}\nAnswer:" - ollama_model = "llama3.2" - print(f"🤖 Asking to model: {ollama_model}") - response, ollama_latency, tokens_per_second = query_ollama(prompt, ollama_model) + ai_model = "dolphin3.0-qwen2.5-0.5b" + + print(f"🤖 Asking to model: {ai_model}") + response, ai_latency, tokens_per_second = query_local_ai(prompt, ai_model) print(f"\n💡 Question: {query}\n📝 Answer: {response}") print(f"✅ Indexed {success} documents in {bulk_latency:.0f}ms") print(f"🔍 Search Latency: {search_latency:.0f}ms") - print( - f"🤖 Ollama Latency: {ollama_latency:.0f}ms | {tokens_per_second:.1f} tokens/s" - ) + print(f"🤖 AI Latency: {ai_latency:.0f}ms | {tokens_per_second:.1f} tokens/s") From 876f60472ea572369e65d685f551eab4bd415053 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 11:29:06 -0500 Subject: [PATCH 09/16] adding readme methos for create mappings and inference endpoint --- .../README.md | 31 +++++++ .../app-logs/why-elasticsearch-is-so-cool.md | 11 --- .../app-logs/why-is-the-sky-blue.md | 18 ++++ .../script.py | 88 ++++++++++++++++++- 4 files changed, 134 insertions(+), 14 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md delete mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md new file mode 100644 index 000000000..5a1609a0a --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md @@ -0,0 +1,31 @@ +# Local RAG with Elasticsearch & Local AI + +Simple RAG (Retrieval-Augmented Generation) system using Elasticsearch for semantic search and Local AI as model provider. + +## Prerequisites + +- Docker +- Python 3.11+ + +## Quick Start + +### 1. Activate Virtual Environment + +```bash +python -m venv venv +source venv/bin/activate +``` + +### 2. Install Python Dependencies + +```bash +pip install -r requirements.txt +``` + +### 3. Run the Script + +```bash +python script.py +``` + + diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md deleted file mode 100644 index 96a312e80..000000000 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md +++ /dev/null @@ -1,11 +0,0 @@ ->>> Why Elastic is so cool? - -## Raw Response - -```json -{"created":1762881411,"object":"chat.completion","id":"0178b570-4e13-4c1b-9ff4-e2ca5bff1c67","model":"dolphin3.0-qwen2.5-0.5b","choices":[{"index":0,"finish_reason":"stop","message":{"role":"assistant","content":"Elastic is a versatile technology that supports a wide range of applications. Its coolness stems from its ability to manage complex environments and provide a seamless integration with other technologies."}}],"usage":{"prompt_tokens":14,"completion_tokens":35,"total_tokens":49}} -``` - -## Answer - -Elastic is a versatile technology that supports a wide range of applications. Its coolness stems from its ability to manage complex environments and provide a seamless integration with other technologies. diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md new file mode 100644 index 000000000..a48331cee --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md @@ -0,0 +1,18 @@ +>>> Why Elastic is so cool? + +## Raw Response + +```json +{"created":1763994585,"object":"chat.completion","id":"d96f7e7a-003f-4167-bb07-501aa41ef8e7","model":"dolphin3.0-qwen2.5-0.5b","choices":[{"index":0,"finish_reason":"stop","message":{"role":"assistant","content":"The sky being blue is primarily due to the scattering of sunlight by the Earth's atmosphere. Here are a few key factors contributing to the blue color of the sky:\n\n1. **Scattering of Light**: Blue light is scattered more than other colors by the Earth's atmosphere. This scattering occurs because blue light has a shorter wavelength, which is more likely to travel through the Earth's atmosphere than other wavelengths. The scattering occurs as the light bounces off particles in the atmosphere, such as dust and water vapor, which have a higher concentration in the upper atmosphere.\n\n2. **Atmospheric Composition**: The Earth's atmosphere is composed of gases like nitrogen, oxygen, and water vapor. These gases have different properties, and their interactions with sunlight can affect the colors they transmit. Nitrogen and oxygen gases have a scattering effect that is more intense at shorter wavelengths than water vapor, which results in the blue color observed in the sky.\n\n3. **Atmospheric Reflection**: The blue color of the sky also depends on the amount of light reflecting off the Earth's surface. Clouds, for instance, can reflect a lot of sunlight, particularly blue and green light, which creates a blue tint to the sky. Additionally, the reflection of sunlight from the Earth's surface can contribute to the blue color observed in the sky.\n\n4. **Clouds and Precipitation**: The presence of clouds and precipitation can also affect the color of the sky. Clouds can scatter blue light, but they can also trap it, making the sky appear a bit less blue. Precipitation, particularly heavy rain or snow, can also scatter light, making the sky appear a bit darker and more gray.\n\nIn summary, the blue color of the sky is a result of the scattering of sunlight by the Earth's atmosphere, with the primary contributor being the scattering of blue light and the absorption of other wavelengths by particles in the atmosphere."}}],"usage":{"prompt_tokens":14,"completion_tokens":384,"total_tokens":398}} +``` + +## Answer + +The sky being blue is primarily due to the scattering of sunlight by the Earth's atmosphere. Here are a few key factors contributing to the blue color of the sky: + +1. **Scattering of Light**: Blue light is scattered more than other colors by the Earth's atmosphere. This scattering occurs because blue light has a shorter wavelength, which is more likely to travel through the Earth's atmosphere than other wavelengths. The scattering occurs as the light bounces off particles in the atmosphere, such as dust and water vapor, which have a higher concentration in the upper atmosphere. +2. **Atmospheric Composition**: The Earth's atmosphere is composed of gases like nitrogen, oxygen, and water vapor. These gases have different properties, and their interactions with sunlight can affect the colors they transmit. Nitrogen and oxygen gases have a scattering effect that is more intense at shorter wavelengths than water vapor, which results in the blue color observed in the sky. +3. **Atmospheric Reflection**: The blue color of the sky also depends on the amount of light reflecting off the Earth's surface. Clouds, for instance, can reflect a lot of sunlight, particularly blue and green light, which creates a blue tint to the sky. Additionally, the reflection of sunlight from the Earth's surface can contribute to the blue color observed in the sky. +4. **Clouds and Precipitation**: The presence of clouds and precipitation can also affect the color of the sky. Clouds can scatter blue light, but they can also trap it, making the sky appear a bit less blue. Precipitation, particularly heavy rain or snow, can also scatter light, making the sky appear a bit darker and more gray. + +In summary, the blue color of the sky is a result of the scattering of sunlight by the Earth's atmosphere, with the primary contributor being the scattering of blue light and the absorption of other wavelengths by particles in the atmosphere. diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 66362c638..8500b13d9 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -5,7 +5,7 @@ from openai import OpenAI ES_URL = "http://localhost:9200" -ES_API_KEY = "your-api-key-here" +ES_API_KEY = "NDdDQWM1b0JPSDBFTV9JQzA0WVo6eHFXcWFJQmFYNzBwS1RjUllpRUNHZw==" INDEX_NAME = "team-data" LOCAL_AI_URL = "http://localhost:8080/v1" # Local AI server URL DATASET_FOLDER = "./Dataset" @@ -15,6 +15,79 @@ ai_client = OpenAI(base_url=LOCAL_AI_URL, api_key="sk-x") +def setup_inference_endpoint(): + inference_id = "e5-small-model" + try: + es_client.inference.put( + inference_id=inference_id, + task_type="text_embedding", + body={ + "service": "elasticsearch", + "service_settings": { + "num_allocations": 1, + "num_threads": 1, + "model_id": ".multilingual-e5-small", + }, + }, + ) + print(f"✅ Inference endpoint '{inference_id}' created successfully") + except Exception as e: + print(f"❌ Error creating inference endpoint: {str(e)}") + + +def setup_inference_endpoint(): + inference_id = "e5-small-model" + + try: + es_client.inference.get(inference_id=inference_id) + print(f"✅ Inference endpoint '{inference_id}' already exists") + except Exception: + print(f"📦 Creating inference endpoint '{inference_id}'...") + + try: + es_client.inference.put( + inference_id=inference_id, + task_type="text_embedding", + body={ + "service": "elasticsearch", + "service_settings": { + "num_allocations": 1, + "num_threads": 1, + "model_id": ".multilingual-e5-small", + }, + }, + ) + print(f"✅ Inference endpoint '{inference_id}' created successfully") + except Exception as e: + print(f"❌ Error creating inference endpoint: {str(e)}") + + +def setup_index(): + try: + if es_client.indices.exists(index=INDEX_NAME): + print(f"✅ Index '{INDEX_NAME}' already exists") + + print(f"📦 Creating index '{INDEX_NAME}'...") + es_client.indices.create( + index=INDEX_NAME, + body={ + "mappings": { + "properties": { + "file_title": {"type": "text", "copy_to": "semantic_field"}, + "file_content": {"type": "text", "copy_to": "semantic_field"}, + "semantic_field": { + "type": "semantic_text", + "inference_id": "e5-small-model", + }, + } + } + }, + ) + print(f"✅ Index '{INDEX_NAME}' created successfully") + except Exception as e: + print(f"❌ Error creating index: {str(e)}") + + def build_documents(dataset_folder, index_name): for filename in os.listdir(dataset_folder): if filename.endswith(".txt"): @@ -88,7 +161,13 @@ def query_local_ai(prompt, model): if __name__ == "__main__": - print("📥 Indexing documents...") + print("🚀 Setting up infrastructure...") + + # Setup inference endpoint and index + setup_inference_endpoint() + setup_index() + + print("\n📥 Indexing documents...") success, bulk_latency = index_documents() time.sleep(2) # Wait for indexing to complete @@ -106,7 +185,10 @@ def query_local_ai(prompt, model): prompt = f"{context}\nQuestion: {query}\nAnswer:" - ai_model = "dolphin3.0-qwen2.5-0.5b" + # ai_model = "llama-smoltalk-3.2-1b-instruct" + # ai_model = "dolphin3.0-qwen2.5-0.5b" + # ai_model = "fastllama-3.2-1b-instruct" + ai_model = "smollm2-1.7b-instruct" print(f"🤖 Asking to model: {ai_model}") response, ai_latency, tokens_per_second = query_local_ai(prompt, ai_model) From ac0585090ec01f4cadf02b88c2896e38f30000dd Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 18:52:32 -0500 Subject: [PATCH 10/16] changing dataset technology references to generic ones --- .../Dataset/meeting_development-team_monday.txt | 8 ++++---- .../Dataset/meeting_management-sync_friday.txt | 2 +- .../Dataset/report_development-team.txt | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt index aa6deb247..7435951a5 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt @@ -7,13 +7,13 @@ Participants: Alice (Tech Lead), John (Senior Developer), Sarah (Backend Develop [09:03] Sarah: API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds. -[09:05] John: Elasticsearch queries and no caching layer? +[09:05] John: Database queries and no caching layer? -[09:06] Sarah: Exactly. Complex queries are slow, and we need Redis caching. +[09:06] Sarah: Exactly. Complex queries are slow, and we need a caching layer. [09:07] Mike: Also hitting CPU limits during spikes. Need auto-scaling. -[09:08] Alice: Three priorities: query optimization, Redis cache, and infrastructure scaling. +[09:08] Alice: Three priorities: query optimization, cache implementation, and infrastructure scaling. [09:11] Sarah: Propose 15-minute TTL cache with event-based invalidation. @@ -21,7 +21,7 @@ Participants: Alice (Tech Lead), John (Senior Developer), Sarah (Backend Develop [09:17] Mike: Can set up auto-scaling by tomorrow - scale to 6 instances at 70% CPU. -[09:18] Sarah: Starting Redis today, basic version by Wednesday. +[09:18] Sarah: Starting cache implementation today, basic version by Wednesday. [09:19] John: New indexes and query optimization ready for testing Wednesday. diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt index 7d516d082..fea4865ea 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt @@ -5,7 +5,7 @@ Participants: David (Project Manager), Alice (Tech Lead), Maria (QA Lead), Emma [14:03] Emma: Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues. -[14:05] Alice: We've identified bottlenecks. Working on Redis caching and Elasticsearch query optimization. +[14:05] Alice: We've identified bottlenecks. Working on cache layer implementation and search engine query optimization. [14:06] David: Can we resolve issues without impacting October migration date? diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt index 932c920b0..c47601501 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt @@ -12,12 +12,12 @@ Development team completed critical infrastructure components but identified per === TECHNICAL CHALLENGES === - Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) -- Root cause: Complex Elasticsearch queries without caching layer +- Root cause: Complex database queries without caching layer - Multi-filter searches average 1.2 seconds execution time === ACTION PLAN NEXT WEEK === -1. Redis cache implementation (Sarah) - Basic by Wednesday, complete by Friday -2. Elasticsearch query optimization (John) - Testing ready Wednesday +1. Cache system implementation (Sarah) - Basic by Wednesday, complete by Friday +2. Search engine query optimization (John) - Testing ready Wednesday 3. Auto-scaling setup (Mike) - Scale to 6 instances at 70% CPU === METRICS === From 6866f1e68ac767810ace699755e87b37fcfb1675 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 19:11:33 -0500 Subject: [PATCH 11/16] adding dotenv support --- .../README.md | 23 +++++++++-- .../script.py | 38 +++++++++++++------ 2 files changed, 46 insertions(+), 15 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md index 5a1609a0a..2a9143ecf 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/README.md @@ -1,6 +1,6 @@ -# Local RAG with Elasticsearch & Local AI +# Build a Local lightweight RAG System with Elasticsearch -Simple RAG (Retrieval-Augmented Generation) system using Elasticsearch for semantic search and Local AI as model provider. +Simple RAG (Retrieval-Augmented Generation) system using Elasticsearch for semantic search and Local AI as model provider. This application serves as supporting content for the blog post [Build a Local lightweight RAG System with Elasticsearch](https://www.elastic.co/search-labs/blog/local-rag-with-lightweight-elasticsearch) ## Prerequisites @@ -22,7 +22,24 @@ source venv/bin/activate pip install -r requirements.txt ``` -### 3. Run the Script +### 3. Configure Environment Variables + +Create an `.env` and put there your settings: + +```yaml +# Elasticsearch Configuration +ES_URL=http://localhost:9200 +ES_API_KEY="your_elasticsearch_api_key_here" +INDEX_NAME=team-data + +# Local AI Configuration +LOCAL_AI_URL=http://localhost:8080/v1 + +# Dataset Configuration +DATASET_FOLDER=./Dataset +``` + +### 4. Run the Script ```bash python script.py diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 8500b13d9..25165e5c3 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -1,14 +1,17 @@ import os import time +from dotenv import load_dotenv from elasticsearch import Elasticsearch, helpers from openai import OpenAI -ES_URL = "http://localhost:9200" -ES_API_KEY = "NDdDQWM1b0JPSDBFTV9JQzA0WVo6eHFXcWFJQmFYNzBwS1RjUllpRUNHZw==" -INDEX_NAME = "team-data" -LOCAL_AI_URL = "http://localhost:8080/v1" # Local AI server URL -DATASET_FOLDER = "./Dataset" +load_dotenv() + +ES_URL = os.getenv("ES_URL", "http://localhost:9200") +ES_API_KEY = os.getenv("ES_API_KEY") +INDEX_NAME = os.getenv("INDEX_NAME", "team-data") +LOCAL_AI_URL = os.getenv("LOCAL_AI_URL", "http://localhost:8080/v1") +DATASET_FOLDER = os.getenv("DATASET_FOLDER", "./Dataset") es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) @@ -177,23 +180,34 @@ def query_local_ai(prompt, model): print(f"🔍 Search: '{query}'") search_results, search_latency = semantic_search(query) - context = "Information found:\n" - for hit in search_results: + context = "" + citations = [] + for idx, hit in enumerate(search_results, 1): source = hit["_source"] - context += f"File: {source['file_title']}\n" + context += f"[{idx}] File: {source['file_title']}\n" context += f"Content: {source['file_content']}\n\n" + citations.append(f"[{idx}] {source['file_title']}") + + prompt = f"""Based on the following documents, answer the user's question. + You MUST cite your sources using the format [1], [2], etc. when referencing information from the documents. + + Documents: + {context} + + User Question: {query} - prompt = f"{context}\nQuestion: {query}\nAnswer:" + Answer (remember to include citations [1], [2], etc. when referencing specific information) + """ - # ai_model = "llama-smoltalk-3.2-1b-instruct" - # ai_model = "dolphin3.0-qwen2.5-0.5b" - # ai_model = "fastllama-3.2-1b-instruct" ai_model = "smollm2-1.7b-instruct" print(f"🤖 Asking to model: {ai_model}") response, ai_latency, tokens_per_second = query_local_ai(prompt, ai_model) print(f"\n💡 Question: {query}\n📝 Answer: {response}") + print("\n📚 Citations:") + for citation in citations: + print(f" {citation}") print(f"✅ Indexed {success} documents in {bulk_latency:.0f}ms") print(f"🔍 Search Latency: {search_latency:.0f}ms") From 0c45108c26a1b2cbb4942c6e860d4be580bc23eb Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 19:19:05 -0500 Subject: [PATCH 12/16] build_documents method renamed to load_documents --- .../local-rag-with-lightweight-elasticsearch/script.py | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 25165e5c3..1245ce65d 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -91,7 +91,7 @@ def setup_index(): print(f"❌ Error creating index: {str(e)}") -def build_documents(dataset_folder, index_name): +def load_documents(dataset_folder, index_name): for filename in os.listdir(dataset_folder): if filename.endswith(".txt"): filepath = os.path.join(dataset_folder, filename) @@ -109,9 +109,7 @@ def index_documents(): try: start_time = time.time() - success, _ = helpers.bulk( - es_client, build_documents(DATASET_FOLDER, INDEX_NAME) - ) + success, _ = helpers.bulk(es_client, load_documents(DATASET_FOLDER, INDEX_NAME)) end_time = time.time() bulk_latency = (end_time - start_time) * 1000 # ms From b8e92a8fe6d3d5a7d6139c049e4bcbd64bfce818 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 19:33:01 -0500 Subject: [PATCH 13/16] adding code comments and index validations --- .../script.py | 45 ++++++++++--------- 1 file changed, 25 insertions(+), 20 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 1245ce65d..17ed74496 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -19,26 +19,8 @@ def setup_inference_endpoint(): - inference_id = "e5-small-model" - try: - es_client.inference.put( - inference_id=inference_id, - task_type="text_embedding", - body={ - "service": "elasticsearch", - "service_settings": { - "num_allocations": 1, - "num_threads": 1, - "model_id": ".multilingual-e5-small", - }, - }, - ) - print(f"✅ Inference endpoint '{inference_id}' created successfully") - except Exception as e: - print(f"❌ Error creating inference endpoint: {str(e)}") + """Create the e5-small-model inference endpoint for text embeddings if it doesn't exist.""" - -def setup_inference_endpoint(): inference_id = "e5-small-model" try: @@ -66,6 +48,8 @@ def setup_inference_endpoint(): def setup_index(): + """Create the Elasticsearch index with semantic_text field mappings if it doesn't exist.""" + try: if es_client.indices.exists(index=INDEX_NAME): print(f"✅ Index '{INDEX_NAME}' already exists") @@ -92,11 +76,15 @@ def setup_index(): def load_documents(dataset_folder, index_name): + """Generator that yields documents from .txt files in the dataset folder for bulk indexing.""" + for filename in os.listdir(dataset_folder): if filename.endswith(".txt"): filepath = os.path.join(dataset_folder, filename) - with open(filepath, "r", encoding="utf-8") as file: + with open( + filepath, "r", encoding="utf-8" + ) as file: # UTF-8 encoding ensures proper handling of special characters and international text content = file.read() yield { @@ -106,9 +94,18 @@ def load_documents(dataset_folder, index_name): def index_documents(): + """Bulk index all documents from the dataset folder into Elasticsearch and return success count and latency.""" + try: start_time = time.time() + if es_client.indices.exists(index=INDEX_NAME) is False: + print( + f"❌ Error: Index '{INDEX_NAME}' does not exist. Please set up the index first." + ) + + return 0, 0 + success, _ = helpers.bulk(es_client, load_documents(DATASET_FOLDER, INDEX_NAME)) end_time = time.time() @@ -121,6 +118,8 @@ def index_documents(): def semantic_search(query, size=3): + """Perform semantic search and return top results with latency.""" + start_time = time.time() search_body = { "query": {"semantic": {"field": "semantic_field", "query": query}}, @@ -134,9 +133,12 @@ def semantic_search(query, size=3): def query_local_ai(prompt, model): + """Send a prompt to Local AI model and return the response, latency, and tokens per second.""" + start_time = time.time() try: + # Using simple completions without streaming. response = ai_client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], @@ -173,6 +175,9 @@ def query_local_ai(prompt, model): time.sleep(2) # Wait for indexing to complete + if success == 0: # if the index documents failed, or index does not exist, exit + exit(1) + query = "Can you summarize the performance issues in the API?" print(f"🔍 Search: '{query}'") From d96c99c15bd64a3f5d27b73fdab34e4d0e0e7955 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 19:51:46 -0500 Subject: [PATCH 14/16] removing indexing latency calc ulations --- .../script.py | 42 +++++++++---------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 17ed74496..ce52beb1c 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -15,7 +15,9 @@ es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) -ai_client = OpenAI(base_url=LOCAL_AI_URL, api_key="sk-x") +ai_client = OpenAI( + base_url=LOCAL_AI_URL, api_key="sk-x" +) # You don't need a real OpenAI key for Local AI but we need to pass something, if you leave it blank it throws an error def setup_inference_endpoint(): @@ -53,6 +55,7 @@ def setup_index(): try: if es_client.indices.exists(index=INDEX_NAME): print(f"✅ Index '{INDEX_NAME}' already exists") + return False print(f"📦 Creating index '{INDEX_NAME}'...") es_client.indices.create( @@ -71,8 +74,10 @@ def setup_index(): }, ) print(f"✅ Index '{INDEX_NAME}' created successfully") + return True except Exception as e: print(f"❌ Error creating index: {str(e)}") + exit(1) def load_documents(dataset_folder, index_name): @@ -97,24 +102,16 @@ def index_documents(): """Bulk index all documents from the dataset folder into Elasticsearch and return success count and latency.""" try: - start_time = time.time() - if es_client.indices.exists(index=INDEX_NAME) is False: - print( - f"❌ Error: Index '{INDEX_NAME}' does not exist. Please set up the index first." - ) - - return 0, 0 + print(f"❌ Error: Index '{INDEX_NAME}' does not exist. ") + exit(1) success, _ = helpers.bulk(es_client, load_documents(DATASET_FOLDER, INDEX_NAME)) - end_time = time.time() - bulk_latency = (end_time - start_time) * 1000 # ms - - return success, bulk_latency + return success except Exception as e: - print(f"❌ Error: {str(e)}") - return 0, 0 + print(f"❌ Error indexing documents: {str(e)}") + exit(1) def semantic_search(query, size=3): @@ -168,15 +165,17 @@ def query_local_ai(prompt, model): # Setup inference endpoint and index setup_inference_endpoint() - setup_index() + is_created = setup_index() - print("\n📥 Indexing documents...") - success, bulk_latency = index_documents() + if is_created: # Index was just created, need to index documents + print("\n📥 Indexing documents...") + success = index_documents() - time.sleep(2) # Wait for indexing to complete + if success == 0: # if indexing failed, exit + print("❌ Documents indexing failed. Exiting.") + exit(1) - if success == 0: # if the index documents failed, or index does not exist, exit - exit(1) + time.sleep(1) # Wait for indexing to complete query = "Can you summarize the performance issues in the API?" @@ -212,6 +211,5 @@ def query_local_ai(prompt, model): for citation in citations: print(f" {citation}") - print(f"✅ Indexed {success} documents in {bulk_latency:.0f}ms") - print(f"🔍 Search Latency: {search_latency:.0f}ms") + print(f"\n🔍 Search Latency: {search_latency:.0f}ms") print(f"🤖 AI Latency: {ai_latency:.0f}ms | {tokens_per_second:.1f} tokens/s") From c7fae031f3e4357f1a3e6a8825305a95aa27f431 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 20:22:38 -0500 Subject: [PATCH 15/16] prompt changes --- .../local-rag-with-lightweight-elasticsearch/script.py | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index ce52beb1c..adcc24aec 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -108,6 +108,7 @@ def index_documents(): success, _ = helpers.bulk(es_client, load_documents(DATASET_FOLDER, INDEX_NAME)) + print(f"✅ Indexed {success} documents successfully") return success except Exception as e: print(f"❌ Error indexing documents: {str(e)}") @@ -197,11 +198,9 @@ def query_local_ai(prompt, model): {context} User Question: {query} - - Answer (remember to include citations [1], [2], etc. when referencing specific information) """ - ai_model = "smollm2-1.7b-instruct" + ai_model = "dolphin3.0-qwen2.5-0.5b" print(f"🤖 Asking to model: {ai_model}") response, ai_latency, tokens_per_second = query_local_ai(prompt, ai_model) From 3336810368009ec435c8bc9345dfe48a8e9ffa76 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Mon, 24 Nov 2025 20:26:21 -0500 Subject: [PATCH 16/16] results files updated --- .../llama-smoltalk-3.2-1b-instruct_results.md | 19 +++++++++++----- .../app-logs/results.md | 20 +++++++++-------- .../app-logs/smollm2-1.7b-instruct_results.md | 22 ++++++++----------- .../app-logs/why-is-the-sky-blue.md | 2 +- 4 files changed, 34 insertions(+), 29 deletions(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md index 333025cc3..ceeff2d23 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/llama-smoltalk-3.2-1b-instruct_results.md @@ -1,5 +1,3 @@ -📥 Indexing documents... - 🔍 Search: 'Can you summarize the performance issues in the API?' 🤖 Asking to model: llama-smoltalk-3.2-1b-instruct @@ -8,12 +6,21 @@ Can you summarize the performance issues in the API? ## 📝 Answer: -The primary performance issue in the API is the slow response times of 3 seconds or more from the 1,000+ queries per minute. The search API, in particular, is experiencing performance degradations, with complex Elasticsearch queries causing the issues. A proposed solution is to implement a 15-minute TTL cache with event-based invalidation to improve response times. Additionally, a three-tiered approach involving optimization of bool queries and added calculated index fields is being implemented to improve query performance. Finally, auto-scaling for the infrastructure is set up to scale to 6 instances at 70% CPU. +Based on the documents, it appears that the main performance issue with the API is related to the search query optimization. The API degrades to around 1,000+ queries per minute (QP/min) when there are 12 of 18 API endpoints integrated with authentication. This issue is caused by complex queries without a caching layer, leading to performance degrades and slow response times. +However, there is also a smaller issue with the "Search" API, where it degrades to around 3+ seconds after 1.2 seconds execution time. This is likely due to multi-filter searches and the need for a caching layer to improve performance. -## Stats -✅ Indexed 5 documents in 250ms +To address these issues, the team is working on implementing a caching layer (Sarah) and optimizing bool queries and adding calculated index fields (John) to improve query efficiency. They are also working on setting up auto-scaling for the database (Mike) to ensure that it can handle increased traffic. + +A meeting was held to discuss these issues and a plan for improvement was agreed upon. The team will work together to implement a caching layer and optimize the queries, and the team will work with product team to ensure that the migration is completed on time and does not impact the October migration date. -🔍 Search Latency: 57ms +📚 Citations: + [1] report_development-team.txt + [2] meeting_development-team_monday.txt + [3] meeting_management-sync_friday.txt + + +## Stats +🔍 Search Latency: 12ms 🤖 AI Latency: 21019ms | 5.8 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index 5463f5cea..d3cd7dc3d 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -1,4 +1,3 @@ -📥 Indexing documents... 🔍 Search: 'Can you summarize the performance issues in the API?' @@ -8,18 +7,21 @@ Can you summarize the performance issues in the API? ## 📝 Answer: -The performance issues in the Search API deployed on September 16, 2025, include: +The performance issues in the API can be summarized as follows: -- Degradation in performance at 1,000+ queries per minute, resulting in a 200ms to 3-second response time for complex queries. -- High response times for queries that do not utilize caching, causing them to take significantly longer than 2 seconds. -- Inability to scale to handle spikes in query traffic, leading to increased CPU limits. +1. **Search API degrades with 1,000+ queries per minute**: The search API has degraded, with performance degrades to a time of 3 seconds compared to the target of 200ms. -These issues are primarily attributed to the complexity and inefficiency of the Elasticsearch queries, as well as the lack of caching layer. This indicates a need for optimization and addressing these specific performance bottlenecks to ensure the API's scalability and effectiveness for the development team. +2. **Complex queries are slow and no caching layer**: Complex queries take longer to execute as expected. -## Stats +3. **CPU limits during spikes**: The CPU usage is at 100% at the peak hour and limits to 70% at the peak hour. + +📚 Citations: + [1] report_development-team.txt + [2] meeting_development-team_monday.txt + [3] meeting_management-sync_friday.txt -✅ Indexed 5 documents in 627ms +## Stats -🔍 Search Latency: 81ms +🔍 Search Latency: 14ms 🤖 AI Latency: 16044ms | 9.5 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md index c3beb29e7..455b5c69a 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/smollm2-1.7b-instruct_results.md @@ -1,5 +1,3 @@ -📥 Indexing documents... - 🔍 Search: 'Can you summarize the performance issues in the API?' 🤖 Asking to model: smollm2-1.7b-instruct @@ -9,20 +7,18 @@ Can you summarize the performance issues in the API? ## 📝 Answer: -The summary of the performance issues in the API can be summarized as follows: +The development team identified two key technical challenges for the API: -- The API works but performance degrades at 1,000+ queries per minute, resulting in response times jumping from 200ms to 3 seconds. -- The root cause of these issues is the lack of a caching layer in the Elasticsearch queries. -- The team proposed a few solutions, including a 15-minute TTL cache with event-based invalidation, which would be implemented by Sarah. -- They also proposed optimizing boolean queries and adding calculated index fields, which would be taken care of by John. -- To handle the performance spikes, they suggested auto-scaling the infrastructure, with Mike working on this and aiming to scale to 6 instances at 70% CPU by Wednesday. -- They also proposed implementing Redis cache, which would be done by Sarah. -- The team discussed the timeline and timeline of the changes and proposed a phased migration approach: complete migration on October 30th, followed by a partial migration on October 15th. +1. The search API degrades at 1,000+ queries per minute, causing average execution times to jump from 200ms to 3 seconds. +2. The root cause is complex database queries without a caching layer, leading to poor query performance. -## Stats +📚 Citations: + [1] report_development-team.txt + [2] meeting_development-team_monday.txt + [3] meeting_management-sync_friday.txt -✅ Indexed 5 documents in 141ms +## Stats -🔍 Search Latency: 26ms +🔍 Search Latency: 16ms 🤖 AI Latency: 47561ms | 4.8 tokens/s diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md index a48331cee..539291465 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-is-the-sky-blue.md @@ -1,4 +1,4 @@ ->>> Why Elastic is so cool? +>>> Why is the sky blue? ## Raw Response