მოძიებით გაძლიერებული გენერაცია (RAG)

PRX მოძიებით გაძლიერებულ გენერაციას (RAG) ახორციელებს LLM პასუხების გასაძლიერებლად აგენტის მეხსიერებისა და ცოდნის საცავებიდან რელევანტური კონტექსტით. მხოლოდ LLM-ის პარამეტრულ ცოდნაზე დაყრდნობის ნაცვლად, RAG შესაბამის დოკუმენტებს მოიძიებს და პრომპტში ჩაშვებს -- რაც ჰალუცინაციებს ამცირებს და პასუხებს ფაქტობრივ, განახლებულ ინფორმაციაზე აფუძნებს.

მიმოხილვა

RAG პაიპლაინი აგენტის ციკლში ყოველ LLM გამოძახებამდე შესრულდება:

მომხმარებლის შეტყობინება
    │
    ▼
┌──────────────────────────┐
│  1. მოთხოვნის ფორმულირება │  საძიებო ტერმინების ამოღება
│                           │  მომხმარებლის შეტყობინებიდან
│                           │  + საუბრის კონტექსტიდან
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  2. ჩაშენების გენერაცია  │  მოთხოვნის ვექტორად გარდაქმნა
│                           │  კონფიგურირებული ჩაშენების
│                           │  პროვაიდერის გამოყენებით
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  3. მეხსიერების ძიება    │  ძიება მეხსიერების ბექენდებში:
│                           │  ვექტორული მსგავსება + სრული
│                           │  ტექსტური ძიება
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  4. რელევანტურობის       │  შედეგების შეფასება და
│     ფილტრაცია            │  რელევანტურობის ზღურბლს ზემოთ
│                           │  მყოფების გაფილტვრა
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  5. კონტექსტის ინექცია   │  შედეგების ფორმატირება და
│                           │  სისტემურ პრომპტში / კონტექსტის
│                           │  ფანჯარაში ჩაშვება
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│  6. LLM გენერაცია        │  მოდელი პასუხს სრული
│                           │  კონტექსტით ხელმისაწვდომი
│                           │  გენერირებს
└──────────────────────────┘

კონფიგურაცია

RAG-ის ჩართვა config.toml-ში:

[memory]
backend = "embeddings"  # RAG-ს ჩაშენებების ბექენდი სჭირდება

[memory.embeddings]
# ჩაშენების პროვაიდერი: "openai" | "ollama" | "local"
provider = "openai"
model = "text-embedding-3-small"
dimensions = 1536

# ვექტორული საცავის ბექენდი
vector_store = "sqlite"  # "sqlite" | "postgres" | "qdrant"

[rag]
enabled = true

# კონტექსტში ჩაშვებისთვის მოძიებული ფრაგმენტების მაქსიმალური რაოდენობა.
max_results = 10

# მინიმალური რელევანტურობის ქულა (0.0-დან 1.0-მდე) ფრაგმენტის ჩასართავად.
relevance_threshold = 0.3

# RAG კონტექსტისთვის გამოყოფილი ტოკენების მაქსიმალური რაოდენობა.
# კონტექსტის ფანჯრის გადავსებას თავიდან იცილებს.
max_context_tokens = 4000

# ფრაგმენტების შერჩევის სტრატეგია, როდესაც max_context_tokens
# გადამეტებული იქნებოდა.
# "top_k" -- ყველაზე მაღალი რელევანტურობის ქულები პირველი
# "mmr" -- მაქსიმალური ზღვრული რელევანტურობა (მრავალფეროვნება + რელევანტურობა)
selection_strategy = "top_k"

ჩაშენების პროვაიდერები

PRX მრავალ ჩაშენების პროვაიდერს უჭერს მხარს:

პროვაიდერი	მოდელი	განზომილებები	შენიშვნები
OpenAI	text-embedding-3-small	1536	საუკეთესო ხარისხი/ფასის თანაფარდობა
OpenAI	text-embedding-3-large	3072	უმაღლესი ხარისხი
Ollama	nomic-embed-text	768	ლოკალური, API ხარჯის გარეშე
Ollama	mxbai-embed-large	1024	ლოკალური, უფრო მაღალი ხარისხი
Local	fastembed	384	ჩაშენებული, ქსელის გარეშე

ჩაშენების პროვაიდერის კონფიგურაცია:

# OpenAI ჩაშენებები
[memory.embeddings]
provider = "openai"
model = "text-embedding-3-small"
api_key = "${OPENAI_API_KEY}"

# Ollama ჩაშენებები (ლოკალური)
[memory.embeddings]
provider = "ollama"
model = "nomic-embed-text"
endpoint = "http://localhost:11434"

# ჩაშენებული ლოკალური ჩაშენებები (გარე სერვისის გარეშე)
[memory.embeddings]
provider = "local"
model = "fastembed"

ფრაგმენტაციის სტრატეგიები

დოკუმენტების ჩაშენებისა და ძიების წინ ისინი ფრაგმენტებად უნდა დაიყოს. PRX რამდენიმე ფრაგმენტაციის სტრატეგიას უჭერს მხარს:

სტრატეგია	აღწერა	საუკეთესო
fixed_size	დაყოფა ფიქსირებულ ტოკენთა რაოდენობაზე გადაფარვით	ერთგვაროვანი დოკუმენტები
sentence	დაყოფა წინადადებების საზღვრებზე	პროზა და ბუნებრივი ტექსტი
paragraph	დაყოფა აბზაცების საზღვრებზე	სტრუქტურირებული დოკუმენტები
semantic	დაყოფა თემატურ საზღვრებზე ჩაშენებების გამოყენებით	გრძელი, მრავალფეროვანი დოკუმენტები
recursive	იერარქიული დაყოფა (სათაური > აბზაცი > წინადადება)	Markdown/კოდი

[rag.chunking]
strategy = "recursive"

# სამიზნე ფრაგმენტის ზომა ტოკენებში.
chunk_size = 512

# მეზობელ ფრაგმენტებს შორის გადაფარვა (საზღვრებზე კონტექსტის დაკარგვის თავიდან აცილება).
chunk_overlap = 64

# რეკურსიული სტრატეგიისთვის: გამყოფები პრიორიტეტის მიხედვით.
separators = ["\n## ", "\n### ", "\n\n", "\n", ". "]

მოძიების პაიპლაინი

ნაბიჯები 1-3: მოთხოვნა, ჩაშენება, ძიება

RAG მოდული მომხმარებლის უახლესი შეტყობინებიდან საძიებო მოთხოვნას ამოიღებს (არჩევითად LLM-ით გადაფორმულირებული query_reformulation = true შემთხვევაში), მას ჩაშენების პროვაიდერის გამოყენებით ვექტორად გარდაქმნის და ყველა მეხსიერების ბექენდში ერთდროულად ეძებს -- ვექტორული მსგავსება (კოსინუსი) და სრული ტექსტური ძიება (FTS5/pg_trgm). შედეგები გაერთიანდება და დედუბლიკატებს მოშორდება.

ნაბიჯი 4: რელევანტურობის ფილტრაცია

თითოეული შედეგი 0.0-დან 1.0-მდე რელევანტურობის ქულას იღებს. relevance_threshold-ს ქვემოთ მყოფი შედეგები უარყოფილია. ქულის გამოთვლა ითვალისწინებს:

• ვექტორული კოსინუსის მსგავსებას (პირველადი სიგნალი)
• სრული ტექსტური შედარების ქულას (გაძლიერების ფაქტორი)
• სიახლეს (ახალი მეხსიერებები მცირე გაძლიერებას იღებს)
• წყაროს პრიორიტეტს (ბირთვული მეხსიერებები საუბრის მეხსიერებაზე მაღლა რანჟირდება)

ნაბიჯი 5: კონტექსტის ინექცია

გაფილტრული შედეგები სტრუქტურირებული XML ტეგებით (<context><memory source="..." relevance="...">) ფორმატირდება და LLM პრომპტში ჩაშვდება. ჩაშვებული კონტექსტის მთლიანი რაოდენობა max_context_tokens-ით იზღუდება კონტექსტის ფანჯრის გადავსების თავიდან ასაცილებლად.

შერჩევის სტრატეგიები

Top-K

ნაგულისხმევი სტრატეგია. max_context_tokens-ში ჯდომადი K ყველაზე მაღალქულიანი ფრაგმენტის შერჩევა. მარტივი და პროგნოზირებადი, მაგრამ შეიძლება ზედმეტი შედეგები დააბრუნოს, როდესაც მრავალი ფრაგმენტი ერთსა და იმავე თემას ფარავს.

მაქსიმალური ზღვრული რელევანტურობა (MMR)

MMR რელევანტურობასა და მრავალფეროვნებას აბალანსებს. იტერაციულად ირჩევს ფრაგმენტებს, რომლებიც ერთდროულად მოთხოვნისთვის რელევანტურია და უკვე შერჩეული ფრაგმენტებისგან განსხვავდება:

[rag]
selection_strategy = "mmr"

# Lambda აკონტროლებს რელევანტურობა-მრავალფეროვნების თანაფარდობას.
# 1.0 = სრული რელევანტურობა (იგივეა, რაც top_k)
# 0.0 = სრული მრავალფეროვნება
mmr_lambda = 0.7

MMR რეკომენდებულია, როდესაც ცოდნის ბაზა გადაფარვად ან ზედმეტ ინფორმაციას შეიცავს.

დოკუმენტების ინდექსირება

ავტომატური ინდექსირება

memory_store ინსტრუმენტით შენახული მეხსიერებები ავტომატურად იჩაშენება და ინდექსირდება. დამატებითი კონფიგურაცია არ არის საჭირო.

დოკუმენტების ხელით შეტანა

დოკუმენტების მასობრივი შეტანისთვის გამოიყენეთ CLI:

# ერთი ფაილის ან დირექტორიის ინდექსირება
prx rag index /path/to/document.md
prx rag index /path/to/docs/ --recursive

# ყველა დოკუმენტის ხელახალი ინდექსირება (ჩაშენებების ხელახალი აშენება)
prx rag reindex

მხარდაჭერილი ფორმატები: Markdown (.md), უბრალო ტექსტი (.txt), PDF (.pdf), HTML (.html) და წყაროს კოდი (.rs, .py, .js).

წარმადობის ოპტიმიზაცია

პარამეტრი	რეკომენდაცია
chunk_size	256-512 ტოკენი კითხვა-პასუხისთვის, 512-1024 შეჯამებისთვის
chunk_overlap	chunk_size-ის 10-20%
max_results	5-15 უმეტესი სცენარებისთვის
relevance_threshold	0.3-0.5 (ხარისხის მიხედვით დარეგულირება)

უსაფრთხოების შენიშვნები

• RAG კონტექსტი LLM პრომპტში ჩაშვდება. დარწმუნდით, რომ შენახული დოკუმენტები არ შეიცავს სენსიტიურ მონაცემებს, თუ აგენტი არ არის ავტორიზებული მათზე წვდომისთვის.
• memory.acl_enabled = true შემთხვევაში RAG წვდომის კონტროლის სიებს პატივს სცემს. მხოლოდ მიმდინარე პრინციპალისთვის ხელმისაწვდომი მეხსიერებები მოიძიება.
• ჩაშენების API გამოძახებები დოკუმენტის კონტენტს ჩაშენების პროვაიდერზე გადაცემს. სენსიტიური მონაცემებისთვის გამოიყენეთ ლოკალური ჩაშენების პროვაიდერი (ollama ან local).

დაკავშირებული გვერდები

• მეხსიერების სისტემა
• ჩაშენებები
• ვექტორული ძიება
• SQLite ბექენდი
• PostgreSQL ბექენდი