Головна / Статті / Практичні поради: створіть простий додаток RAG у Google Colab за допомогою LlamaIndex

Практичні поради: створіть простий додаток RAG у Google Colab за допомогою LlamaIndex

Покрокова інструкція з практичних нотаток: створення простого додатку RAG у Google Colab за допомогою LlamaIndex: контракти, перевірки та готові блоки коду для команд, які використовують цю схему.

1221 слів

Цей посібник описує процес створення системи від сировини до готового продукту для: створення простого додатку типу RAG у Google Colab за допомогою LlamaIndex та безкоштовної моделі ШІ. Основна увага приділяється конкретним крокам виконання, чітким перевіркам та коду, який можна без проблем додати до репозиторію, не здогадуючись про його призначення. На етапі огляду необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Виконавці мають мати можливість перезапустити крок з відомої точки контролю, не здогадуючись про прихований стан системи. Необхідно одночасно задокументувати оптимальний та альтернативний сценарії виконання. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

1. Встановіть необхідні бібліотеки

Під час виконання етапу «1. Встановити необхідне» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторна передача ідентичних даних є поширеною причиною витрат ресурсів.

!pip install -q llama-index llama-index-readers-web html2text llama-index-llms-groq llama-index-embeddings-huggingface

2. Імпортувати необхідні пакети

Під час виконання етапу «2. Імпортувати необхідні дані» спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та наслідки часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви елементам, визначте критерії успіху та не допускайте безповідомного часткового виконання. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторна передача ідентичних даних є поширеною причиною проблем.

from llama_index.core import VectorStoreIndex, Settings
from llama_index.readers.web
import SimpleWebPageReader
from llama_index.llms.groq import Groq
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from google.colab import userdata

3. Налаштувати ключ API Groq

Під час виконання третього етапу «Налаштувати Groq» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Зберігайте у кеші стабільні інструкції системи та схеми інструментів. Повторна передача ідентичних даних є поширеною причиною зайвих витрат. Під час виконання третього етапу «Налаштувати Groq» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Одночасно задокументуйте оптимальний та резервний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

# Groq API Key
os.environ["GROQ_API_KEY"] = userdata.get("GROQ_APIKEY")

4. Налаштувати модель LLM та модель вбудовування

Етап 4 «Налаштування LLM» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність дій. Встановіть ліміт токенів на кожен крок та сесію. Інструменти типу агентів активно розширюють контекст; жорсткі обмеження запобігають тому, що демонстрації перетворюються на несподівані рахунки.

# Set up the open-source LLM and embedding model
Settings.llm = Groq( model="openai/gpt-oss-120b", temperature=0.1 )
Settings.embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-small-en-v1.5" )

5. Завантаження веб-сторінки

Етап 5 «Завантаження веб-сцени» працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу завдань. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Встановіть ліміти на кількість операцій за раз та за сеанс. Інструменти типу агентів активно розширюють контекст; жорсткі обмеження запобігають тому, щоб демонстрації перетворювалися на несподівані рахунки.

# Passing a URL which we want to load to our vector store
url = "https://mlds.analyticsindiamag.com/"
# Using SimpleWebPageReader to load the URL content
# html_to_text=True converts HTML into plain text
d1 = SimpleWebPageReader( html_to_text=True ).load_data([url])

6. Створення векторного індексу

Етап «6. Створити вектор» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ. Визначте бюджет на токени за кожен хід та сесію. Інструменти типу агентів активно розширюють контекст; жорсткі ліміти не дозволяють демо-версіям перетворюватися на несподівані рахунки. Етап «6. Створити вектор» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Документуйте як успішний, так і відновлювальний шляхи роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

# Create a searchable index from the loaded document
index = VectorStoreIndex.from_documents(d1)

7. Створити двигун запитів

Для етапу 7 «Створення запиту» необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Краще використовувати невеликі, перевірювані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру процесу. Коли наступним кроком є код чи виклик інструменту, краще використовувати структуровані результати з перевіркою схеми, ніж вільний текст.

# Creating query engine
query_engine = index.as_query_engine()

8. Задайте запитання

На етапі 8 «Задайте запитання» необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви елементів, визначте критерії успіху та не допускайте мовчазного часткового завершення. У разі, коли наступним кроком є код або виклик інструменту, віддавайте перевагу структурованим результатам із перевіркою за схемою перед вільним текстом.

# Running a query against the loaded URL data
r1 = query_engine.query("What is MLDS?")
print(r1)

Повний процес RAG

На етапі «Повний процес RAG» необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан.

Web Page
   ↓
SimpleWebPageReader
   ↓
Extract Text
   ↓
Hugging Face Embeddings
   ↓
VectorStoreIndex
   ↓
User Question
   ↓
Relevant Context
   ↓
Groq LLM
   ↓
Answer

Що далі?

Чек-лист для роботи