diff --git a/index.html b/index.html index d340f4f..6f25032 100644 --- a/index.html +++ b/index.html @@ -330,11 +330,12 @@

What these are built on, and why

-

FastAPI · Postgres · pgvector

praxis
+

FastAPI · NumPy

praxis

- One API core serves every client. pgvector keeps the dense index in the same database - as the corpus, so there is no second system to keep in sync and no separate backup - story for the part that makes answers. + One API core serves every client. Dense retrieval is a matrix-vector product over + vectors held in memory and cached to disk, with a pure standard-library fallback so + the offline image and CI run without NumPy at all. A Postgres index with pgvector is + designed and not yet wired — the schema is in the repository, the retriever is not.

diff --git a/ru/index.html b/ru/index.html index 617e2ef..d144b53 100644 --- a/ru/index.html +++ b/ru/index.html @@ -328,11 +328,12 @@

На чём это построено и почему

-

FastAPI · Postgres · pgvector

praxis
+

FastAPI · NumPy

praxis

- Одно API-ядро обслуживает всех клиентов. pgvector держит плотный индекс в той же базе, - что и корпус: нет второй системы, которую надо синхронизировать, и отдельной истории с - бэкапами для той части, что делает ответы. + Одно API-ядро обслуживает всех клиентов. Плотный поиск — умножение матрицы на вектор + по векторам в памяти с кэшем на диск, плюс запасной путь на чистой стандартной + библиотеке, чтобы офлайн-образ и CI работали вообще без NumPy. Индекс на Postgres с + pgvector спроектирован, но не подключён: схема в репозитории есть, ретривера нет.