Document Clustering with LLM Embeddings in Scikit-learn

 

In this article, you will learn how to cluster a collection of text documents using large language model embeddings and standard clustering algorithms in scikit-learn.

Topics we will cover include:

• Why LLM-based embeddings are well suited for document clustering.
• How to generate embeddings from raw text using a pre-trained sentence transformer.
• How to apply and compare k-means and DBSCAN for clustering embedded documents.

Let’s get straight to the point.

Document Clustering with LLM Embeddings in Scikit-learn (click to enlarge)
Image by Editor

Introduction

Imagine that you suddenly obtain a large collection of unclassified documents and are tasked with grouping them by topic. There are traditional clustering methods for text, based on TF-IDF and Word2Vec, that can address this problem, but they suffer from important limitations:

• TF-IDF only counts words in a text and relies on similarity based on word frequencies, ignoring the underlying meaning. A sentence like “the tree is big” has an identical representation whether it refers to a natural tree or a decision tree classifier used in machine learning.
• Word2Vec captures relationships between individual words to form embeddings (numerical vector representations), but it does not explicitly model full context across longer text sequences.

Meanwhile, modern embeddings generated by large language models, such as sentence transformer models, are in most cases superior. They capture contextual semantics — for example, distinguishing natural trees from decision trees — and encode overall, document-level meaning. Moreover, these embeddings are produced by models pre-trained on millions of texts, meaning they already contain a substantial amount of general language knowledge.

This article follows up on a previous tutorial, where we learned how to convert raw text into large language model embeddings that can be used as features for downstream machine learning tasks. Here, we focus specifically on using embeddings from a collection of documents for clustering based on similarity, with the goal of identifying common topics among documents in the same cluster.

Step-by-Step Guide

Let’s walk through the full process using Python.

Depending on your development environment or notebook configuration, you may need to pip install some of the libraries imported below. Assuming they are already available, we start by importing the required modules and classes, including KMeans, scikit-learn’s implementation of the k-means clustering algorithm:

import pandas as pd import numpy as np from sentence_transformers import SentenceTransformer from sklearn.cluster import KMeans from sklearn.decomposition import PCA from sklearn.metrics import silhouette_score, adjusted_rand_score from sklearn.preprocessing import LabelEncoder import matplotlib.pyplot as plt import seaborn as sns   # Configurations for clearer visualizations sns.set_style("whitegrid") plt.rcParams['figure.figsize'] = (12, 6)

Next, we load the dataset. We will use a BBC News dataset containing articles labeled by topic, with a public version available from a Google-hosted dataset repository:

url = "https://storage.googleapis.com/dataset-uploader/bbc/bbc-text.csv" df = pd.read_csv(url)   print(f"Dataset loaded: {len(df)} documents") print(f"Categories: {df['category'].unique()}\n") print(df['category'].value_counts())

Here, we only display information about the categories to get a sense of the ground-truth topics assigned to each document. The dataset contains 2,225 documents in the version used at the time of writing.

At this point, we are ready for the two main steps of the workflow: generating embeddings from raw text and clustering those embeddings.

Generating Embeddings with a Pre-Trained Model

Libraries such as sentence_transformers make it straightforward to use a pre-trained model for tasks like generating embeddings from text. The workflow consists of loading a suitable model — such as all-MiniLM-L6-v2, a lightweight model trained to produce 384-dimensional embeddings — and running inference over the dataset to convert each document into a numerical vector that captures its overall semantics.

We start by loading the model:

# Load embeddings model (downloaded automatically on first use) print("Loading embeddings model...") model = SentenceTransformer('all-MiniLM-L6-v2')   # This model converts text into a 384-dimensional vector print(f"Model loaded. Embedding dimension: {model.get_sentence_embedding_dimension()}")

Next, we generate embeddings for all documents:

# Convert all documents into embedding vectors print("Generating embeddings (this may take a few minutes)...")   texts = df['text'].tolist() embeddings = model.encode(     texts,     show_progress_bar=True,     batch_size=32  # Batch processing for efficiency )   print(f"Embeddings generated: matrix size is {embeddings.shape}") print(f"   → Each document is now represented by {embeddings.shape[1]} numeric values")

Recall that an embedding is a high-dimensional numerical vector. Documents that are semantically similar are expected to have embeddings that are close to each other in this vector space.

Clustering Document Embeddings with K-Means

Applying the k-means clustering algorithm with scikit-learn is straightforward. We pass in the embedding matrix and specify the number of clusters to find. While this number must be chosen in advance for k-means, we can leverage prior knowledge of the dataset’s ground-truth categories in this example. In other settings, techniques such as the elbow method can help guide this choice.

The following code applies k-means and evaluates the results using several metrics, including the Adjusted Rand Index (ARI). ARI is a permutation-invariant metric that compares the cluster assignments with the true category labels. Values closer to 1 indicate stronger agreement with the ground truth.

n_clusters = 5   kmeans = KMeans(n_clusters=n_clusters, random_state=42, n_init=10) kmeans_labels = kmeans.fit_predict(embeddings)   # Evaluation against ground-truth categories le = LabelEncoder() true_labels = le.fit_transform(df['category'])   print("   K-Means Results:") print(f"   Silhouette Score: {silhouette_score(embeddings, kmeans_labels):.3f}") print(f"   Adjusted Rand Index: {adjusted_rand_score(true_labels, kmeans_labels):.3f}") print(f"   Distribution: {pd.Series(kmeans_labels).value_counts().sort_index().tolist()}")

Example output:

K-Means Results:    Silhouette Score: 0.066    Adjusted Rand Index: 0.899    Distribution: [376, 414, 517, 497, 421]

Clustering Document Embeddings with DBSCAN

As an alternative, we can apply DBSCAN, a density-based clustering algorithm that automatically infers the number of clusters based on point density. Instead of specifying the number of clusters, DBSCAN requires parameters such as eps (the neighborhood radius) and min_samples:

from sklearn.cluster import DBSCAN   # DBSCAN often works better with cosine distance for text embeddings dbscan = DBSCAN(eps=0.5, min_samples=5, metric='cosine') dbscan_labels = dbscan.fit_predict(embeddings)   # Count clusters (-1 indicates noise points) n_clusters_found = len(set(dbscan_labels)) - (1 if -1 in dbscan_labels else 0) n_noise = list(dbscan_labels).count(-1)   print("\nDBSCAN Results:") print(f"   Clusters found: {n_clusters_found}") print(f"   Noise documents: {n_noise}") print(f"   Silhouette Score: {silhouette_score(embeddings[dbscan_labels != -1], dbscan_labels[dbscan_labels != -1]):.3f}") print(f"   Adjusted Rand Index: {adjusted_rand_score(true_labels, dbscan_labels):.3f}") print(f"   Distribution: {pd.Series(dbscan_labels).value_counts().sort_index().to_dict()}")

DBSCAN is highly sensitive to its hyperparameters, so achieving good results often requires careful tuning using systematic search strategies.

Once reasonable parameters have been identified, it can be informative to visually compare the clustering results. The following code projects the embeddings into two dimensions using principal component analysis (PCA) and plots the true categories alongside the k-means and DBSCAN cluster assignments:

# Reduce embeddings to 2D for visualization pca = PCA(n_components=2, random_state=42) embeddings_2d = pca.fit_transform(embeddings)   # Create comparative visualization fig, axes = plt.subplots(1, 3, figsize=(18, 5))   # Plot 1: True categories category_colors = {cat: i for i, cat in enumerate(df['category'].unique())} color_map = df['category'].map(category_colors)   axes[0].scatter(     embeddings_2d[:, 0],     embeddings_2d[:, 1],     c=color_map,     cmap='Set2',     alpha=0.6,     s=30 ) axes[0].set_title('True Categories', fontsize=12, fontweight='bold') axes[0].set_xlabel('PC1') axes[0].set_ylabel('PC2')   # Plot 2: K-Means scatter2 = axes[1].scatter(     embeddings_2d[:, 0],     embeddings_2d[:, 1],     c=kmeans_labels,     cmap='viridis',     alpha=0.6,     s=30 ) axes[1].set_title(f'K-Means (k={n_clusters})', fontsize=12, fontweight='bold') axes[1].set_xlabel('PC1') axes[1].set_ylabel('PC2') plt.colorbar(scatter2, ax=axes[1])   # Plot 3: DBSCAN scatter3 = axes[2].scatter(     embeddings_2d[:, 0],     embeddings_2d[:, 1],     c=dbscan_labels,     cmap='plasma',     alpha=0.6,     s=30 ) axes[2].set_title(f'DBSCAN ({n_clusters_found} clusters + noise)', fontsize=12, fontweight='bold') axes[2].set_xlabel('PC1') axes[2].set_ylabel('PC2') plt.colorbar(scatter3, ax=axes[2])   plt.tight_layout() plt.show()

With the default DBSCAN settings, k-means typically performs much better on this dataset. There are two main reasons for this:

• DBSCAN suffers from the curse of dimensionality, and 384-dimensional embeddings can be challenging for density-based methods.
• K-means performs well when clusters are relatively well separated, which is the case for the BBC News dataset due to the clear topical structure of the documents.

Wrapping Up

In this article, we demonstrated how to cluster a collection of text documents using embedding representations generated by pre-trained large language models. After transforming raw text into numerical vectors, we applied traditional clustering techniques — k-means and DBSCAN — to group semantically similar documents and evaluate their performance against known topic labels.

Small Language Models are the Future of Agentic AI

 

Small LLMs are the Future of Agentic AI
Image by Editor | ChatGPT

Introduction

This article provides a summary of and commentary on the recent paper Small LLMs are the Future of Agentic AI. The study is a position paper that lays out several insightful postulates about the potential of small language models (SLMs) to drive innovation in agentic AI systems, compared to their larger counterparts, the LLMs, which are currently the predominant component fueling modern agentic AI solutions in organizations.

A couple of quick definitions before we jump into the paper:

• Agentic AI systems are autonomous systems capable of reasoning, planning, making decisions, and acting in complex and dynamic environments. Recently, this paradigm, which has been investigated for decades, has gained renewed attention due to its significant potential and impact when used alongside state-of-the-art language models and other cutting-edge AI-driven applications. You can find a list of 10 Agentic AI Key Terms Explained in this article.
• Language models are natural language processing (NLP) solutions trained on large datasets of text to perform a variety of language understanding and language generation tasks, including text generation and completion, question-answering, text classification, summarization, translation, and more.

Throughout this article, we will distinguish between small language models (SLMs) — those “small” enough to run efficiently on end-consumer hardware— and large language models (LLMs) — which are much larger and usually require cloud infrastructure. At times, we will simply use “language models” to refer to both from a more general perspective.

Authors’ Position

The article opens by highlighting the increasing relevance of agentic AI systems and their significant level of adoption by organizations today, usually in a symbiotic relationship with language models. State-of-the-art solutions, however, traditionally rely on LLMs due to their deep, general reasoning capabilities and their broad knowledge, gained from being trained on vast datasets.

This “status quo” and assumption that LLMs are the universal go-to approach for integration into agentic AI systems is precisely what the authors challenge through their position: they suggest shifting some attention to SLMs that, despite their smaller size compared to LLMs, could be a better approach for agentic AI in terms of efficiency, cost-effectiveness, and system adaptability.

Some key views underpinning the claim that SLMs, rather than LLMs, are “the future of agentic AI” are summarized below:

• SLMs are sufficiently powerful to undertake most current agentic tasks
• SLMs are better suited for modular agentic AI architectures
• SLMs’ deployment and maintenance are more feasible

The paper further elaborates on these views with the following arguments:

SLMs’ Aptitude for Agentic Tasks

Several arguments are provided to support this view. One is based on empirical evidence that SLM performance is rapidly improving, with models like Phi-2, Phi-3, SmoILM2, and more, reporting promising results. On another note, as AI agents are typically instructed to excel at a limited range of language model capabilities, properly fine-tuned SLMs should often be appropriate for most domain-specific applications, with the added benefits of efficiency and flexibility.

SLMs’ Suitability for Agentic AI Architectures

The small size and reduced pre-training and fine-tuning costs of SLMs make them easier to accommodate in typically modular agentic AI architectures and easier to adapt to ever-evolving user needs, behaviors, and requirements. Meanwhile, a well-fine-tuned SLM for selected domain-specific prompt sets can be sufficient for specialized systems and settings, although LLMs will generally have a broader understanding of language and the world as a whole. On another note, as AI agents frequently interact with code, conformance to certain formatting requirements is also a concern to ensure consistency. Consequently, SLMs trained with narrower formatting specifications would be preferable.

The heterogeneity inherent in agentic systems and interactions is another reason why SLMs are argued to be more suitable for agentic architectures, as these interactions serve as a pathway to gather data.

SLMs’ Economic Feasibility

SLM flexibility can be easily translated into a higher potential for democratization. The aforementioned reduced operational costs are a major reason for this. In more economic terms, the paper compares SLMs against LLMs concerning inference efficiency, fine-tuning agility, edge deployment, and parameter usage: aspects in which SLMs are considered superior.

Alternative Views, Barriers, and Discussion

The authors not only present their view, but they also outline and address counterarguments solidly founded on existing literature. These include statements like LLMs generally outperforming SLMs due to scalability laws (which may not always hold for narrow subtasks or task-specific fine-tuning), centralized LLM infrastructure being cheaper at scale (which can be countered by decreasing costs and modular SLM deployments that prevent bottlenecks), and industry inertia favoring LLMs over SLMs (which, while true, does not outweigh other SLM advantages like adaptability and economic efficiency, among others).

The main barrier to adopting SLMs as the universal go-to approach alongside agentic systems is the well-established dominance of LLMs from many perspectives, not just technical ones, accompanied by substantial investments made in LLM-centric pipelines. Clearly demonstrating the discussed advantages of SLMs is paramount to motivating and facilitating a transition from LLMs to SLMs in agentic solutions.

To finalize this analysis and summary of the paper, here are some of my own perspectives on what we have outlined and discussed. Specifically, while the claims made throughout the paper are brilliantly well-founded and convincing, in our rapidly changing world, paradigm shifts are often subject to barriers. Accordingly, I consider the following to be three major barriers to adopting SLMs as the main approach underlying agentic AI systems:

• The huge investments made in LLM infrastructure (already highlighted by the authors) make it difficult to change the status quo, at least in the short term, due to the strong economic inertia behind LLM-centric pipelines.
• We may have to rethink evaluation benchmarks to adapt them for SLM-based frameworks, as current benchmarks are designed to prioritize general performance aspects rather than narrow, specialized performance in agentic systems.
• Last, and perhaps simplest, there is still work to be done in terms of raising public awareness about the potential and advances made by SLMs. The “LLM” buzzword is deeply rooted in society, and the LLM-first mindset will take time and effort to evolve before decision-makers and practitioners jointly view SLMs as a possible replacement with its own advantages, especially regarding their integration into real-world agentic AI solutions.

On a final, personal note, if major cloud infrastructure providers were to embrace and more aggressively promote the authors’ view on the potential of SLMs to lead agentic AI development, perhaps a significant portion of this journey could be covered in the blink of an eye.

Creating a Qwen-Powered Lightweight Personal Assistant

 

Creating a Lightweight Personal Assistant Powered by a Qwen Language Model
Image by Editor | Midjourney

Introduction

The Qwen family of language models provides powerful and open-source large language models for various natural language processing tasks.

This article shows you how to set up and run a personal assistant application in Python powered by a Qwen model — specifically the Qwen1.5-7B-Chat model, which is an efficient and relatively lightweight 7-billion-parameter chat model optimized for conversational use cases. The code shown is ready to be used in a Python notebook such as Google Colab, but can easily be adapted to run locally if preferred.

Coding Solution

Since building a Qwen-powered assistant requires several dependencies and libraries being installed, we start by installing them and verifying installation versions to ensure compatibility among versions you might have pre-installed as much as possible.

pip install -q transformers accelerate bitsandbytes einops ipywidgets

We also set GPU use, if available, to ensure a faster model inference, the first time it will be called during execution.

These initial setup steps are shown in the code below:

import torch from transformers import AutoModelForCausalLM, AutoTokenizer import time from IPython.display import display, HTML, clear_output import ipywidgets as widgets import sys import os   # Verifying installed packages and dependencies try:     import bitsandbytes as bnb     print("Successfully imported bitsandbytes") except ImportError:     print("Error importing bitsandbytes. Attempting to install again...")     !pip install -q bitsandbytes --upgrade     import bitsandbytes as bnb   # Installing required packages (you may want to comment the cell below if you already got these installed) !pip install -q transformers accelerate bitsandbytes einops   # Set device, prioritizing GPU if available device = "cuda" if torch.cuda.is_available() else "cpu" print(f"Using device: {device}")

Now it’s time to load and configure the model:

• We use Qwen/Qwen1.5-7B-Chat, which allows for faster first-time inference compared to heavier models like Qwen2.5-Omni, which is a real powerhouse but not as lightweight as other versions of this family of models.
• As usual, when loading a pre-trained language model, we need a tokenizer that converts text inputs to a readable format by the model. Luckily, the AutoTokenizer from HuggingFace's Transformers library smoothens this process.
• To enhance efficiency, we try to configure 4-bit quantization which optimizes memory usage.

# Load Qwen1.5-7B-Chat model - publicly available and efficient to run in Google Colab with T4 GPU model_name = "Qwen/Qwen1.5-7B-Chat"   print(f"Loading {model_name}...") start_time = time.time()   # Loading the tokenizer tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)   # Trying to load the model with 4-bit quantization for efficiency try:     print("Attempting to load model with 4-bit quantization...")     model = AutoModelForCausalLM.from_pretrained(         model_name,         torch_dtype=torch.bfloat16,  # Use bfloat16 for better performance         device_map="auto",         trust_remote_code=True,         quantization_config={"load_in_4bit": True}  # 4-bit quantization for memory efficiency     ) except Exception as e:     print(f"4-bit quantization failed with error: {str(e)}")     print("Falling back to 8-bit quantization...")     try:         model = AutoModelForCausalLM.from_pretrained(             model_name,             torch_dtype=torch.bfloat16,             device_map="auto",             trust_remote_code=True,             load_in_8bit=True  # Try 8-bit quantization instead         )     except Exception as e2:         print(f"8-bit quantization failed with error: {str(e2)}")         print("Falling back to standard loading (will use more memory)...")         model = AutoModelForCausalLM.from_pretrained(             model_name,             torch_dtype=torch.bfloat16,             device_map="auto",             trust_remote_code=True         )   load_time = time.time() - start_time print(f"Model loaded in {load_time:.2f} seconds")

When building our own conversational assistant, it is typically a good practice to craft a default prompt that accompanies each specific request to adapt the model's behavior and generated response to our needs. Here's a specific default prompt:

system_prompt = """You are a helpful, respectful and honest assistant. Always answer as helpfully as possible, while being safe. Your answers should be engaging and fun.
If a question does not make any sense, or is not factually coherent, explain why instead of answering something not correct. If you don't know the answer to a question, please don't share false information."""

The following function we will define encapsulates the heaviest part of the execution flow, as this is where the model gets user input and is called to perform inference and generate a response. Importantly, we will run a conversation in which we can sequentially make multiple requests, therefore, it is important to manage the chat history accordingly and incorporate it as part of each new request.

def generate_response(user_input, chat_history=None):     if chat_history is None:         chat_history = []          # Formatting the conversation for the model     messages = [{"role": "system", "content": system_prompt}]          # Adding chat history for a full context of the conversation     for message in chat_history:         messages.append(message)          # Adding the current user input     messages.append({"role": "user", "content": user_input})          # Tokenization: converting messages to model input format     prompt = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)     inputs = tokenizer(prompt, return_tensors="pt").to(device)          # Generating response: this part may take some time to execute at first     with torch.no_grad():         outputs = model.generate(             **inputs,             max_new_tokens=512,             do_sample=True,             temperature=0.7,             top_p=0.9,             pad_token_id=tokenizer.pad_token_id or tokenizer.eos_token_id         )          # Decoding the generated response     full_response = tokenizer.decode(outputs[0], skip_special_tokens=True)          # Extracting only the assistant's response, instead of the full raw output     assistant_response = full_response.split(user_input)[-1].strip()          # Further cleaning up the response if it contains role markers or other artifacts     if "assistant" in assistant_response.lower()[:20]:         assistant_response = assistant_response.split(":", 1)[-1].strip()          return assistant_response

Once the key function to generate responses has been defined, we can build a simple user interface to run and interact with the assistant.

The interface will contain an output display area that shows the conversation, an input text box where the user can ask questions, and two buttons for sending a request and clearing the chat. Notice the use of the widgets library for these elements.

# Create a simple UI for the personal assistant def create_assistant_ui():     output = widgets.Output()     input_box = widgets.Text(         value='',         placeholder='Ask me anything...',         description='Question:',         layout=widgets.Layout(width='80%')     )     send_button = widgets.Button(description="Send")     clear_button = widgets.Button(description="Clear Chat")          chat_history = []          def on_send_button_clicked(b):         user_input = input_box.value         if not user_input.strip():             return                  with output:             print(f"You: {user_input}")                          # Show thinking indicator             print("Assistant: Thinking...", end="\r")                          # Generate response             start_time = time.time()             try:                 response = generate_response(user_input, chat_history)                 end_time = time.time()                                  # Clear the "thinking" message                 clear_output(wait=True)                                  # Display the exchange                 print(f"You: {user_input}")                 print(f"Assistant: {response}")                 print(f"\n(Response generated in {end_time - start_time:.2f} seconds)")                                  # Update chat history                 chat_history.append({"role": "user", "content": user_input})                 chat_history.append({"role": "assistant", "content": response})             except Exception as e:                 clear_output(wait=True)                 print(f"You: {user_input}")                 print(f"Error generating response: {str(e)}")                 import traceback                 traceback.print_exc()                  # Clear input box         input_box.value = ''          def on_clear_button_clicked(b):         with output:             clear_output()             print("Chat cleared!")         chat_history.clear()          # Connect button clicks to functions     send_button.on_click(on_send_button_clicked)     clear_button.on_click(on_clear_button_clicked)          # Handle Enter key in input box     def on_enter(sender):         on_send_button_clicked(None)     input_box.on_submit(on_enter)          # Arrange UI components     input_row = widgets.HBox([input_box, send_button, clear_button])     ui = widgets.VBox([output, input_row])          return ui

Alternatively, we can also set up the option of using a command line interface (CLI) for the chat workflow:

# Example of a simpler approach to utilize the model (command line interface) def cli_chat():     print("\n=== Starting CLI Chat (type 'exit' to quit) ===")     chat_history = []          while True:         user_input = input("\nYou: ")         if user_input.lower() in ['exit', 'quit', 'q']:             print("Goodbye!")             break                  print("Assistant: ", end="")         try:             start_time = time.time()             response = generate_response(user_input, chat_history)             end_time = time.time()                          print(f"{response}")             print(f"(Generated in {end_time - start_time:.2f} seconds)")                          # Update chat history             chat_history.append({"role": "user", "content": user_input})             chat_history.append({"role": "assistant", "content": response})         except Exception as e:             print(f"Error: {str(e)}")             import traceback             traceback.print_exc()

Almost done. We will define two last functions:

1. One for performing a quick test to ensure that both the model and dependencies are set up well.
2. An overarching function to run the entire conversational assistant application. Here, the user can choose the kind of interface to use (UI vs. CLI).

# Trying a simple test query to ensure everything is working def quick_test():     test_question = "What can you help me with?"     print(f"\nTest Question: {test_question}")          start_time = time.time()     try:         response = generate_response(test_question)         end_time = time.time()                  print(f"Response: {response}")         print(f"Generation time: {end_time - start_time:.2f} seconds")         return True     except Exception as e:         print(f"Test failed with error: {str(e)}")         import traceback         traceback.print_exc()  # Print the full stack trace for debugging         return False   # Overarching function for our application: we can choose here which interface to use def run_assistant():     print("\nRunning quick test...")     test_success = quick_test()          if test_success:         # Ask user which interface they prefer         interface_choice = input("\nChoose interface (1 for UI, 2 for CLI): ")                  if interface_choice == "2":             cli_chat()         else:             print("\nStarting the personal assistant UI...")             assistant_ui = create_assistant_ui()             display(assistant_ui)                          # Usage instructions             print("\n--- Instructions ---")             print("1. Type your question in the text box")             print("2. Press Enter or click 'Send'")             print("3. Wait for the assistant's response")             print("4. Click 'Clear Chat' to start a new conversation")             print("----------------------")     else:         print("\nSkipping UI launch due to test failure.")         print("You may want to try the CLI interface by calling cli_chat() directly")   # Running the conversational assistant run_assistant()

Trying It Out

If everything has gone well, now it's time to have fun and interact with our newly built assistant. Here is an example excerpt of the conversational workflow.

Running quick test...
Test Question: What can you help me with?
Response: 1. General knowledge: I can provide information on a wide range of topics, from history and science to pop culture, current events, and more.
2. Problem-solving: Need help with a math problem, figuring out how to do something, or troubleshooting an issue? I'm here to guide you.
3. Research: If you have a specific topic or question in mind, I can help you find reliable sources and summarize the information for you.
4. Language assistance: Need help with writing, grammar, spelling, or translation? I can assist with that.
5. Fun facts and trivia: Want to impress your friends with interesting facts or just looking for a good laugh? I've got you covered!
6. Time management and organization: Strategies to help you stay on top of your tasks and projects.
7. Personal development: Tips for learning new skills, setting goals, or managing your emotions.

Just let me know what you need, and I'll do my best to assist you! Remember, I can't always give away all the answers, but I'll certainly try to make the process as enjoyable and informative as possible.
Generation time: 18.04 seconds

Choose interface (1 for UI, 2 for CLI):

Below is an example of live interaction through the UI.

Qwen-based conversational assistant's UI
Image by Author

Conclusion

In this article, we demonstrated how to build a simple conversational assistant application powered by a lightweight yet powerful Qwen language model. This application is designed to be run and tried out efficiently in a GPU setting like those offered by Google Colab notebook environments.