Retrieval, RAG i MCP: przestań być API między Claude a resztą SDLC

Jedno pytanie, kilka mechanizmów

W tym artykule nie chodzi o zapamiętanie różnicy między pięcioma buzzwordami.

Chodzi o pytanie:

Jak Claude ma sam zdobywać informacje potrzebne do wykonania zadania?

Odpowiedź zależy od rodzaju informacji.

1. Built-in tools: najpierw użyj tego, co już masz

Jeżeli informacja jest w repo, Claude często może znaleźć ją sam:

grep
glob
read
git
shell

Przykład:

Dlaczego zmiana X rozwaliła test Y?

Claude może:

• uruchomić test,
• zobaczyć failure,
• przeszukać repo,
• sprawdzić git diff,
• znaleźć odpowiedni kod.

Nie potrzebujesz MCP ani RAG.

Pierwsza zasada:

Nie dodawaj nowej infrastruktury tam, gdzie zwykły tool wystarcza.

2. CLI: często najlepszy interfejs dla developera i agenta

Jeżeli w Twoim środowisku działa:

gh pr view
gh run view
kubectl logs
terraform plan

Claude może używać tych samych interfejsów, których używa developer.

To ma ogromną zaletę: nie tworzysz osobnej ścieżki integracji tylko dla AI.

Przykład:

Sprawdź, dlaczego CI dla tego brancha nie przechodzi.

Claude może:

gh
|
v
znajduje run
|
v
czyta failure
|
v
repo
|
v
odtwarza problem
|
v
fix
|
v
test

Developer przestaje kopiować logi ręcznie.

3. Retrieval: znajdź właściwą wiedzę

Niektórych informacji Claude nie powinien mieć stale w context window.

Masz:

• ADR-y,
• runbooki,
• dokumentację,
• decyzje projektowe,
• historię incidentów.

Retrieval oznacza po prostu:

potrzebuję informacji o X
|
v
wyszukuję w źródle
|
v
wybieram relevant fragmenty
|
v
dodaję je do contextu

To może być zwykły full-text search.

Może być też bardziej rozbudowany system.

4. RAG: retrieval staje się częścią odpowiedzi

RAG, Retrieval-Augmented Generation, to wzorzec, w którym przed wygenerowaniem odpowiedzi pobieramy relevant wiedzę z zewnętrznego źródła.

Klasyczny diagram:

query
|
v
retrieval
|
v
relevant documents
|
v
Claude
|
v
answer / decision

Popularna implementacja może używać embeddings i vector DB, ale nie jest to definicja RAG.

W praktycznym systemie możesz mieć:

full-text
+
vector search
+
metadata filters
+
reranking

Dla developera ważniejsze jest rozpoznanie use case'u.

RAG ma sens, kiedy:

• wiedzy jest dużo,
• jest rozproszona,
• nie powinna być stale ładowana,
• agent musi odnaleźć ją na podstawie znaczenia.

Nie ma sensu budować vector DB tylko po to, żeby Claude znalazł definicję klasy znajdującą się w aktualnym repo.

5. External retrieval: internet też jest źródłem contextu

Wiedza potrzebna do wykonania tasku nie zawsze siedzi w repo albo wewnętrznej dokumentacji firmy.

Często problem zależy od aktualnych informacji z zewnątrz:

• dokumentacji frameworka,
• release notes,
• changeloga,
• GitHub issues,
• vendor docs,
• RFC/specyfikacji,
• security advisory,
• dokumentacji cloud providera,
• zmian w API zewnętrznego serwisu.

Wtedy Claude może użyć web search albo innego narzędzia do retrievalu z internetu.

Przykład:

CI zaczęło padać po aktualizacji biblioteki.

Claude może:

repo
|
v
sprawdza aktualną wersję dependency
|
v
web search
|
v
release notes / migration guide / issue tracker
|
v
łączy to z lokalnym failure
|
v
proponuje fix

Albo:

Czy ta metoda w aktualnej wersji SDK jest deprecated?

Zamiast polegać wyłącznie na wiedzy modelu:

Claude
|
v
przeszukuje aktualną dokumentację
|
v
wraca z bieżącym stanem API

To ważne rozróżnienie:

repo search
= wiedza z aktualnego kodu

internal retrieval / RAG
= wiedza firmy

web search
= aktualna wiedza zewnętrzna

MCP / tools
= dostęp do konkretnych systemów i akcji

Najważniejszy wniosek:

Context nie kończy się na repo i dokumentacji firmy.

Dobry agent powinien umieć sam dobrać także aktualne źródła zewnętrzne, jeśli problem tego wymaga.

6. MCP: dostęp do systemów i narzędzi

Retrieval odpowiada głównie na:

Co Claude powinien wiedzieć?

MCP pozwala wystawić agentowi zewnętrzne dane i akcje jako narzędzia.

Mentalny model:

Claude
  |
  +-- repo tools
  |
  +-- GitHub
  |
  +-- issue tracker
  |
  +-- observability
  |
  +-- internal APIs

MCP jest standardowym interfejsem pomiędzy agentem i takimi narzędziami.

To nie znaczy, że każdą integrację należy przepisywać na MCP.

Jeśli gh rozwiązuje Twój problem świetnie, użyj gh.

Jeżeli masz wewnętrzną platformę z operacjami:

get_recent_deployments(service)
get_service_health(service)
find_incidents(service)

MCP zaczyna wyglądać bardzo naturalnie.

RAG i MCP nie konkurują

To częste nieporozumienie.

Możesz mieć MCP tool:

search_engineering_docs(query)

który pod spodem korzysta z RAG.

Wtedy:

MCP
= interfejs do narzędzia

RAG
= sposób odnajdywania wiedzy

Podobnie MCP tool może zwracać aktualny stan CI, gdzie RAG w ogóle nie występuje.

Jeden task pokazujący cały poziom

Polecenie:

Sprawdź, dlaczego ten PR nie przechodzi CI. Znajdź przyczynę, odtwórz problem lokalnie i przygotuj poprawkę.

Stary workflow:

developer
|
v
GitHub
|
v
kopiuje log
|
v
Claude
|
v
developer znajduje pliki
|
v
Claude

Nowy:

Claude
+-- GitHub / CLI / MCP -> znajduje failing run
+-- repo tools -> lokalizuje kod
+-- docs retrieval -> sprawdza relevant zasady
+-- web search -> sprawdza aktualne vendor docs / changelog
+-- shell -> odtwarza failure
+-- edit + test -> przygotowuje fix

To właśnie jest praktyczne znaczenie:

Agent sam zdobywa potrzebny context.

Co to zmienia w SDLC?

Planning

Claude może pobrać:

• issue,
• acceptance criteria,
• relevant ADR,
• aktualną dokumentację zewnętrzną.

Implementation

Claude ma:

• repo,
• dokumentację,
• git history,
• vendor docs.

CI/debugging

Claude sam pobiera:

• failing job,
• log,
• artefakty dostępne przez narzędzia,
• changelog dependency, jeśli jest potrzebny.

Review

Claude może:

• przeczytać PR,
• diff,
• linked issue,
• build status,
• aktualną dokumentację API użytego w zmianie.

Incident response

Claude może:

• pobrać logi,
• metrics,
• deployment history,
• runbook,
• sprawdzić aktualne statusy lub dokumentację vendora.

Nadal obowiązują permissions i rozsądne granice. Dostęp do informacji nie oznacza automatycznie prawa do modyfikowania production.

Wdróż to dziś

1. Spisz trzy rzeczy, które regularnie kopiujesz do Claude

Na przykład:

• failure z CI,
• opis issue,
• fragment wewnętrznej dokumentacji,
• link do vendor docs,
• release notes dependency.

2. Wybierz jedną

Nie integruj wszystkiego naraz.

3. Znajdź najprostszy interfejs

W kolejności:

built-in tool?
|
v
CLI?
|
v
web search?
|
v
MCP?
|
v
własny tool?

4. Jeśli problemem jest wiedza, dodaj retrieval

Najpierw najprostszy search.

Vector RAG dopiero wtedy, gdy rzeczywiście rozwiązuje problem.

5. Pozwól Claude korzystać z internetu tam, gdzie aktualność ma znaczenie

Przy:

• nowych wersjach bibliotek,
• zmianach API,
• vendor docs,
• security advisory,
• cloud services,

nie polegaj wyłącznie na pamięci modelu.

6. Powtórz realny task

Warunek: nie wolno Ci ręcznie wkleić informacji, którą agent ma teraz pobierać sam.

Level complete

Poziom jest zaliczony, jeśli przynajmniej jeden typ informacji z codziennego SDLC, który wcześniej ręcznie kopiowałeś, Claude potrafi teraz zdobyć sam.

Może pochodzić z:

• repo,
• CLI,
• wewnętrznej dokumentacji,
• internetu,
• MCP,
• innego zewnętrznego systemu.

Na kolejnym poziomie zajmiemy się inną powtarzalnością: nie danych, tylko instrukcji typu "jak u nas robi się review / incident / migration".

Materiały

• Model Context Protocol w dokumentacji Anthropic
• Claude Code CLI reference: claude mcp
• Contextual Retrieval w Anthropic Engineering
• Enhancing RAG with contextual retrieval